This page contains all the blog posts from september 2013. To read the most recent blog posts, click here.

Past week, i've been working on a text renderer for HD3. Both Technospire 2 and the Ultranought follow-up also have a self-made text renderer. This renderer is rather simple : it accepts a single paragraph of text and the coordinates of a rectangular area in which this text must fit as well as an alignement (left, center, right). The renderer makes sure that the text wraps when needed, without breaking up words and makes sure that the text doesn't spill out of the rectangular area. For TS2 and UL2, this is all that's needed.

In the past i've mentioned that Flash contains a very powerful text renderer that produces high quality results. The drawback of this very useful tool is that it's rather slow. Flash doesn't have a comparable tool built-in, but there probably are plenty of text renderers in existence (LibGDX offers a solution as well). Seeing as HD3 has some very specific demands, i can't use the renderer i made for TS2, nor will the Flash or LibGDX renderers will be sufficient, so i need to make a new renderer.

So what does HD3 need? There are many different ways in which cards get displayed in-game and each way has it's own demands regarding text. Cards that are in play need to show their name, if these cards are ships, they also need to show their current attack and defense values. Cards in hand don't need to show their name, but have to show their cost. Again, attack and defense are shown for ship cards. Cards in the deck editor should show the name, the attack/defense values, the cost and the amount of cards either in the deck or in the card stock. Finally there is the detailed card popup which must show everything about a card, so also the abilities. These various card images appear at different sizes and often use different fontsizes as a result.
Card costs have symbols in them. The card popup also has extra symbols to indicate different ability classes and might also contain text in italics, on top of that the abilities are seperated by a non-standard linebreak.
Combining all these requirements, i'd need a text renderer that's capable of inserting symbols at any point in the text, that can render italics and multiple paragraphs and that can support any text size.

At the core, a text renderer can be very simple. The one in Flash most likely uses the vectorized data of a font file to turn text into pixels, which does require more processing power, but is pretty much a mandatory step for quality font rendering at any size. My renderer works with a premade set of images : every character is an image, f.i. 'a' is one image, 'A' is another, the italics versions of these two are yet two more images, etc - this results in a total of 212 images at a relatively large font size (32). The plan is to pick a large font size for this 'master set' and then use pixel scaling to simulate having smaller fonts.
When my renderer receives a text, it breaks this text down into characters, spaces and linebreaks. Each of these things gets a number. Think of these numbers as instructions that tell the renderer where the character its image is located or when to leave some room between characters or start new lines. At this point, the renderer no longer treats the text as a set of characters, but as a set of images. This is important since it makes it very easy to add in images that aren't characters, such as the energy and race symbols in the game. In a next step, the renderer places images next to eachother, making sure that when a line is full, it starts on a next line while preserving individual words. In a final step, the renderer applies alignments and then scales this text down if it was told to produce text with a smaller than standard size.
My renderer is also capable of generating text with a slight shadow under them (which helps seperate them from backgrounds and improves readability), it can vary the space between all characters in a text, and it can also change the spacing for individual characters.

Up to the final step everything works great. Text is aligned, italics and symbols are working. Scaling however does not produce acceptable results. This is most likely due to a combination of the pixel scaling filters used in LibGDX, the fact that we're dealing with small pixel images and not a vectorized font.

Here is a screenshot of some tests with the renderer. The first row shows the default font size in 3 alignments (left, center, right). Some symbols and italics have been included. The second row is the same text and alignments as the first row, but scaled at 85%, 70% and 55% from left to right. The filter used here is 'bilineair'. The 3rd row is scaling at the same percentages, but this time with a 'nearest neighbour' filter. These two rows clearly show the drop in quality.
The 4th row is a realtime scale test, basically taking the first row and scaling it in realtime to 85%, 70% and 55%. The quality here is clearly much better, but the drawback is that this scaling is done after the renderer has generated its output, thus the area that contains the text is also scaled with it.
A small problem is also made clear in this image : in the top row, the text has a small black shadow, this shadow is exactly one pixel. In the scaled examples, the shadow obviously becomes smaller since it's part of the text. To fix this i would have to scale and render the shadow layer seperately, which might affect performance.
Looking at the first word of each entry, it shows that the space between the 'T' and 'e' is too large. This is where per-character spacing comes in. To fix this example i could either add a negative spacing after the 'T' or in front of the 'e'. If you look at the italics word 'text', regular 't' and 'e' are okay, so the problem is probably related to the capital 'T'.

Being able to have fonts in different sizes is critical for HD3, so a solution is required. For the past 3 days i've been looking at what my possibilities are, and i'm in the process of testing these out to see what gives the best result, what is most efficient, what is fast, and what can be easily ported to Flash.
First of all, i could attempt to write different scaling filters - LibGDX offers 'Bi-linear' and 'Nearest neighbour'. I could make my own filter that does a form of 'Bi-cubic' filtering. The problem with this idea is that a filter is a pixel operation and thus can be quite slow, especially for larger texts. On top of that there's no guarantee that this will produce acceptable results as it will still perform scaling based on a set of characters that are on average 30 pixels in size.
Another solution is to provide additional mastersets - one for each fontsize the game requires. The trouble here is that at this point, it's unknown how many different fontsizes are needed. There is the UI, the card popup, cards in play, cards in hand and 2 or 3 sizes of card images in the deck editor. While there will be some overlap between these in terms of font sizes, there's a good chance the game needs at least 3-4 master sets. Creating such a set and calibrating it takes a lot of time, on top of that it will make the game's filesize larger. There's another problem with this : the smaller the font gets, the harder it will be to calibrate it to make sure that spacing between individual characters (i.e. images) is constant. The renderer, due to the fact that it works with pixellated and not vectorized fonts has a resolution of one pixel, if things need to move away or closer to each other for a fractional pixel value, it's not going to work out.
A 3rd solution is using the GPU of the GFX card to do the scaling. In tests, this produces much better results than pixel scaling and it's also faster. The problem is that to be able to scale a text that sits on top of an image (for instance the card cost that is placed on a card image), this text has to be rendered seperately. It would however take a lot of seperate renders before the GPU starts to slow down, but it does complicate the code that needs to keep track of scaled texts and non-scaled images. In the image above, the 4th row of text was created using the GPU to scale the first row.

Right now i'm considering a combination of the second and third options : the UI will receive a dedicated font of size 32, this fontset doesn't need italics or symbols so it will be smaller. The card popup will receive a dedicated font of size 24, including italics and symbols. Neither of these will thus require any form of scaling.
All card images will use the size 32 font for cardnames and scale those texts in realtime. Any numbers (for attack, defense and costs) on cards will probably be rendered using a dedicated (possibly, multiple) fontset that only contains numbers and the energy symbols, which requires a very simple and easy to build renderer.
There are other combinations possible as well : i could render the text for the full card popup in size 32, then scale it down in realtime so it appears as size 24 and place it on top of the popup image. While this requires two render calls (the image and the text), it would probably result in the best possible font quality. Doing this does mean i won't be able to use this setup for Flash and thus i'd have to make a seperate renderer (with its own fontset) for the flash version of the game. However, this might be an acceptable thing to do as it would really ensure both versions of the game to have the best possible rendering quality for texts. Previous versions of HD prove that it's possible to create a card popup only using the built-in Flash text renderer, so if all else fails for the Flash version, i can go that route again. Since the flash version is half the size of the Java version, the fontsize needed for the cardpopup would be 12, which might be too small to attempt to do this with a pixellated fontset anyway.

Testing of these options, or combinations of options will tell me what works best. This is most likely going to take a while, but it's better to do this in the early stages of development and start out with a proper text renderer rather than having to change the renderer halfway into finishing the game.

In my previous blogpost i showed some sketches of UIs from the game. The images were 800x500, which is the target size of the flash version of the game. The size is a bit smaller compared to previous versions of the game, which were all 800x600 pixels.
The very first alpha of HD (written in C#/XNA and not in flash yet) was actually 1024x768 pixels. The on-screen elements were not that much bigger than they are in the 800x600 versions that followed, which meant that things had to be moved closer together as well as being resized. A big change was removing reserved space for the card popup, which permanently sat to the left of the area where the cards in a player's hand were shown. Instead of being in a fixed position, the card popup had to overlap other images and moved to different positions depending on which cards you were putting the mouse cursor over.
I picked the 800x600 size after checking what the maximum size was that the most popular flash game portals accepted at that time. Even though a fair number of portals don't accept games this large, i had to stick with it as it wouldn't be possible to make the game smaller.

HD3 will be 800x500, which will affect the look of the combat screen somewhat, but for most other screens there won't be any problems. The deck edit sketch from last week still has more space dedicated to cards compared to HDx, despite being smaller. This is mainly because of the UI being a lot more compact.
There are two reasons to go with 800x500. One is simply because i really like the 16:10 ratio for games, this ratio is also becoming more and more popular for desktops, laptops and of course tablets. If i were to make a 4:3 ratio game, it wouldn't look too good on tablets. Reason two is convenience : the Java version of the game is 1600x1000 pixels, so when the time comes to create a flash port, all dimensions related to UI or screen input can be easily adjusted without losing any accuracy. The same goes for images that have to be scaled down or recreated : it will be more accurate to scale down images to 50% and it will be easier to recreate images at 50% as well, compared to for instance going from 1200x750 to 800x500 (which is what the Ultranought follow-up is doing).

The Java version being 1600x1000 pixels doesn't mean that this will be the only resolution the game will support. This is the resolution behind the scenes, used to lay out UIs and game screens. This is the advantage of a graphical system using the graphics chip of a computers versus using the CPU (as in flash). Not only is it faster, but in the end, this 1600x1000 gets projected onto whatever the window size of the game is. By default the game will support 800x500, 1024x640, 1200x750, 1280x800, 1600x1000 window resolutions and any fullscreen resolution.
1600x1000 is the max resolution i can do as my monitor isn't much bigger. This means that when the game runs fullscreen on a monitor of 1680x1050 or larger, there will be some upscaling. However, so far this doesn't result in any noticable drop in quality. If i wanted to make the default resolution of the game 1680x1050, i would need a larger monitor to allow me to work in windowed mode all the time, which greatly speeds up work versus working in fullscreen mode.

Looking at the resolutions that current tablets can support, 1600x1000 is not that much. Many PC monitors these days are also well beyond 1680x1050. But i have to make a choice somewhere, and besides convenience of porting to flash, i still need to be able to finish this game within a reasonable amount of time and with the resources i have (i.e. my current PC monitor), so i need to choose a resolution that's easy to work in and with. Another concern is the size of the game. HDx was pretty heavy for a flash game (6+ MB), the AIR version of the game with non-compressed graphics is almost 32 MB. Half of that amount is taken up by the card images (the rest is UI and misc images and audio), these were 128x128 pixels for HDx and they will probably be 292x292 for HD3 (more than twice as big since the card popup will be slightly larger). Based on the size of the card images and the filesize of the AIR version, an estimate for the Java version (i.e. the PC and tablet version) will be 16 * (292^2) / (128^2) = 83 MB. While this number doesn't take into account compression, which i expect to be more efficient on larger spritesheets and some other optimization tricks, it's clear that this is a big increase compared to HDX-air. It's not because internet connections in general are fast these days that a game should be huge in file size, this is always something i've been conscious about when making games. The estimate above doesn't even take into account yet the many ideas for new cards that are planned.

I hope this post provides a little insight into my choice on 800x500 (flash) and 1600x1000 (PC+android) pixel resolutions for HD3.

The first few lines of code for HD3 have been written. As said before, the game is being written in Java (using LibGDX). I took the basic gamestructure which i made for Technospire II and which was improved for the Ultranought follow-up and started adding in specifics for HD3. I'm nowhere near getting started on actual gameplay related code however, several supporting mechanics and UI-related stuff needs to be added in first.

To get an idea of what the UI might look like, i made several sketches, starting with what will most likely become the most complex screen UI-wise, the deck editor. Below is a screenshot of a sketch for this screen.

The top part will show cards in the deck being edited while the bottom part shows the cards in stock. The red boxes are placeholders to get an idea of how many cards can be shown at once, depending on the size option that is selected. The sketch shows two options for cardsizes, but there will be a third (an even smaller one) for the desktop version. I'm starting with sketches for flash/android to make sure buttons are large enough or things are big/clear enough in general on the smallest versions of the game.
A big difference with previous HD games is that the UI on this screen takes up very little room, resulting in more space to show the cards. The plan is now to also support dragging of cards to quickly edit decks.

Deck management will look like this :

One entry per deck, showing the deck's name, base energy type, card contents and some info regarding the skills that are linked to each deck.

And here is a preview of what the card popup might end up looking like :

The passives of the card are shown in italics and are all next to each other, the remaining abilities will each start with an icon and are seperated from each other.
The plan is add a setting to the game that allows players to control the size of the popup. As it is now, the popup is slightly larger than the HDx one, which is probably fine for tablet screens of 7". For flash and larger tablet screens, it might be more interesting to scale it down a bit, and even more so when playing on desktop screens.
The 'attack' and 'defense' icons have been upgraded, as well as the rarity icons, which have been replaced by stars. The more stars, the more rare a card is, starting from uncommon. I'll dedicate a future blogpost about rarity since there are some changes planned to the current rarity system.

These are sketches, which mean they can (and most likely, will) change before being put in the game. The cyan detail in the UI in the first two sketches can be changed to any of the 8 racial colors, as in HDx. In general, i prefer simple and functional UIs, rather than more elaborate UIs with a lot of graphical detail. Basically, i don't want an UI to stand out and get in the way of the gameplay. It's always a tricky thing to balance right, so i actually have to implement these in game to see if they work well.
Once i'm done with the basic gamestructure work, i'll start working towards the deck management screen first, and then the deck editor and card popup.

The decision has been made : i'll work on HD3 for the forseeable future and HD SQ is on hold.

While HD SQ is a completely new idea, HD3 offers more challenge and is more exciting to both build and play. A lot of new stuff is coming on top of what is present in HD Xyth already.
I don't have a final list of features yet as things can still change this early in development. The focus for the coming weeks will be on setting up the core of the game and doing tests with several completely new mechanics such as a new text renderer and java-database interaction - nothing terribly exciting, but very important for the game.

Over the coming weeks i'll talk about some of the planned features in more detail. Planned doesn't mean that they'll all make it at release. Some may change or be replaced, others may be postponed for future patches (for instance : i have no plans for direct pvp in the first release).

For now, here is a very early list of planned features.

• exploration - similar to the campaigns in HDX, but this time it will be a different format with better difficulty progression.
• skills - see my previous devblog for more details on this. Skills basically let players enhance their favorite tactics.
• drafting - a new game mode that will play a big role in events.
• events - large scale indirect multiplayer happenings with rankings. These will be quite different from both HDS events and HDX wars.
• friend list - set up a list of allies that will be available in indirect coop game modes.
• flagship - a ship avatar that also serves as a fully customizable ship card that can be used in most game modes.
• more cards, deck mods, environments, etc

So i'm still working on the preparations for both HD SQ and HD3, which means i haven't decided yet what game i'll make next.

I'm spending a bit more time on this preparation compared to other games. Usually i only detail the main gameplay mechanic and then i start coding, creating everything that's needed to allow me to implement and then test the main gamplay mechanics. For HD Xyth this meant i created the main menu and activated the 'quick fight' button, which led to a quick fight setup screen that had pretty much no options, only a 'play' button. At that point, the game had no way to edit decks, so all testing was done with a hardcoded deck. This however means that the game already had card data and ways to process that data (such as required to render the full card popup), which is obviously a very important part of the game even though it doesn't directly deal with duelling. Then came the opening hand screen, which was fully functional, and from there one i could start on the actual combat. There was no real AI at first, all it did was cycle through the phases of a turn.
Once this was finished, i started fleshing out what was present : the main menu, the quick fight setup screen and additions to combat to support new abilities. Eventually it was time to add in a deck editor and card browser to make it easier to test the new cards and abilities. Eventually the AI had to be added to allow even more testing options for abilities. Then came more additions : deck mods, environments. Finally, i went back to the main menu and started activating buttons and finishing all the stuff related to each button. For each menu entry, before implementing the related code and mechanics, i went through a smaller preparation phase, where everything was worked out before i started coding.

What i like about this way of work is that i break the game up in it's main components, but i only focus on one component at a time. I can start coding faster as i only need to work out one initial component. The entire process of building up the game then goes through cycles of preparation and coding phases, which keeps things interesting - coding 8-10 hours a day gets very tiring if you do it for weeks on end. This setup also allows me to postpone game design decisions - when i started on HD Xyth, the details regarding how the campaign mode would look like weren't know yet. As i worked on other stuff, i occasionally wrote down ideas and by the time i started on campaign mode i had a bunch of things written down to sort through, compare and flesh out.

For HD3, which has been the focus for the past two weeks, i'll be spending more time on the initial preparation phase. Right now i have sketches ready for the menu screen and deck editor, which will allow me to break down these screens in detail and set up a list of related mechanics and graphical assets. I'm at least going to add the quick fight setup screen, the opening hand screen and the combat screen as part of the preparation, as well as everything related to card data (important since the way abilities are handled, will change). This is a fair bit of stuff, but compared to what's planned for HD3, it's actually not that much. What makes these elements important, is that pretty much everything else planned for HD3 will depend on them.
The other elements for HD3 can wait until this basic stuff is in, since all of it will build upon the base. Additional gameplay modes all require the default gameplay mode. The skill system i mentioned in my previous blogpost needs both combat and deckbuilding/managament to be complete.
The most important change compared to HDX, is that the card browser and deck management screen are already present from the start of the game. Even though they don't directly deal with playing duels against the AI, they are the most important screens when it comes to setting up the building blocks and capabilities of the UI. The screens themselves are relatively complex to make and they need to work well with large amounts of cards and decks (something that didn't work out too well with the deck editor in HDX).

Compared to the HD3, HDSQ needs less prep work, since i already made a prototype a while ago, which had its own preparation phase. The game is also a lot less complex so less stuff needs to be detailed.

At this rate, i do expect to be able to make a decision on what game to build next within the next two weeks.