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

Alpha testers have commented several times on the original input system on the combat screen. It's different from the other HD games in that simply mousing over cards no longer shows the card popup. There are two reasons for this. One is that a system with mouse-overs isn't going to work on android (or touchscreen devices in general), and i didn't want to create seperate input systems for desktops and android devices this early in development. Two is that this system makes it much harder to accidentally play the wrong cards or activate the wrong abilities.
For experienced players that know the card stats by hand, being forced to bring up the popup before you can play or activate cards is an unnecessary step. I had already planned several other input options, but originally wanted to add these after a few more card abilities were added (since some of these actions and acti abilities can determine what an input system needs to be capable of, if they require special targets).

I've been working on two out of three planned input systems :

1. Holding down the ctrl key on the keyboard while clicking a card will, instead of bringing up that card's popup, activate that card's default operation. A ship in hand will go straight to the targetmode where you can choose an empty slot. An action in hand will either request a target, or be played instantly if it doesn't need a target. An acti on a card in play will function similarly as actions. Someone who knows the stats and abilities of most cards by hand, is likely going to be using the mode over the default mode, so i've added a button on the combat screen that, when on, basically makes it seem as if the ctrl key is down all the time. With this button toggled on, players no longer need to hold down ctrl to quick-play cards, but they can use ctrl to temporarily disable this mode. Basically, this button reverses the behaviour of the ctrl key during the combat screen. Another advantage of this button is that it makes this quickplay mode available for android devices, who generally don't have keyboards.
For now, this button will always show, but the plan is that by default it will be hidden. There will be an option to make this button visible once this is implemented. That way, i'm sure that players can't accidentally turn it on, and wonder where the popups have gone. After all, this feature is aimed at more experienced players.

2. Full keyboard control. Arrow keys allow to browse between cardslots, enter allows to bring up popups on selected cards, or allows to activate a card's default operation if a popup is open. Ctrl+enter will allow to activate the default operation on a selected card without needing to bring up the popup.
This is a bit more complex as it deals with selecting cards, which is a new concept in HD. Technically you could say that a card is selected when it's popup is shown, but now the game needs cards to be selected even without a popup. A second new element is that empty slots can be selected as well. Originally, the plan was to have the arrow keys jump between cards, ignoring any empty slots between them, but while that system worked, it wasn't very intuitive. Example : you have a structure in your right most slot, and its selected. You also have only one ship and its in the left most slot. Pressing the up arrow will jump from the selected structure to the ship, and that didn't feel right as you pressed up and the selector basically went more left than up. Instead, when pressing up, the empty ship slot above the selected structure slot will become selected.
At this very moment, the arrow keys work, and it's possible to scroll through card slots. The enter key to activate cards still needs to be implemented.

3. Drag and drop operations (DD). This is the most complex system of the three, and will likely be postponed until at least a bit more content has been added to the game. That way i can also gather some feedback on the other two input systems first to see if this is needed at all, or perhaps which parts are needed the most. DD will also likely be implemented in steps. Dragging a ship or struct from hand to an open spot in play is relatively simple and will be part of the first step. Then there are actions in hand. If they need a target, they would have to be dragged on that target, unless these are special targets for which DD will never work (cards in deck or scrap, or when an action requires you to choose an energy type). If actions don't need a target, technically just dragging them outside of the hand area should be enough to play them. Actions from hand would be implemented in a second step. Then comes the most complex part : acti abilities. These would be a matter of allowing the player to drag cards in play with actis onto their targets. If these are actis that don't require targets, it becomes tricky : technically i could allow the player to drag these anywhere, but then there would be no way to cancel anymore if players change their mind.
On top of these challenges, there's also the complexities that come from the presence of the ctrl-key system that already exists in game. DD still must work, regardless of the state of the ctrl button on the combat screen. So dragging a card shouldn't activate the quickplay mode for instance.

The next alpha update (ETA unknown at this time) will definately include the first system (ctrl-key), and it looks like the arrow key system will be in as well. I'll see about fixing a few more bugs for that update as well, and once that version is live, i'll start work again on adding content (CA card set would be the next logical step).

The way graphics work in my flash games versus those made in java, can differ quite a bit. Since the plan is to give my java games also flash versions, i try to mimic the way i'm used to work in flash in the java games. For HD3, which in places gets rather graphically complex, this didn't work out. Before the alpha was released, i ended up spending about two weeks optimizing a number of screens in the game.

In flash, you basically reserve a block of memory where you can draw into. Everything you draw or copy in there, ends up being shown on screen. Generally, this goes rather fast, but at the same time, flash games are mostly small, so this is to be expected. You can reserve additional blocks of memory just to store images that are more complex. Let's say you have a game that features spaceships built up out of various components. You draw these components beforehand, instead of the full ships, and add them to your game. Whenever your game then needs to render a ship, it then takes the needed components and renders them in the correct order and relative positions to generate a complete ship. If a large number of ships need to be drawn in realtime, you actually have a lot of draw operations that the flash player needs to perform in realtime. In such a case, it's often a good idea to render all the ships a certain level needs, once, at the start of that level, and to a seperate location of memory. Then, whenever your game needs a ship, instead of combining the component images, it just copies that entire ship from the seperate memory location. So instead of risking having lag in your game while it plays, you have a small loading screen before each level.
HD3 does a lot of such preparations, at the very start of the game. Before the menu screen shows, the game will prepare a bunch of images and place them in memory.

The big difference with working in java, is that the images i create need to be uploaded to the computers graphics card before they can be shown on screen, and this is uploading itself is a slow process. Once an image is in the graphic card's memory however (at this point it's called a texture), it can be shown on screen with only minimal effort. The drawback is that there are now two seperate objects : an image and its texture. If i change the image, the texture is not updated, unless i upload it again. Now, i not only need to worry about preparing images without them lagging the game, but also minimizing the number of texture uploads.

I started of HD3 similar to how i worked in flash games, and for most screens this worked okay (but not stellar). I'd make one image large enough to hold the entire screen, draw the screen on that image, and turn it into a texture. Most screens change the way they look, depending on what you do in that screen (moving cards around in the deck editor, for example). If something changed on screen, i'd update only those parts on the image that were affected (to minimize the time spent drawing), and then upload it again. But the time it takes to upload a texture to the graphics card depends on the size of the image, and not on how much of it was changed. So if i change only a small portion of the image, or the entire image gets changed, the time to upload it remains the same, as you can't upload only the changed part of the image. This quickly became a problem in screens with frequent updates. Example : in the battle setup screen, or the flagship editor, there are scrollers that allow you to change values, and you are likely to click these very quickly. Everytime such a scroller was clicked, the screen would need to update, which slowed things down a lot.
The solution is to seperate all the elements of a screen, and give them their own texture. Things that change often are placed on the smaller textures, just large enough to contain the changing element, so that continuously uploading the (very small) texture doesn't slow down the game. Everything else gets all placed on a single large texture, which only needs to be uploaded once, at the very start of the screen. Another solution is to prepare all possible varations of the changing elements, but in a game like HD3, with so many variable elements, it would take both a lot of time and a lot of memory to prepare all that, so the ideal solution sits somewhere between these two options (and is different for each screen).

The biggest drawback is that, compared to the original flash system, rendering has become a lot more complex. In flash, i had basically one renderer, that could handle every screen, with the exception of the combat screen, which receive its own renderer. Now, every screen needs its own renderer since screens have varying numbers of textures, varying amounts of stuff that gets prepared at the start of the screen, and there are even screens that have different update rates. Example : the flagship screen - it shows a card popup at all times of your flagship, but the card popup itself is a relatively complex image, made up out of multiple layers with often a fair bit of text on it. Originally, everytime you'd change an ability or stat in the screen, the popup would have to be redrawn, and then uploaded again. If you are using a scroller, rapidly changing the strength of a single ability, this alone could slow down the screen, even with all the optimizations. At that point, you're likely not even looking at the popup, but at the part of the screen you're manipulating. So i've changed the way this works : the cardpopup will remember that a change has been made, but it will wait a very short time before doing an actual update of the popup image. So while you're rapidly clicking buttons to change a single ability, the popup won't update, but when you stop doing that, the popup will update. Instead of one update for every click, there's only one when it's truly needed. Now, this is straightforward stuff, and many games have such little tricks to improve performance, but actually implementing that stuff takes a bit of time.

The slowest screens the game had were the flagship editor and the boost/component browser. The examples above already explained the problems with the flagship editor. The boost browser had two problems : 1 - it updated frequently since players are likely to move boosts or components from the bottom half to the top (similar to the deck editor, which suffered from the same problem), and 2 - the boost images were very complex.
Similar to the cardpopup, boost images are made up out of many layers, several of which need to be colorized on top of that. Regular card images are just one image that's provided with the game, but boosts can come in so many different combinations, that it's better to provide the components and let the game create a full boost image.
The first problem this screen had (and the deck editor, too) was fixed by splitting all the images on this screen over 5 different textures. For the second problem, i had no choice but to prerender all the boosts and components a player has at very start of the game. This resulted in a noticably longer loading period before the game can start, but the boost browser now works a lot more fluently.
The increase in loading time however, turned to be unacceptable, especially on android devices which aren't as fast as the average computer. The solution here is to render the images, then save them to file. The next time the game gets started, instead of rendering images, it simply loads the files that had been saved previously. On PC, the time saved between rendering and loading from file is not that noticable, but in android, it shortened the loading dramatically.

The HD3 alpha has only been out for a week. Thus far, a few bugs have been discovered, but more importantly, players/testers have brought a few issues up.

One thing that keeps coming back is the new input system during combat. In the previous versions of HD, the interaction was kept to a minimum : mouse over cards to see their card popup, click cards to activate or play them. Now, the mouseover system is gone, and cards need to be clicked to bring up their popup, then a button needs to be clicked to activate or play them. It takes a bit more work, but it's needed for android, where the concept of mouseovers doesn't exist. This system also makes it much harder to accidentally activate or play cards.
I knew that this system wasn't going to be very interesting for more experienced players who no longer need to see the card popups to know what cards do. So i was already planning to implement a drag-and-drop system for both PC and android. On top of that, there can be a set of hotkeys as well, so most of the combat can be played without a mouse. The main reason this system isn't in yet is because its capabilities will depend on all the activatable and action abilities that require special targets that might still be added. If such an ability targets a card in play, things can be relatively simple, but if you have an action that asks you to choose a card in deck or scrap, or an energy type, things become complex right away.
In the near future, i'll work out what is possible.

I'm hoping to get a first patch out in the course of the coming week. It will contain a few bugfixes, but hopefully also some improvements for the performance on android. A lot of stuff is already planned for the next major version as well.

The HD3 alpha is available. For the time being, i'm not planning on promoting it too much, as it's still a very early version of the game. Once more cards, deckmods and environments are in, and the game starts feeling more like a beta version, i'll start trying to attract more playtesters.

The current version of the game has the entire Human card set, 3 deck mods and 3 environments. The only gameplay mode that's active is the regular single duel against the AI. Only a small sets of boost components are supported, but all related mechanics (crafting, recycling, usage) are complete. Flagship editing is possible as well, but only the abilities that are present on the Human cards can be chosen. All other flagship mechanics are also complete.
Feature-wise, the game in its current state is very close to what a beta or even release might look like, it's mainly the content that's lacking. But content depends on existing mechanics anyway, so adding in new content (cards, boosts, gameplay modes) will be the focus for the forseeable future.
As i've mentioned in the blogpost about alpha contents, there are two more large mechanics that might still be added before the game is considered ready for release : drafting and mercenaries. But even without these things, HD3 will already offer plenty of new stuff compared to HD Xyth.

I'll be taking a short break from coding, to do a few other things :

• the wiki will receive a number of articles that serve as a manual to the features and content already in the current alpha. Part of this work is already done. The plan is that the wiki will be updated alongside new alpha releases.
• i'm also planning to test a few things that might be included in HD3 at a later point, and now seems like a good time as i'm not in the middle of coding any large or complex mechanics
• finally, i need to set up a list of things that should be added in the next alpha expansion. This will likely be the Ca'anian card set as a minimum with a few more deckmods and some new boost abilities.

For those of you who are interested in checking out the alpha, the download locations can be found on this page on the wiki. That same page also links to a number of articles (some still in progress of being completed) with more info about the alpha and it's current feature set.

The HD3 alpha will not be the first alpha i've released. Both HDx and HDs had their own alpha phases, but things will run a bit differently now.
Both the previous HD alphas were flash games, and since these are embedded on the NULLL site, it's very easy to share information from the site with the game, without the game needing to connect to a database at all. This made it possible for me to restrict access to the alpha. Such a simple solution isn't possible for the HD3 alpha, which only exists as a java version (for both desktop and android).

The reason why i would restrict an alpha in the first place, is to make sure that only people who are truly interested in having a look at the game and helping me out by reporting bugs or problems, do get access to the alpha. Announcements and recruitement for alpha testers were only done on the NULLL forums, so that way i only reached people who were interested in the forums to begin with, and thus those people were more likely to report problems on those same forums. It also made sure that if there were sudden critical bugs that might make parts of the alpha unplayable, that i could keep testers up-to-date on this, so they could avoid going to parts of the game that were clearly broken. There's very little point in allowing everyone to access your alpha, when only 3 people are actually interested enough to report problems they come across. If everyone who's interested in HD, sees the HD3 alpha, and don't know what an alpha version of a game entails, they might get the wrong idea about what HD3 might be like.

So my options are to add in a log-in page to the game, or to have no restrictions at all. I haven't done anything in java that deals with database interaction yet, so i have no idea how much time this would take. Sooner or later the game will need such systems, but i rather focus on stuff like this when it's truly needed. If i do add log-in functionality, i ideally also add a system that stores your info, so players don't have to type their log-in credentials everytime they start up the alpha (and an alpha version is likely to have bugs that will crash the game).
Not having any access restrictions makes things a bit easier, though. I don't have to adjust the NULLL website accounts of those people who are interested, and i don't have to implement an untested system that is so critical that it basically determines whether people can access the alpha at all.

Thus, the HD3 alpha will be available to anyone who is interested. Downloads for windows/mac/linux/android versions will be provided on the NULLL website. For now i don't have a list of minimum requirements, but for the PC versions, i doubt this is really needed. The android version is aimed at devices with a screen size of minimum 7 inch, the game might be too hard to interact with on smaller screens.

There won't be a flash alpha. Turning the game in its current state in to a flash game, is definately possible, but it's basically wasted effort. Large parts of the game will likely change so drastically over the course of the alpha, that i would have to create a new flash version from scratch instead of being able to update the flash version alongside the java version, everytime there's an update. The amount of time that would go into that is better spent on making the java version better. It's unlikely that there will be a flash version before the game reaches beta.

HD3 doesn't have an official subtitle. The plan is that the game will receive a number of larger updates, each bringing new large mechanics or updates, every so often. Each update will have it's own title. The alpha will have version number 3.00.000 and subtitle 'cards in space', minor updates will start at V 3.00.001 but will keep that same subtitle, the next big alpha update will be V 3.01.000, and will have a new subtitle, and so on.