Now the intro screen is also finished, showing a nice ASCII logo with some fade in/out effects. For the logo I wanted to add also some ASCII transformation effects, but the problem was the performance. Something has changed on Android 4.x, and the TextView can’t handle refreshing itself with approx. 5000 characters per frame at a decent speed. I tested the same effect on a 2.x device, and all is working just perfect. So the effect is unhappily left out.

Today I implemented quickly the splash screen which will show some basic information about the project, current build number, and complete release notes for the current and all previous versions. The screen will be shown propably only in the development phase.

One more important thing is that the whole game, after the splash screen, will be locked to landscape mode. I thought about different game parts and how to organize the whole UI and at the end with landscape mode much more information can be shown.

After investing so much time in the project, it’s time to sit again and think about the next steps.

First of all I decided that I will use the ASCII graphics until the project is completely finished; now that’s for sure. But still, I want the game to look good even without real graphics and it would be a real challenge to do this, because I’m thinking about adding also some effects and animations. Yes, everything is represented only with text and symbols, but still, I can add unlimited layers of text to achieve some effects, like adding sprites in any other 2d game.

Also I will concentrate myself on parts before the actual gameplay, like showing the splash screen, intro and title screen, menues, selecting scenarios… etc. In other words, I will start from the beginning, trying to code everything so that it can be considered as the final implementation for the first couple of demo releases. Of course that means also that I’ll need more time for every part or feature, plus, I want the game to look nice.

One of the topics that I didn’t covered is the victory conditions definition for each scenario and each team, and also the in game event handler.

In the original game there are several ways to finish a scenario: eliminating one team member of the opposite team or all of them, eliminating special tiles on the map, evacuating own units… etc. So I’m massaging my brain cells last couple of days with thoughts how to define these conditions in the existing scenario model.

The other thing is the event handler. In some scenarios you can get reinforcements after a specific number of turns. That must be also defined in the scenario model and checked by the handler every turn.

Currently I’m putting all my thoughts on a paper and thinking about how to implement all these features with as less code as possible, so it will be easy later on to create all these conditions in a level editor.

While developing I put in some data model classes a little bit of game logic. The game is getting more and more complex, so it’s becoming harder to follow and debug the code. Today I created a couple of helper classes which contain only the game logic, leaving the data model classes clean and readable.

I decided to pack all the armor data in one class. In the original game there are only four types of armor in all scenarios, all with same characteristics (but different prices). Since I’m planning to make the game as more expandable as possible, I’m leaving the possibility that armor types can be defined for each scenario separately. The unit base data model is also expanded with a new armor parameter now.

After I completed the items, tiles and the map, it was time to put also the rest of the data into the first scenario. I had to expand the base scenario model with additional fields like how many levels are available in single player mode, how many credits you get per level / or in two player mode, available units with all their characteristics, which items can be bought and how much they cost, available turns… etc. I’m still thinking about how to define victory conditions for both teams, and event handling during the game.

There is enough data now to start maybe with the player and level selection, armoring and equipping units, and finally initializing the game.

Today I added the protection value parameter to the base tile data model. Some tiles can have a terrain protection value; meaning, when a unit stands on such tile, other units have less chance to hit when shooting on it. So units can “hide” behind bushes, plants or even furniture tiles. In the first scenario the tile that has the most protection value is the “Reed Plant” with a value of 6, following then the “Shower” tile with a protection value of 4. The formulas how those values are affecting the shooting algorithm are, unfortunately, unknown to me, so I must improvise again.

Last couple of days I was busy defining the whole tile set for the first scenario. The map consists of 26 different tiles sorted in categories, and each having it’s own parameters. Again I had to play the game a little bit, to figure out the additional AP costs which some tiles have and need to be added on the basic movement cost. Also, units can hide behind some tiles (like trees and bushes), and I had to test these in the original game and set the appropriate parameter for hiding. The only thing I don’t know is the constitution of the tiles, so I set some values of my own guided by logic.

The representation (“graphics”) of the tiles is not final, some minor changes can occur in the future. When I look at the game now, it reminds me totally on a Rogue-like game. Very nice indeed.

Now the base ammo items are also defined and linked with weapons. There are total of 14 different ammo clips (some of them can be used for more than one weapon). Just as a reminder, although I adjusted the parameters of the ammo items like in the original game, my idea was that weapons can use different ammo types with different ammo capacity or firepower. Therefore every weapon has a list of supported ammo items.