June 2013 blog archive

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

30/06 - Ultranought I vs II

Work on the follow-up to Ultranought continues : most of the supporting mechanics for actual combat are nearing completion, which means i'll be able to start combat related stuff very soon.

The idea for Ultranought was to have a combat system where there would be plenty of ships on the screen at all times and to let the player have some choices when it comes to ships and their stats. The first thing worked out ok, the second not so much. Building ships required energy and one basic resources and both of these were not that rare. The choice the player had was to use optional resources to boost the attack, armor or speed of these ships. Generally one would stall the enemy just enough to stock up a lot of these secondary resources and then launch a large number of ships with maxed secondary stats. If this attack didn't take down the enemy base, return to stalling until there were enough resources again to launch another big attack.
You can say that resource management is a tactic, but i rather see the tactical choices one has to make come down to choosing the correct ship for the current situation.

The new Ultranought has a different setup. The stats of ships are fixed throughout a battle, but ships have abilities. There are also more ships to choose from : 32 compared to 4. Not all ships have abilities, but most do and can regenerate HP, repair allies in a certain range, teleport or disable enemy ships, etc.

Ultranought focussed on the ships of a single race, and while the new version is also centered around a single race, it can technically launch ships from all races. Each race then offers 4 ships. To be able to launch ships from other races, the player has to collect experience points which can be invested into skills. Both the experience and the ships are fixed to certain race, this means each race has its own set of skills and you only get experience for a certain race if you defeat that race in combat. So play a level against a Ca'anian opponent to gain Ca'anian experience, which can be invested into Ca'anian skills, which in turn unlocks Ca'anian ships and boosts their stats.
Energy is required to build ships and since everything up until this point is nicely split into the different races, it comes as no surprise that you'll need the specific racial energy to launch that race's ships.
The available levels reflects this setup as well : from the start, the player can choose which race to battle. One can then focus on a single race to make their ships stronger, or battle the other races to have access to a wider range of ships.

23/06 - HD3 card abilities

Past week i've been working on Ultranought II, i'm currently doing the layouts for the various in-game screens and working out the details of combat. These are the basics before i can start on the more exciting stuff, so in this blog post i'll talk a bit about HD3 instead.

I have no idea yet when i'll start on HD3, but i've been writing down ideas and working out some details for a while now. A lot of these things still need to be worked out in greater detail before i can start coding, so all the things i'll talk about can still change. While many things will be similar to older versions of HD, there will be plenty of mechanics that will have to be re-invented, such as the way cards and their abilities are stored and handled in-game.

The data that represents cards in HD only has room for 3 card abilities : played (which trigger when the card enters play), automatic (which trigger at the start of each of their owner's turns) and activated (which the owner of the card can trigger during their turn). There are abilities that don't really fit in these 3 types however, such as Cloak or being able to damage 3 ships during the attack phase, which are abilities that are always active. Cards don't have room for proper passive abilities, but the game mimics this by having automatic abilities hand out passives. This is why cloak is an automatic ability, but all this automatic ability does, is add the passive ability 'cloak' to this card. Abilities that grant a bonus to the base while the card is in play have also been placed in the automatic ability slots, as well as abilities that trigger on the removal of cards.
While this system works, it's far from straight-forward and it uses up the automatic ability slot on card. It also gets tricky when cards need multiple passive abilties, as i have to create automatic abilities that hand out every possible combination of passive abilities.

This setup will change in HD3. The best solution i have thus far is simply the removal of the current fixed, one-of-each ability structure.
Technically this means cards can have more than 3 abilities (and any combination of passives on top of that), or multiples of a single ability type. While it's not my intention to drastically change the current card set (all the current cards will still work under this new system), it's good to have these possibilities for future cards.
Removing the card categories also doesn't mean that things will get more complex for the player. If an ability clearly states when it triggers, the player doesn't really need to know what type of ability it is. An ability that starts with the words 'When this cards enters play…' is clearly a played ability. Going from HD Spectrum to HD Xyth, i introduced icons for the 3 ability types and most passives, which meant the phrase 'When this cards enters play…' was replaced by an icon, freeing up space on the card popup. This idea might be extended to support more ability types on top of the current 3, such as icon to indicate that an ability triggers when this card leaves play, or an icon to indicate that an ability is always true (example : while this card is in play, owner's base gets +1 resistance). Passives on the other hand might lose their icons and instead be replaced by keywords. Examples of such keywords : Cloak, Cerberus (attacks 3 ships), Hydra (attacks 7 ships), Fast (can attack the turn it enters play).

To round up this post, here are some ideas for new passive abilities. Firstly, i'll probably change cloak and split it into two abilities : cloak and shimmer. Cloak then becomes immunity to all targeted abilties, but doesn't provide protection to abilities with an area-of-effect. Shimmer is a more advanced version of cloak and provides immunity to all abilities, targeted or not, but only those owned by an opponent.
A new ability, similar to cloak and shimmer is 'Shield', this provides protection against a single non-combat ability. Once a card with this ability has been hit by such an ability, it loses the Shield. 'Armor' could absorb a set amount of damage, before it's removed from a card. The 'Ethereal' ability makes a ship unblockable, but also causes this ship to be unable to block, basically making any opposing ship in front of it unblockable as well.
I'm also thinking about racial resistances, these work the same as regular resistance, but only for damage sources that are of a specific race. And the opposite ability could be interesting too : a damage boost for your ships when they face a ship or base of a certain race.

If you wish to discuss this blog post, you may use this topic on the NULLL forum : http://nulll-void.com/forums/viewtopic.php?f=21&t=952

16/06 - HD past & future

Thus far, when releasing games i stuck with the same general idea when it comes to the order in which i put out games. I've done a number of small games and only two truly larger titles (HDS and HDX).
There are two main reasons for doing these small games inbetween the larger HD titles :
Firstly it allows me to quickly try out an idea without spending several months on it. If i release something and it turns out it's not considered fun, that's easier to deal with if it only took me a few weeks versus it taking several months of work. From these smaller games, Ultranought, Nebula Warriors, Warstations and Rivi'i Hell are those that received generally positive feedback.
The second reason has to do with promotion. On one hand it's easy to reach a fair number of people with flash games as there are plenty of sites where one can upload their games to, at the same time this also means there are tons and tons of flash games, making it hard to stand out. So far, i don't think these smaller games, with the exception of Ultranought have brought in many new players.

Next to the smaller games, i've released a new version of Hidden Dimensions each year. This year will be different since i needed a break from doing HD stuff for about 9 months out of every year thus far. Not doing a HD game this years allows me to try out a few more things that can be considered medium games or that simply will take more time (such as everything related to learning Java and Android specifics).

HD Xyth did well : lots of positive feedback, high ratings on Kongregate and Newgrounds, i really enjoyed creating the game and managed to put most of my remaining ideas for HD into this game. There's still room for improvement however : the UI isn't smooth/clear enough in many places, the upgrade system could use more room for player choices or customization, the AI still struggles with certain abilities and the new direct PvP code didn't perform as well as expected. The wars system could also be more detailed and the lack of some form of in-game savegame backup or cloud saving of player's progress has caused too much trouble.
For a while i considered tackling all these issues and at the same time making the game compatible with Android. This would take several months of work, as it would basically come down to a complete rewrite of large sections of the game.
After completing TS2, i learned plenty of new things about Java and porting Java games to Flash. Trying to fix HDX basically means i'd make a new flash version, so i can keep the basics of my renderers, especially for complex stuff such as card images and the combat screen. However, to make the best version for Android, i'd have to make a java version instead (though the flash version would work, it just wouldn't be good enough). Porting a flash game to a java game takes a fair bit more work than doing it the other way round. On top of that, if i want to do a java version, i'd need a new multiplayer service as the current one doesn't work with java.
So the only solution here would be to start from scratch in Java, then port the game to flash. The amount of time it would take to do all of this is probably as much as it took me to create HDX itself - i might as well get started on a new HD game instead. By the time this 'fix' is ready, there might not be any people left playing HDX and it's much easier to promote a new game than an update to an existing game.

So i have decided to leave HDX as is. I will make a new HD game instead, which builds upon HDX, but where i'll add in new features. Some of these new things are rather exciting : clans/friends system, indirect co-op, 2 vs 2 system, regular and raid bosses, events, plenty of new card abilities, and more.
For the near future, i'll also make less of the smaller games and set up my larger titles so that it's easier to provide long-time support as well (this includes bugfixing, new features and new content). Generally i tend to start on new games as soon as one has been completed, which makes it harder to go back to these older games to fix or add stuff since i'm no longer familiar with their code and structure.

In my previous blogpost i mentioned having 4 games in mind. These are Ultranought II, HD SQ (which is not the follow up to HD X as it's not a traditional HD game), a party-based ARPG and the next traditional HD game. Right now it seems that it's best to start with Ultranought II (the least complex of these 4), to allow me to fine-tune my game frameworks a bit more, so porting from Java to Flash is even faster. Then i'll probably do HD SQ, which will probably also feature clans, indirect co-op and raid bosses.
This will allow me to test more complex remote database related stuff in Java. I might also add some form of direct multiplayer, to test a new multiplayer service (as the current one doesn't work with Java).
HD SQ will take quite some work, so i can't really say when i'll start and when (or if) it will be ready. I also don't know if i'll do the next HD game after HD SQ, or do the ARPG (or something else) first. Since i tend to add or change features while working on a game, i can't really predict how long something will take either.

This is the general plan for the near future. Summary : no small games unless they're vital in testing out something for the larger games & new Hidden Dimensions game(s) coming up.

If you wish to discuss this blog post, you may use this topic on the NULLL forum : http://nulll-void.com/forums/viewtopic.php?f=21&t=950

09/06 - TS2 flash version

The porting process ended up taking a lot less time than expected, which is of course a good thing. On top of this there are still a few areas that can be optimized further to making porting of future games easier.

The release of TechnoSpire II wasn't planned until later this summer and i will probably stick with that plan. For the flash version, a few things still need to be done related to achievements for the NULLL site. The NULLL site itself also needs to be updated so it can support a new game.

Between now and the release of TS2, i'll probably get started on the next game. I'm not completely sure which one it'll be as i have 4 games in mind for the near future. I might start with the least complex game so i can work on mechanics i haven't tried before in Java (such as remote database interaction and multiplayer-related code) over the course of several games instead of putting all that stuff into a single game right away.
The most likely candidates for my next game are HD SQ and Ultranought 2. I already did some work on HD SQ, but it requires a fair bit of database and indirect multiplayer features. For Ultranought i'm currently working on some sketches for the various in-game screens. In any case, i'll probably start the next game in Java again and port it to flash later, so there will be a hires version for Android devices.

02/06 - TS2 flash port

Porting in progress! There are several stages in creating the flash version of TechnoSpire II.
First i simply put all the java code through a tool that turns the basic and most frequently used Java commands into their AS3 (the language used in creating Flash games) counterpart. This takes care of the most tedious part of the port as it involves small simple changes that need to be done many times.
Next i'll paste the resulting code from this operation into my default framework for flash games.
Then i have to go through all the code a look for more complex elements that need to be changed as well as game-specific changes that differ between the Java and the Flash version (mostly related to the Flash version being smaller than the Java version). At this point i also look at stuff that's fundementally different between the two languages, such as input capturing and savegame saving and loading.

The next step involves everything that's related to rendering, but i split this step in two parts : in the first part i look at the relatively simple elements, such as the UIs and once these are confirmed working, i start on the complex stuff : the game map. For TS2, i kept the UIs very simple on purpose, to allow faster porting. The game map on the other hand is relatively complex since it requires pixel-perfect rendering (it's a tile-based game after all) and there are a number of graphical effects that have to be rewritten completely.

For the sake of learning Java and LibGDX, TS2 was a good project since it contained all the basic functionality a game needs (minus multiplayer and remote database interaction) and i added in support for multiple resolutions, which is the first time one of my games supports this (excluding the original Star Mass alpha). But for the sake of porting things over to Flash, the multiple resolution support actually made things more complex. At this point, i've completed all the UIs and some of the visual effects code. What remains is the actual map rendering and real-time player interaction with the map and it's NPCs and items.
Either way, the porting process thus far has allowed me to come up with a number of things for the general framework of future games that would bring the Flash and Java version much closer to each other, and thus, easier to port.

Coincidentally, the first version of Technospire was created so i could teach myself PHP and Mysql database interaction. Now TS2 ends up being used to learn Java+LibGDX.

Advertisement