Beta test

Or should I say a month of playtesting. A good number of bugs are identified and fixed and publishing a pipeline (to beta test at least) is established. Also, the game UI finally looks like a game UI.

At least that was the state of the game in May. This is going to be a long post, game development is going faster than blogging. So let's begin. Here is the trailer! And information about how to join beta:

It took me a number of attempts to make this video and it shows. I have decent experience in chopping and compressing a video but this was my time composing one out of multiple pieces. The audio was the easiest part, I wrote the text, tried a few recording programs, a few microphones, and read the text the best combination. In principle that is. I had run through multiple drafts of the text because the speech is not a blog post. You have to use simpler sentence structure, watch your breath and rephrase hard to pronounce words. But at least it was quick and easy to iterate. I settled on recording one paragraph (2-3 sentences) multiple times at the time and stitching the best takes in one audio file afterward. Getting video footage was a mess. The game is not integrated with Google Play Games so I couldn't use their screen recording feature, which is otherwise very ergonomic and makes good quality footage. So I had to look for other programs and make do with a barely passable one. Composing a video out of multiple ones was an even bigger mess. I was unable to find a good no-fuss program for it so I had to stretch the capabilities of a tool I worked with before. It again took multiple tries to get desired clips out of recordings because the tool doesn't like making cuts at arbitrary frames and appending multiple such hack job video files often resulted in the glitchy final video. It was the FLV encoder that saved me from non-keyframe cuts hell. And now, now the game is changed so much that I should make another trailer... I dread about it but I'm prepared with better software now and all I really need, besided courage, is to find the time to make the footage.

Ok, so the trailer got uploaded, the link posted here and people came, and then what happened? I'll get to that, after elaborating one little detail. Getting a beta test invite link requires basically having an app published, which means, filling in more forms, figuring out app signing, getting comfortable with the release treadmill, and then wait for a few days to get the app reviewed. The upside of the process is that Google will do some basic app tests for you and the results could be useful for improving the app. Automated tests do have trouble with navigating game map because they don't do touch gestures but they will do everything possible on regular UI widgets and report all sorts of accessibility issues. Also, Google will try running your app on older devices if you declared it should be compatible with them. This test has found (crashed) a few places where the game was using functions unavailable in the old versions of Android.

Ok, so people came, and what happened? When you present a program to the general public, keep in mind that most feedback will not be aligned with your plans for the project and that requests for additions of a similar kind will not be uncommon. Don't get overwhelmed by it, keep calm and try to compromise.

I've limited promoting the game so I got about 10 beta testers. Most of the requests were for more role-playing features. Ones that come to mind are flag emblems, named fleets, and AI personalities. But the most requested change was to make a black background. Since the game kind of already had that in the form of the night mode theme, I made the night mode the default.

At least that was the first step. The second step was to make properly set up application's theme, for both night and day mode and both portrait and landscape orientation. This took the most of the May, mostly for learning which leavers to pull to get the desired effect. But there were also trials and errors in making and setting button and panel background images. Android, especially older OS versions, has very limited support for stretchable images, both in terms of capabilities and documentation. I managed to get things working under imposed constraints but it's not foolproof there are still some quirks remaining I cannot find a solution for.

Other smaller improvements done during the month:

• Fleets can be redirected in flight. Immediate destination (first waypoint) still can't be changed, the rest of the path can be. The idea is that once you send a fleet it is committed to that destination but everything beyond the first destination is a future order and therefore prone to change. 
• Star type and star trait are listed in the star/colony info panel.
• Speed boost technological is effective only between own colonies. The idea is to help speed up ship deployment but to still have an advance warning when being attacked.
• The game now tracks how many qubits you got from each source instead of one total number. This makes it possible to change rank-based rewards in the future and consolidates data for rewards like beating previous survival record.
• Players are first ranked by whether they survived until the end of the game or not and then by score (within alive and eliminated groups). I entertained the idea of having it possible for an eliminated high scoring player to rank above an alive but low scoring one but this would defeat the point of making a big alliance to take out dominating player and just make alive players postpone concluding a finished game until they outscore eliminated players.
• Computer players now gather at least 3 combat ships before attacking. It's a quick and dirty patch for preventing bots from sending ships one at a time in the early game and just losing them without incurring any damage to an enemy with slightly higher defense tech.
• Research points each player gains is not affected by combat outcomes (such as losing a colony). The amount shown in the research screen is guaranteed and technology advancement happens after combat.
• Survival threat ships spawn at random locations outside the map. Quick and dirty partial unstub of this part of the game until I come around implementing it properly.
• Save file can be exported so if the game is crashing in certain situations, you can help by sending me your save.
• Infrastructure for upgrading save files when the game updates, since now there are players other than me.
• Optional ads at the end of the normal game to increased qubit reward.
  

Bug fixes:

• Fleet orders are properly saved.
• Computer player logic starts properly in survival mode.
• Computer player war declaration trigger properly calculates ally strengths so it doesn't change its mind about relation with the strongest player every turn.
• Computer player doesn't crash when sending troop ships.
  
• Colonization news when the whole map is colonized happens only once per game (was repeating itself every turn).
• Attempting colonization on the already colonized world doesn't prematurely end turn processing anymore.
• Selecting an object on the map doesn't change orders given to a previously selected one. Before, selecting an uncolonized star you don't want to colonize would remove colonization order from a previously selected star, and the same happened for stimulation and factory prioritization on own colonized stars.
  
• Star name uniqueness is guaranteed.
• Technologies can advance by multiple levels if there are enough research points.
  

June

 

Most of June was spent improving rendering performance. Yup, even a game as simple as this can have FPS issues. Occasionally at least. Just drawing the map was pretty fast but any map transformation (panning and zooming) would create a lot of short-lived objects, resulting in a performance drop on older phones. Improving the performance was tricky. An initial approach was supposed to be simple, just delegate translation (result of panning) and scale (zoom factor) numbers to the drawing API. But this also scales things you don't want it to: line thickness and text size. For such cases, I still had to make "manual" transformations but I've tried to minimize the work that happens there.

 

Another big thing, simply due to the amount of ground to cover, this month was more info in the game. You can long tap on almost any UI element in the game and get clarification on it. This is akin to right-click in Master of Orion 2 and Master of Magic.

Other smaller improvements done during the month:

• Limited player length to 2 to 100. 
• Changed starting conditions, each player starts with a fully developed colony and one cruiser to start scouting with.
• Perform negotiations with other players by long taping their names on galaxy map info sheets.
• Increased research benefits to x1.2 per level and changed research cost. The first few levels have handpicked costs and later levels grow by factor x1.5.

Bug fixes:

• Diplomatic contacts are checked when the game is created.
• Prevented homeworld placement overlap that was causing players staring eliminated on a crowded map.
  

July

As of yet, July doesn't come with big works like the previous two months so I seized the opportunity to tie up some loose ends and add improve gameplay. One thing I wanted to do for a long time was to add cheats to speed up testing new features. Like being able to see the whole map when working on graphics or jumping straight to survival mode when working on it. Until now I was modifying code to achieve that but that was always running the risk of inadvertently slipping into an official build. And if nothing else, remembering the place I need to hack to get a certain cheat got old pretty fast. Formalizing cheats into app feature neatly solves those problems and it's easy to limit it only to development builds.

Cheats for ending the normal game greatly helped to test the survival mode, which I wanted to align with the design document. Now the replicators don't send their probes before turn 100, if you manage to end the normal mode before it, and their escalation progression counts from that moment rather than from whenever the survival mode was started. This is mostly to prevent players from building up the economy before entering survival mode but also to not overwhelm players who start the mode early. Another major survival mode change is how replicators move, now their fleets attack a colony that is nearest to their spawn location and then moves toward the center of the map, taking time destroying colonies along the way. Once they reach the center, they stay there, I'll have to come up with something more interesting. Also, replicators now have more varied ship types in the fleet and their tech progression is slower.

Survival mode UI was also improved. Contact list now sorts players by population since the score makes no sense in this mode. Population count is also a good indicator of how long a player can withstand a replicator threat. A moment when a player is eliminated is tracked by the game and game over screen for the survival mode ranks the player in order the managed to stay alive.

Other smaller improvements done during the month:

• Ground defense troop growth speed is tied to the number of factories. Previous constant growth was too fast and messed with bombardment a lot.
• Rebalanced bombardment by increasing base bombardment damage and having chemistry reduce received bombard damage. This way early game when you have a few ships, the bombardment is strong enough but doesn't become overpowered later on. 
• The star with ancient megastructure is guarded by high-tech hostile ships. My favorite strategy for getting an advantage over computer players was to colonize central star early. Admittedly that was super unfair and needed to be nerfed.
• Info sheet raised/lowers state is preserved when ending a turn or rotating a phone. It was annoying to me to have the colony info sheet disappear when ending a turn, every turn. Now I only need to figure out how to keep a fleet selected over turns.

Bug fixes:

• The game ends when a human player is eliminated. It would be an interesting feature to see the computer playing against itself, may I'll implement it in the future. Until it's formally coded, there is no point game going on without a human, both normal mode and survival mode.
• Survival can't be started if a human is eliminated.
  
• Fixed crash when 5 player game ends. An interestingly specific corner case :).
  
• Fixed normal game always giving a maximum reward. For some reason, the reward was determined at the start of the game and updated only when loading a game (when a particular object was recreated).
  

Month of polish

How would have thought that polishing UI would take so much time? Or conversely that there are so many UI components to pass through in such a simple game.

But don't expect fancy graphics and sci-fi fonts just yet. By polish, I meant raising UI from "just enough so it works" to "not an eyesore anymore". This still required checking placing and spacing of elements, adjusting their size, making the stuff that can grow large is scrollable, and repeat all of that for the landscape mode. Yup, you can play the game like a game now! Though I find portrait mode more practical for mobile apps, especially when not seated, stuff just looks nicer in the landscape mode when an app supports it adequately. I'll add some fancy sci-fi look and feel down the road but I have to first decide on a general theme of it.

Along the way, the contacts screen got renamed to diplomacy and made into the list of the known status of all players. It shows your relations with them (peace with uncontacted ones) and a score of all players, including yours. The screen sort of doubles as a leaderboard now.

Qubit spending screen got a little bit of functionality change too. You can't reallocate bonus levels arbitrarily anymore, you can only refund the levels you bought in the current turn.

Global news screen got a bit of controversial update, it shows a banner ad below news text. I'm not a fan of advertisements either but I'm not making this game entirely for free. There will be some monetization in it but I promise there will be no evil schemes. The banner will show only on the news screen, the galaxy map screen will be free of ads forever, and the news screen will not show for minor news if a certain number of turns did not pass since the last news item. Why did I decide to put an ad banner there instead of a more prominent place then? Well in most games a news screen (like GNN in Master of Orion games) is made to look like a funny version of real TV news: anchorman, news text and image in the primary screen area, and some white noise running at the bottom, usually a scrolling text with some jokes. In a way, I've placed an actual advertisement as a joke. Hopefully, you won't find the fact offensive.

There were some minor gameplay changes implemented this month. Restrictions on what you can see on the map are now enforced properly:

• A star needs to be scouted in order to learn its planet size
• A star needs to at least be inside your vision range to know if somebody else has a colony there
• You need to have a fleet at the star to see other's colony population and factory count
• You can only see the immediate next destination of other's fleets, not all waypoints
• As before, other's fleet has to be in vision range to know about it at all
  

And there were some bug fixes too:

• The colonization checkbox won't flip its state when clicking around the map anymore
  
• Another case of a computer player hanging in an infinite loop fixed
• Research progress not working properly after loading game fixed
  

The problem with the colonization checkbox was basically that the Android UI framework, like many other frameworks, doesn't make a distinction between user clicking/taping a checkbox and code setting/clearing check mark. So when selecting one uncolonized star after another, without deselecting or selecting some other type of object in between¸ the UI update logic would inadvertently set the colonization checkbox of a previous star to the state of the next one.

The research progress bug was an interesting one, after loading a game it was possible that multiple research fields (across multiple players!) would get research points simultaneously at the end of a turn. After loading, multiple research fields would share the same research progress describing object so investing points in one of them would advance all with the same object. It was hard to pinpoint down the exact moment when that object would get shared because save file data would look normal (no object sharing) and for no visible reason research loading code would make some objects shared and some distinct. And it was a single line of code on my side manipulating a data structure from a standard library, so a debugger could not step inside and let me see what is going on. After reading the documentation on that data structure (HashMap) very carefully, I've learned it doesn't behave as it does in other programming languages. Java Maps and their subclasses override default equality functions so two maps will show up being the same if their key-values are the same. In C# and other languages, the usual practice for collection's default equality function is to just check if memory addresses (references) are the same and have a separate function for testing item equality. Fortunately, the fix was not that difficult, I only need to change how caching identifies which objects have been loaded and have cache users work with that identifier. Each saved object already had a textual name so I just used that instead of a reference to the object's save data.

Phase two progress

The game development is progressing, a bit slower than the previous year but it is progressing.

I should really make some more descriptive names for the development stages. Phase one, two, three are not descriptive at all, and alpha, beta stages are not applicable. By those labels, the project is still in pre-alpha and will be for some time. Let's call phase one stubbing phase because in that phase all features are technically implemented but with stubbed details. Things that are left out are mostly content, say for "the colony builds ships" feature, the code for building queue and general construction item is written but there is only one ship type to build, just enough to test the feature. Parts of logic that are left out or stubbed are mostly ones that give a game feel but don't affect the structure much. For instance, for the map generation, it's enough for the first phase to have it place player homeworlds at the first few stars in the internal star list and have the proper placement be implemented in the second phase. Consequently, let's call phase two the unstubbing phase, where loose ends from previous phases are addressed and the actual content is added. This phase still has a lot of work to do so I'd add a third phase for fully finishing (polish, test, release) the game.

Stuff done since the last post:

• Game creation settings - map size, player count, human player name, and color
• Players can have one of 7 colors
• Unstubbed map generation
• Map zoom and pan limits
• Different star types
  
• Cyclic building queue
• Factory count can be fractional, like population
  
• 3 combat ship types
• Constrained ship movement
• Pathfinding
• Unstubbed computer player logic
  
• Player scoring
• Players can have custom supplementary data
• Qubit bonus cost increases with level
  
• Graphics (serviceable, needs improvement) for all ship types, factories, and icons on a map screen
• Improved ship movement visuals (not hidden below star when starting, the icon is facing movement direction)
• Graphics for each star type and trait
  
• Decimal number formatting
• Automated tests for utility code, almost all colony features, space combat
• Automated test integrated with repository host's CD/CI pipeline
• Various bug fixes
• Various code refactoring
  
• Design document
• App store listing and release draft

Looks like a lot but it has been 3 months, and real life situation that prevented me from posting updates here also prevented me to do more development. Even after accounting for repurposing blogging time to actual development and hours not reported to a time tracker (prototyping graphics, fill out app store information, writing design doc), time spent on the project has been about 1/3 less than in October and November last year. There was definitely some execution friction too. Having worked for years on the Stareater, I'm very comfortable with the stubbing phase and pure coding. The unstubbing phase feels very different, there are a lot of non-coding tasks and coding too is different. You have to make sure the game logic works for all inputs, not just ensure that code compiles and doesn't crash. This increasing the pressure to have good automated tests which in turn begs to have a thorough document describing which features the game has and how exactly do they work.

Computer player development was an interesting experience. Again, an area I only dipped my toes a little until now. I tried to make a simple implementation of every major area (scouting, colonization, ship movement) but almost all areas quickly grew in complexity. Then I decided to write in plain English words how a bot utilizing all game mechanics should behave and then turn those words into code. 90% of bot logic ended up being information analysis, 8% selecting the proper amount of assets, and 2% actually giving orders. I haven't fully play-tested it yet but it appears to be good at scouting and colonization. Diplomacy logic needs more work, at the moment it doesn't consider who is where on the map so it may declare wars that make sense from a relative strength perspective but not a map situation. Attack staging logic should be improved too because if war breaks out too early it will send ships one by one and just lose them without inflicting any damage.

Adding ship types, star types, and changing movement logic were more of standard coding tasks. New ship types have a rock-scissor-paper relationship when it comes to the space combat cost-effectiveness and they behave a bit differently outside of the combat:

• Battleship - strong against cruisers, expensive, good at bombardment, no movement penalty in a nebula
  
• Destroyer - strong against battleships
• Cruiser - strong against destroyers, no movement penalty in an asteroid field

I'd like to add more galaxy speed to cruisers and something to destroyers but nothing natural to an anti-armor unit comes to mind at the moment. Star types for now only affect ship movement speed when leaving them but there too I'd like to add more later:

• Normal star - no special effect
• Dwarf star - double ship speed
• Giant star - half ship speed, would like to make it have smaller colony size
• Dense asteroids - all ships except cruisers have half speed, would like to add production bonus
• Nebula - all ships except battleships have half speed, would like to add the ability to hide ships

Ship movement modifiers are just the tip of the iceberg of the new movement system. Now ships have a limit to how far they can move at a time but by doing multiple hops they are free to travel anywhere. The hop range is about 2 star distances. The idea is basically taken from tiled tactics games, enemies should not be able to just move through each other without triggering combat but otherwise, the space should be open to interstellar travel.

Introducing multiple ship types invalidated the idea that a warship is implicitly at the end of a building queue because there is now a question about which type of warship. That's why there is a cyclic queue feature, you have to enqueue warships types manually but they will rotate in the queue as they are built. So once you set up desired fleet composition the colony will continually produce it.

At this point, I've regretted not having automated tests. There were multiple combinations of repeating and non-repeating construction projects I had to manually test after every single change to the building queue code and each run would uncover a faulty scenario. Manual testing didn't take so much time, about an hour in total, but I feel like I've aged for a whole day in the process. Making an automated test for a game was a bit of unfamiliar territory for me but it turned out making a minimal game state for a test was an easy thing. In a Java/Kotlin project it is very clear what is a "normal" code and what is a test code so you can have tests reach into what would otherwise be internals of the module and not have the test and test supporting code included in the release build. In the process, I dipped my toes in the CD/CI + Docker fanfare and set up a pipeline on the code repository host that runs tests on every code change upload. Not super useful, especially due to the limited monthly time budget but I learned some cool tech and I can set up something similar locally to trigger on every upload attempt.

Admittedly, code coverage is not that great at the moment. I'd say slightly less than 10% and the thing that needs improving first is how to tell what needs covering. Test framework can calculate line coverage but that's a very flawed measure that at very best overestimates the coverage. Having a branch coverage figure would be much better but ideally, there should be a way to tell how many features are covered. I'm trying to think of something that would do like that but for the time being, I'll have to rely on fallible human brain to sync tests with the design document.

This is the first game, heck first program, I have made a complete design document. It took a few failed attempts on other projects and three on this one. Almost a year before I've started coding Ancient Star, I've drafted a high level design document. From it, I've removed a bunch of features to simplify the game and made another document. But both of them were not really useful so I've made a third one, with low level details, explaining every detail of the game rules. It is 10 pages long, plus table contents covering a whole page height. And this game is supposed to be simple!

Not being an artist I've managed to make some decent looking graphics past few months. Here are star types (the last one being a normal star with the "ancient star" trait):

I'm proud of the result but don't ask me how I made them. Hint: they are coded rather than drawn. Ship images are more of traditional drawing, made in Inkscape, measured, and rewritten to SVG instructions. They are so so, not very pleasant but at least they are distinct. I'll rework them at some point. Here you can see ship images along with other graphics (factory, research, diplomacy, supply icons):

And last non-coding task that is more or less done is apps store listing. All the necessary "paperwork" is done, data is entered and a test release draft (signed app package) is made. I'd still like to do another pass on the long description, make proper a feature image and add more screenshots before hitting a release button for real.

Ancient Star - phase one complete

Diplomacy, vision range, and survival mode are implemented. This concludes phase one of the project where all major game features are implemented in at least rudimentary form. Two weeks ago I wasn't joking about the phase getting nearly over.

Once you get the other player (ship or colony) in your vision range the diplomatic contact is established. From that point, both parties can select the desired relation toward each other. Relations are war, peace, and alliance and the effective one is the worst one the involved parties have selected. If one side has selected peace and the other side wants alliance then the peace will be in effect. So war is the easiest to declare while the alliance requires the will of both sides to ally.

By default, players are at peace and it takes a declaration of war to be able to do any combat action. For now, alliances don't force any relations and military action to third parties. They are purely a peaceful way to end the game. Once every player is in an alliance with each other, the game ends. It sounds cheap but remember, there is a ranking system involved and not everyone will want to end the game while they can still improve their standing.

Once the game ends the player is rewarded with qubits and has an option to start survival mode. Yup, there is a premium currency in the game, and I promise to play nice with it. In the survival mode players fight increasingly stronger waves of enemies coming outside of the map and the goal is to stay alive as long as possible. Also, in this mode qubits can be spent on additional bonuses. For now, the bonuses are bigger industry, ship attack, and ship defense multipliers per technology level.

The next step is phase two, of course :). In the second phase, I'll work on improving the quality of the game, do the preparation work for publication on Google's Play Store, and at the end of the phase have the game available for beta testing.

Ancient Star - basic AI and news screen

With AI infrastructure and news screen, phase one (basic feature implementation) of the project is getting very close to being completed.

Having calculations run in the background and affect UI at the end turned out to be very simple. So now there is AI that controls "bot" players and plays them all in parallel in the background. It has very basic logic for now: build scouts, visit unscouted stars, build colony ships, and colonize everything available. In the future, the logic will be more elaborate and goal oriented.

This required some changes to the code structure. Controller classes players use to read and manipulate the game state have been moved from UI to game core subproject (where game data and game logic is) so in theory, AI can be coded without being a part of an Android application. And the other change was to how a turn is ended. So far the human player had absolute control over the matter but now each player marks their turn as ended. The next turn is processed when all players have ended the turn.

When a certain portion of the map is colonized news screen triggers, informing all players about the event.

 

Again, a simple-looking feature that had more going on under the hood. Now there is a proper concept of player events, uniting tech advances and news items. On a new turn, UI runs through the list of new events, switches to relevant screens, and moves to the galaxy map once all events are cleared.

Ancient Star - autosaving, money, Orion?

The feature "to do" list is getting smaller and smaller. This week three features got implemented: a special star, monetary colony stimulation, and autosaving and continuing a game.

The reason why the game is named the Ancient Star is that there is a special star on a map (for now in the center) which holds remnants of an ancient civilization. Colonizing that star will grant a considerable research bonus to the owner and will be the center of a conflict after the end of a normal game. There is more foundation for future work there, all stars can have a trait and "ancient" is only one of them. In the future there will be more traits, affecting ship movement and colony productivity. I'll come back to this after I implements movement range limits.

Next feature this week: money. Money is gained passively from the population working in factories and can be spent on multiplying colony productivity (both industry and research). For now, numbers are 0.2 credits income per manned factory, and spending 1 credit yields the same amount of industry and research as 1 unit of the population would produce. Money doesn't improve ancient ruins bonus and research during construction. Initially, money can only double colony output but each point of sociology tech improves that multiplier by 10%, exponentially. So later on stimulation can seriously jump-start fledgling colonies. Also stimulating multiple colonies without big enough cash reserve will spend whatever cash there is (tax income + cash reserve) equally over all stimulus receiving colonies. So if you stimulate all of your colonies you'd get a 20% boost.

And finally, I've recovered from serialization burn out and integrated the thing with the rest of the game. Now the game will autosave when you navigate away from the galaxy screen or the game app as a whole. When the autosave file is there, the game can be continued later on.

Ancient Star - game over

Now that there are means to end the game (bombardment and ground combat) it is a good time to make the ending itself.

Many 4X games are about the journey then the destination and some of them tend to have no fanfare at the end because of it. This bugs me more than it should, I like to finish all my games and the lack of acknowledgment at the end feels unsatisfying. That's why I've made it this "early" in my project. It also makes me think more about the overarching question in game design: what is the goal? Usually, 4X games have victory conditions where there can be only one winner, and that in my opinion creates a lot of game design problems. Mainly, if you win by eliminating everyone then the end game is one interesting conflict followed by a long and repetitive mop-up phase. If there are multiple victory conditions then you are likely to get a situation where everyone is playing almost a different game that abruptly ends when someone else reaches their goal.

In the image above you can see players ranked by some score (1, a mock value). Meaning I'm experimenting with something different, instead of trying to be the only winner, players are trying to be ranked as high as possible. I'm also pondering the idea of having a score that doesn't feed directly into military power to have some opportunity cost of being higher ranked. I made a similar system in the Stareater where you directly "sacrifice" your colonies for the score but since the game is not finished yet I still don't know the real downsides to it and I want something less extreme in this game. At first, I thought of using the population as a score but when someone gets eliminated, their population will be zero or, depending on when elimination counts, some low circumstantial value. Also, the population is a direct indicator of economic strength and to an extent military potential. So I thought why not research points? They are the closest to representing the art and culture of a civilization, they are accumulating value so they can't be taken away, and counter-intuitively, having a lot of research doesn't directly indicate a strong military or economy. Heavy research is an investment that trades "now" for "later" and makes you vulnerable in the meantime. 

Anyway, nothing is set in stone yet and a mock score of 1 will stay for a while :).

Ancient Star - ground combat

I'm back to adding features to the Ancient Star, and ground combat is done. Including bombardment and invasion controls UI.

It was a simple feature and I was saving it up when I get burned up with the serialization business. Numbers, for now, are straightforward, each troopship carries one ground combat unit, colony defenders grow by one unit every turn, up to population limit. Combat itself is similar to space combat but with troop attack and defense values being the same.

Ancient Star - serialization

The nice convention about mobile applications is that you can turn them "off" at any moment and continue where you've left off later. Yeah, some apps don't work that way but developers are generally encouraged to make apps tolerant to being paused and resumed at any moment. In order to pull this off in the Ancient Star I need a solid system for saving and loading game data.

There are other things to do to make an app lifecycle aware (handle pausing, stopping, and resuming) but Android SDK does a very good job of covering the usual parts. Built-in UI components take care of themselves, custom components (like one where galaxy map is drawn) are fairly easy to make persistent and it's easy to move data around in a lifecycle aware manner. But in comparison getting game data into a format that can be written to a file and back is significantly more work. You might be fooled by built-in JSON converter and open source solutions that this is an already solved problem but I haven't found a solution with both low maintenance overhead and the ability to cope with complex data structures.

When serializing data there are two parts of the process, picking up data from objects and converting data. Think of it as answering "what" and "how" questions. Serializers like built-in Android one expect from app developer to answer "what" question so the code ends up handling the same piece of an object in three different places: declaration, serialization, and deserialization. This incurs considerable code maintenance overhead. Whenever you add a new data member to an object, you have to remember to include it in serialization and deserialization functions. Forgetting to do so is still legal code, the compiler will not complain about it and the app might run for a good while until the issue becomes apparent. And even then it's not trivial to figure out which member did have you forgotten to serialize or deserialize. Better libraries ask you only to put a special annotation next to member declaration so it is very easy to keep serialization coverage in sync with the actual object structure.

As long the structure is simple (tree). Such serializers work by dereferencing each reference and embedding values behind it inside the object that held the reference. So if there is an object referenced by multiple objects its data will get serialized multiple times, producing unnecessary data duplication in a save file, and what is worse, deserialization would not be able to deduplicate it, potentially producing a faulty game state. Cyclical references are even worse, they'll make a serializer run in an infinite loop. And it's easy to have data with such structures. For instance, in the Ancient Star, each Star object can have a reference to a Colony object, Colony has a reference to a Player who owns it and the Player has a list of scouted Stars. That's an example of both a cycle and multiple references to the same Player object since each colony references its owner. It is possible to swap direct references with indirect ones and make data simpler in the eyes of a serializer but it comes with the price of more complicated code. And besides, in the Stareater I did develop a serializer that both utilizes annotations and can work with complex reference networks.

The first "trick" I used there is to have the serializer make indirect references out of real ones. It generates a unique "name" for each object and references are substituted with those names. The second "trick" was to gradually build a reference network while deserializing, similar to how in the normal course of the game the complexity of data gradually increases. For instance, initially, stars don't have colonies, are not scouted, and during the game each player scouts and colonize more and more stars. Similarly, the deserializer can first create objects with only bare necessary data (primitives and references required by a constructor) and fill them with remaining data in the second pass. So how long it took to port the code from the Stareater? 30% of the total development time so far!

I expected it would take some time because I wanted to learn and use Java's annotation processor stack for code generation but I expected it to take half as much. Stareater is written in C# and runs on .Net (CRL actually) while Ancient Star runs in Java Virtual Machine (or something close to it). Certain metadata (generic parameters) which is available in CRL is not available in JVM and Stareater code depends on it. I didn't know that until I ported most of the code and give it a spin. I had to scrap and rebuild the serialization code two more times until I arrived at a workable solution. It was a frustrating road but I'm glad I have done it. It will pay off in the future.

Ancient Star - introduction

Wouldn't it be awesome to have a 4X game on a phone? Now that I mention it, yes? Then I recommend Uciana, it's worth the price. It's so easy to turn on while on break, play a turn or ten, turn it off, and continue later. Do you need more such games? Well, Ancient Star is going to be one.

The ambition level for the Ancient Star project is to make a simple game, akin to Master of Orion 1, but unlike Stareater, to have a complete product. Published by the end of the year, with working AI and multiplayer. That's right, completed, and published in two months. Or at least have a beta version by then. I've been developing it for two months already and about 75% of core game logic is finished. When the app as a whole is considered (UI polish, graphics, writing, AI, multiplayer, tests, publishing), the completion level is about 45%. Here is how looks at the moment:

Galaxy map functions similar to Google Maps map, pan by dragging with one finger, zoom by pinching with two fingers, tap to get information about an object in the panel at the bottom. Colony management is a simple focus setting and a building queue. Features implemented so far:

• Colony development
• Ship construction
• Fleet movement
  
• Colonization
  
• Space combat
• Bombardment
• Turn reports

For now, graphics are minimal, either stock Android SDK images or basic shapes, UI is not styled, and so on. The idea is to get core game features in and then work on polish and visuals. Hopefully, that second phase will come soon, at the end of this month. Stay tuned for more development news about Ancient Star on this blog.

Master of Orion II - missiles

Master of Orion II is an old, old game. It was released in 1996 but people still play it and await for worthy successor. One reason why fans still play MoO II is a deep and meaningful customization. Like in AAA "RPGs" (quotes because role play games get confused with "whatever has experience bars and level ups"), before the game starts player can spend an hour picking traits for his/hers race and empire. Many traits add or remove game mechanics such as lithovore: race doesn't need food or telepathic: empire can mind control colonies. When the game starts every few turns, depending on empire's research output, player has to choose one of the two or three mutually exclusive technologies (or take all is the empire has certain trait). This choices heavily influences which tools will player have at his/her disposal, much like deck building in CCGs. And finally, player can design combat units. I can't even start to explain how much game defining it is and considering the topic I presume you, dear reader, have played the game and are familiar with most of it's feature. If you haven't played it, please do, you can get it from GoG.com for 5$.

Every now and then I find new "build" I haven't tried so far. It sounds unbelievable considering that I play the game for many years (I'm not disclosing how many :)) but I was noob back then and only used one strategy, playing turtle until I got all technologies and then unleash invincible fleet on everyone. Last few years I was trying new stuff, diplomatic race, spy race, uncreative race, empire with heavy money generation bonuses, limiting my self to only the smallest ships and so on... Recently I've tried limiting my self on using weapons other then beams. It was surprising, I had no idea interceptors are so strong in early and mid game. So in the last game I excluded special weapons too, only missiles and bombs were allowed. It was fun and tense at first but AIs were not developing well so it became too easy. They managed to keep pace with armor upgrades but by turn 350 nobody managed to get anything beyond class I shields. Still, I managed to experience new stuff. Having no beam weapons leaves ships free from beam enhancing equipment and frees up nice amount of research points. I've used those points to speed up research of chemistry (better missiles, armor and ship range) and construction, to get automated repair sooner. You see where I was going, high quality armor and self repair equals invincible ship. Unless enemy has ion cannon and it so happened that AI was good enough to get it and bad enough get any better beam weapon for a long time. I was invincible in ship to ship combat but assaulting planet required some fancy footwork in order to have shielded part of the ship facing star base when it was about to fire ion cannon.

After reaching the end of chemistry techs, I've switched to power in order to try out torpedoes. Torpedoes are interesting weapons but in my opinion too high in tech "tree". Antimatter torpedo is OK, easily accessible for mid to late game. By the time proton torpedo becomes usable the game is almost over. Same holds for plasma torpedo that is very last technology in power field. As I said I was facing underdeveloped AIs so it was not fun upgrading torpedoes when antimatter was more then enough for the job. One the bright side, researching torpedoes gives player opportunity to get energy absorber which is great addition to ships designed around taking hits instead avoiding them. Combine it with hard shields and damage reduction will be so high that all but late game weapons would become ineffective.

I've finished the game by attacking Antares and I did it twice, separately with torpedoes and with missiles. Those two roads were very different. Torpedoes were reliable on doing the job given enough time, in fact I had to attack Antares twice with torpedo ships because I reached turn limit first time. I did some bad moves and star fortress managed to shoot down 5 out of 6 ships and the last one didn't have enough fire power to destroy it within 50 combat turns. I could have brought more ships but I wanted to give some chance to Antarans :). Anyway, going with missiles was a gamble, missiles can be destroyed before doing damage and the ammunition is limited so it was possible end up in situation where ships have to retreat because they can't attack any more. I brought extra ships, just in case. With missiles it's either overkill or stalemate and aside from EMG they aren't that interesting. Unlike torpedoes, missile have no twist, they just do damage and higher missile technologies are simply damage upgrades. That is somewhat spiced by EMG, a missile modification that applies damage directly to target's engines if it's shields are down. Unlike armor, engines have very few hit points and if they are destroyed the ship self-destructs. To balance that EMG greatly increases missile size. But AI was not challenging enough to give me opportunity to try it out...

All in all there is material for another playthrough. Maybe this time with smaller ships and no creative trait. Yep, Master of Orion II is still play worthy.

Achievementi

Nekoć davno su igre imale isključivo bodove kao mjerilo igračeve vještine. Danas su to mjerilo postali achievementi. Ako se igra distribuira preko Steama, jednostavno mora imati achievemente. Zanimljivo je promatrati kakve sve ideje ljudi imaju za achievemente, bedževe i ostale unlockable stvari. Ali ima par stvari koje mi se ne sviđaju i na koje bih se osvrnuo.
 
Achievementi za puku činjenicu da igrač igra igru. To su achievementi tipa "završi igru", "skupi x toga i toga", "uništi y neprijatelja". Te stvari uopće nisu dostignuća, ne odražavaju igračev trud (s time da ponavljanje jednostavnih radnji milijun puta ne smatram trudom). Ipak govorimo o igrama a ne o poslovima u stvarnom životu. Isto tako ne prihvaćam achievemente tipa "pokupi rijetki random drop" kao dostignuća jer je riječ o šansi koja nema veze s igračevom vještinom.

Po mom mišljenu achievementi bi se trebali otključavati na akcije koje ne spadaju pod regularno igranje igre i iziskuju dodatan trud od igrača. Npr. završavanje neke misije bez primanja štete ili prelazak nekog dijela nivoa na teži način i sl.

Zvjezdojedac, planovi za verziju 0.4

Ukratko stavke za slijedeću verziju Zvijezdojeca su slijedeće:

• Upravljanje na razini zvjezdanog sustava
• Umjetna inteligencija za upravljanje kolonijama
• Svemirske bitke
• Preinaka prikaza informacija za kolonije
• Prikaz liste kolonija
• (Možda) Preinaka varijabli za formule da budu strong typed

Upravljanje na razini zvjezdanog sustava

Kao što sam napisao u prošlom postu, maknu bih podjelu gradnje na civilnu i vojnu i napravio bih da se brodovi grade na razini cijelog zvjezdanog sustava. Nešto slično kao u prvom Master of Orionu. Na svakoj koloniji bi se moglo odrediti koliko se sredstava odvaja za projekte na razini sustava a upravljanje redom gradnje bi se vršilo na sučelju koje je trenutno prikazuje informacije o zvijezdi i popis planeta.

Umjetna inteligencija za upravljanje kolonijama

Globalni plan za UI je da se upravljanje razlomi na razine. Prva razina bi bila glavna mapa. Algoritam bi određivao koliko je pojedini sustav u posjedu ugrožen i kolko su ostali sustavi pogodni za istraživanje i naseljavanje. Na temelju tih informacija bi se slali brodovi i određivala tendencija gradnje brodova. Druga razina bi bila pojedinačni zvjezdani sustavi. Algoritam bi za tu razinu na temelju informacija s prve razine određivao što će se graditi na razini sustava (da li ratni brodovi, da li kolonizatori ili poboljšanja za planete). Također, na toj razini bi se određivala tendencija ulaganja u zvijezdani sustav tj.  koliko će kolonije odvajati sredstva za sustav a koliko za sebe. Treća i najniža razina bi upravljala samim kolonijama. Znači, što kolonije grade i koliko u što ulažu.

Za početak napravio bih nešto jednostavno, UI koji će razvijati svaku koloniju kao da je sama svemiru. I dodato bih neki jednostavan algoritam za drugu razinu kako bi računalni protivnici gradili brodove za testiranje bitaka.

Svemirske bitke

Najsočniji dio svake igre. Trebam još definirati kako će se koji atribut ponašati. Imam neke ideje ali moram ih još uskladiti. O tome više kada ova stavka dođe na red.

Preinaka prikaza informacija za kolonije

Trenutni prikaz mi se čini kao da prikazuje previše informacija odjedanput. Htio bih napraviti sučelje na kojem se na prvi pogled može vidjeti koliko je koja kolonija razvijena i produktivna a da se do detaljnijih informacija može doći kada se miš pozicionira iznad pojedine stavke (Civilization 4) ili na klik (desni klik u Master of Orionu 2). Time bih dobio više mjesta za prikaz detaljnih informacija i izračuna kako je koja brojka dobivena i na sučelju za kratki pregled, ne bih morao prikazivat puno toga.

Prikaz liste kolonija


Nekoć davno 4X strategije sam igrao na način da bi svaki krug zavirio u svaki grad/koloniju i gledao da li mogu što poboljšati. Takvi turnovi su znali potrajati i po 10 minuta. S vremenom sam se naučio kako se većina micromanagmenta može izvesti preko popisa kolonija (Master of Orion) odnosno gradova (Civilization 3). Kod takvog pristupa, turnovi traju pola minute. Moć popisa kolonija zasniva se na prikazu bitnih informacija i načinu sortiranja stavki. Dobar popis kolonija treba biti u stanju odgovarati na upite dosta visoke razine, kao npr. "koje kolonije su dobre za izgradnju brodova?" ili "koje se kolonije još trebaju razvijati".

Za početak ću napraviti jednostavnu listu s nazivom kolonije, populacijom, procjenom razvijenosti i nazivom zgrade u gradnji i s mogućnošću sortiranja po tim svojstvima.

Preinaka varijabli za formule da budu strong typed


Ovo više finesa ispod haube. Ideja je da od <string, double> hash tablica u kojima se može nalaziti sve i svašta, napravim singleton razred u kojem će za svaku varijablu u igri postojati članska varijabla. Prednosti takvog pristupa su da ću imati jedno mjesto na kojem će varijable biti hijerarhiski poslagane, neću morati izvoditi finese s nazivima varijabli (trenutno skoro svaka varijabla ima za svoj naziv const string da ne moram rovat po kodu i prepisivati), možda će biti brže, ne ću morati instancirati toliko dictionary<string, double> objekata i biti će manje parametara u metodama za izračun vrijednosti formula.

Uglavnom, uz par velikih djelova gameplaya ova verzija će biti više fokusirana na fluidnost sučelja. Nadam se da ću je dovršiti do kraja godine a ako Bog da, u roku 2 mjeseca. I da ću po implementiranim featureima prestići FreeOrion :)

Zvjezdojedac v0.3

Konačno, nakon skoro godinu dana, dovrših verziju 0.3 Zvjezdojedaca. Stvari koje su nove u toj verziji su:

• Lokalizacija
• Pomicanje brodova
• Podešavanje veličine GUIa
• "Knjižnica" (prikaz istraženih tehnologija i dostupnih komponenti za brodove)
• Migracija populacije
• Odabir početne populacije

Od navedenih, najviše sam se namučio s lokalizacijom, mislim da sam tjedana dana radio na tome. Al mislim da je to feature koji trenutno najviše doprinosi pristupačnosti igre široj publici. Naime, do sada je igra bila isključivo na hrvatskom.

Mogućnost pomicanja brodova je najznačajniji feature što se tiće igrivosti. To sam napravio praktički u 2 dana (po sat - dva svaki dan). I još sam se najviše namučio radeći na GUIu. I naravno da nisam zadovoljan sa  sučeljem.

Migracija populacije je malo manje značajan feature ali sa značajnim posljedicama. Naime, za implementaciju migracije, dodao sam efekte na razini zvjezdanog sustava (npr. ukupan broj ljudi koji se može seliti unutar sustava) što će kasnije omogućavati fensi mogućnosti kao npr. sustav za preusmjeravanje zračenja s jednog planeta na drugi kako bi se povećala temperatura na planetima koji su daleko od matične zvijezde. Općenito mislim neke stvari maknuti s planeta i staviti na razinu cijelog sustava. Jedna od većih ideja je maknuti podjelu gradnje na civilnu i vojnu i napraviti svi planeti u sustavu sudjeluju u gradnji brodova. Nešto u stilu posebnog building queuea za sustav i da se na svakoj koloniji može odrediti koliko resursa se izdvaja za taj building queue.

Odabir početne populacije je isto mali feature s velikim posljedicama. Naime, taj feature me natjerao da preinačim kalkulacije vezane za uvjete na planetu. Morat ću si jedonom sve te formule staviti na jedno mjesto i mic po mic ih podešavati. Bit će dosta posla za slijedeću verziju. Budem sutra razmišljao što ću sve raditi u verziji 0.4.