May Progress Update

Edit: Didn’t quite manage to finish everything today, so release will be tomorrow (Friday), or on Monday at the latest.

The game mechanics, API and graphics for CodingGame are starting to look decent, and I am now ramping up for an alpha release on June 11. Until then, I will be tying up various loose ends and complete the following remaining tasks:

  • Replays: I want to add functionality for automatically saving all the commands issued to the game units to a file. These can then be replayed later to perfectly recreate the game. Among other uses, this will be invaluable for bug reports.
  • Community: I want to set up one or more mechanisms to allow for submission of bug reports, discussion of the game mechanics, sharing of replays etc. I am thinking something like a google group, but I’ll have to do some research to see whether there aren’t any better options. If you have any suggestion, let me know.
  • Documentation: There probably should be at least some description of the game mechanics and API.

What happens after the release depends a bit on how many people actually try out the alpha version, but the basic idea is to go through several iterations of receiving feedback and improving the gameplay. In parallel to that, I will be able to start work on setting up a website with tutorials and documentation and implementing multiplayer.

The graphic design for CodingGame

In this post, I will go into some more detail about the graphics in CodingGame.

In my opinion, the main purpose of the graphics is to make it as easy as possible to see what’s going on in the game. I want the graphics to be a one-to-one reflection of the game state. All game objects and their attributes have a graphical representation and all world state transitions are highlighted by an animation. The amount of graphical elements that do not serve a function in the game and convey no useful information is minimized.

At least in principle, this should make it possible to get a feel for the game and even infer all of the game mechanics just from watching the game, making it unnecessary to consult pages and pages of documentation. It should also make the game more fun to watch for people who don’t already have intricate knowledge of the game mechanics.

In accordance with this goal, I am using an abstract/minimalist design where all the game objects are composed from simple geometric shapes. This also allows me to generate all of the graphics programatically, which plays to my strengths and gives a lot of flexibility. In terms of the art style, I am aiming for a sci-fi/space theme that features mostly dark colors with a few very bright elements.

Anyway, I promised screenshots, so let’s get to it!
The game units come in different sizes, their body is simply represented by a regular polygon:

drone_body

These are then filled with all the modules equipped by the unit.

Here are all current module graphics (all inside a size 1 unit):

Engines

module_engines

Shield generator

module_shields

Empty storage

module_storage

Storage with mineral crystal

module_storage_crystal

Storage with energy globes

module_storage_energy

Factory

module_factory

Weapon

module_lasers

A larger unit with several modules:

drone_large

Some additional objects:

Mineral crystals

mineral_crystals

Laser missiles

missiles

A screenshot with a larger scene (very large image, click through for zoom):

scene_large

In other news, the collision detection and physics for CodingGame is now really solid, and I have made a lot of progress on integrating all the components and implementing the game mechanics and API. I can’t promise anything for sure, but if things keep going smoothly I should be able to release an alpha version in about a month. Before then, I plan to write another blogpost to describe my ideas for the game mechanics in some more detail.