The Sprite Font plugin is effectively the Text object, but drawing each character from an image. The image contains a grid of every character in a character set (most commonly ASCII), and then to render a string of text each relevant character is drawn out from the grid in the correct sequence. This allows arbitrary text to be rendered from individual hand-drawn characters.
Note we are not looking for an identical clone of the third-party plugin; this specification makes some changes, additions and removals, some of which are also relatively subtle.
Sprite font [Edit] - opens the image editor for the sprite font image
Character width, Character height - size of each cell in the image
Character set - the sequence of characters displayed in the image, so the plugin can look up which cell to retrieve for each character
Text - initial text
Scale - a multiplier to scale the drawn text with. Effectively the font size, but just done by stretching the drawn images.
Initial visibility - visible/invisible
Horizontal alignment - left/center/right
Vertical alignment - top/center/bottom
Hotspot - top-left/center
Wrapping - word/character
Character spacing - extra pixel width to add between characters, default 0
Line height - extra pixel height to add between lines, as per the Text object, default 0
Other properties from Mipey's plugin should be omitted. In particular the 'Effect' property must be omitted since that is now handled by the built-in 'Blend mode' property. The plugin should handle wrapping as the official Text object does (drawing to the full extent of the object's bounding box, but never outside the bounding box).
Compare text (match the official Text plugin's condition)
Set character spacing
Set line height
It should also be possible to specify variable width characters. I think this would best be done by having an action to set a narrower width than usual for a specific cell. E.g.
Set character width
For example, "Set character 'i' width to 3 px". Any attempts to set a width wider than the cell width should be ignored. After that action, any 'i' characters that are drawn should only occupy 3px of width, rather than the full character width, so narrow 'i' characters do not appear with unnecessary space around them. Narrower characters should probably be drawn left-aligned in their cell, since if they were centered then the rounding of odd sizes could cause pixel-perfectness issues.
Note TextWidth and TextHeight should mimic the official Text plugin, which returns the extent of the actually drawn text. For example if the string "foo" was displaying in a 1000x1000 sized text object, the TextWidth and TextHeight are the size of the box enclosing the characters of the string "foo".
Default sprite font
A default sprite font should be provided as the initial image, so something useful can be rendered immediately after inserting the plugin. We must have copyright permission to redistribute this image, so it would be best if you come up with an original, or at least find an acceptably licensed example online. We will need to add features to Construct 2 to support loading this as the default image, but we will do that ourselves.
The default image must be a power-of-two size.
It is not necessary to have accurate sprite font rendering in the editor, since this can be time-consuming and difficult to get right. A reasonable placeholder is acceptable, although if you can manage full edit-time rendering we would be very impressed!
The plugin should support any size image. Specifically it must not require a wide image with all the characters on a single line, since this is likely to be wasteful on devices where the GPU places the image on a power-of-two surface internally. The plugin must work with power-of-two size images, and we will document that this is recommended for use with the plugin. Given any size image, the cell sequence starts in the top-left corner and continues after wrapping at the edge of the image.
The character set should support unicode characters. In other words it should work correctly if the user enters a sequence of Russian characters for the 'character set'. You should check if some languages involve surrogate pairs (where two code points are emitted for a single typed character), and this should be handled correctly (the character must not span two cells in this case).
The plugin should perform well and create a minimum of garbage. Rendering the object continuously whilst setting any of its properties to different values every tick should create virtually zero garbage, if reasonably possible. All official plugins are written with this aim. See this blog post.
The plugin should not allocate any images or create any canvases other than the single sprite font image, to minimise image memory use. Note Mipey's plugin allocates additional images or canvases; this should not be done in this plugin. It should be possible to draw arbitrary strings directly from the single sprite font texture. It must support both canvas2D and WebGL renderers. It must support Construct 2's layout-by-layout texture management in WebGL mode (the Tiled Background object is a suitable example of how to do this).
The plugin must be tested and verified that all features work on all Construct 2's supported platforms, including when minified. Specifically CocoonJS may be problematic, but it must work with the subset of features that CocoonJS provides. We can help with testing if you don't have access to particular devices, since we have lots of devices in our office.
It is absolutely prohibited to re-use any code from Mipey's plugin, since we do not have copyright permission to use it. It should not be necessary anyway, since the features described here should be achievable by most competent programmers.
You are free to re-use/rip/adapt/hack any code from any official code, especially the Text plugin (from which it might be useful to steal some word wrapping code).
Any bug reports we receive relating to the plugin, even long after release, we will forward to you and expect you to fix in a relatively timely manner (before the next stable release, which usually occurs every 6 weeks, or at the next stable release after that if already close to a stable release). The contract will also cover payment for maintenance work. We may also decide to alter the code of the plugin ourselves, after which we will notify you and send you our updated version. We do not expect maintenance work to be too time consuming (probably a couple of hours every couple of weeks in the long term).
We expect well-written, professional code. It should be at least reasonably readable and practical for another developer to understand and maintain.
We think it is simplest that we provide the documentation, since the use of the plugin should be straightforward. Therefore you do not need to worry about writing the manual entry or any tutorials.
We are interested in contracting similar jobs in future, where we contract to have certain plugins or behaviors developed. High-quality work on this job will put you in a good position when we have other projects in future!
This job has now been assigned to a developer. Look out for future work postings!