More invasion!

Applying the concepts in CMPUT 174, I’ve gotten to an “alpha” version of a popular arcade game. My version, Alien Invasion, is still a work-in-progress but has basic functionality. I suppose it is the minimum-viable-product version of this sort of arcade game.

I definitely enjoyed the process. There are a few features that I’d like to add if I can find some time.

• Explosion graphics when an alien/building is destroyed
• Player-owned buildings (that must survive)
• Aliens that can shoot (they are implemented as flashing objects but the shooting / damage effects are not implemented yet)
• Turret objects that “shoot” laser pulses when a shot registers and track the position of the cursor

I think I might be able to get a few more done before the next term starts and I run out of time.

Here are some lessons learned:

• Code can be re-factored with minor hassles but variable/attributes need to be watched very closely
• Code organization is a mess. The placement does matter in python, because it does a first-to-last interpretation of the code as written, but methods etc. can be rearranged at will within a class, finding a decent organization of those methods is maddening…
• Github is an interesting and useful tool to track changes. I experimented with a main and an alpha branch to track and deal with commits, and when I am satisfied I will do a merge and see what happens there.
• Github is one solution that I’ve decided to use for coding projects; and I use SVN for this webpage, in order to keep up with different (similar) solutions.
• Classes take a bit of thinking and planning during creation. The hardest part is anticipating the needs for a class; what attributes are needed? What kind of methods will handle different aspects of the class? What needs to be in an __init__ function and what can be external?
• Time expenditure total is tough to pin down but I would say an average bug-fix takes maybe an hour or two, a method takes about 3-4 hours, and setting up git, doing a web update, doing some other changes takes another hour. This includes research, checking up on built-ins or other library documentation, creating comments, playtesting and making incremental changes, etc.

In all I would say this has taken about 5 full days of work to get to this point; which is the longest I have worked on a programming specific project so far.

Here’s the MVP version, soon to be released on github!