I haven’t much done games – as in programming them! During 1990s I did one, called ‘Space Shrapnel’ (finnish Avaruusromua), where a spacecraft has to be navigated through a random asteroid field – a side scrolling action game. Although a very simple game, it was quite much fun doing it!

I wrote the game in Commodore 64 BASIC. Designed a sprite, bound the keyboard controls to the spacecraft; added a scrolling background with character-mapped graphics. That was it. Some 200-300 lines of Commodore BASIC language. There was naturally also a “epic” (hmrhmhm….) background tune – but I refuse to talk about the merits there.

Thus this was my thinking one day: let’s grab some Python and do a proper game!

I think part of the reason that I’m really bad at implementing games, is due to the fact that I tend to over-engineer plans, while leaving the rote coding astray in hobby projects. Coding is hard, you know! It’s time to change that.

Python is one of the programming languages I have had a keen interest on learning. I’d done some “mainly read, some writing” of 3D scene importing scripts (for Blender 3D software).

Yet Python remained a bit distant as a casual language for making any standalone project – things that could really stand on their own, and be executed independently.

Battle sim in Python, day 1 (17.8.2019)

I wrote a piece of program to represent “armies”. I want to push armies against each other, one on one. The armies are represented as stats, a bunch of numeric data, and then the battle algorithm – along with a bit of chance – determines outcomes of individual clashes.

At first they only had:

• person count (soldiers)
• offensive strength score 0-100
• defensive strength score 0-100

Naturally that wouldn’t suffice. If actual battles were to be simulated, the armies would have casualties! So maybe it would be proper to record number of soldiers who went KIA, killed-in-action.

At this point my code was around 100 lines of Python. Some structures, initializing routines (“constructors”) for the armies; a bit of boilerplate, and whimsical plans for development, thrown in as inline comments within the code. The typical startup.

I couldn’t yet run the code. In a way the ability to run code would give something to grab: when you can get into that legendary “loop”, things usually look much brighter. Getting to the loop as soon as possible can be considered a modern cornerstone of agile development.

It was time to amend this and make a version that would run, print out at least some signs of life; and then terminate. I’d be quite happy with that as the first day tour of duty.

Language details: Python 3 and data structures

• arrays
• dict
• what’s missing?
• what are the batteries-included in Python 3, without using ‘import’ statements?
• everything is now a properly formatted function
• Python 2 was a bit ‘scriptish’, Python 3 is more formal

I split the initialization of the Battle Sim to constructor functions. They set data in the “army” variables. Python has a dict which suits well representing a record like an army: you have key-value pairs in the dict. By making a contract with yourself, that for example