Pages

Wednesday, March 31, 2021

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.