Well, my last attempt to get a game going was for the November MiniLD. It failed; I tried to go back to Stencyl for one more “quick hacked-together game”, but it quickly lost my attention. Not manipulating the underlying code… I just feel kind of unattached to my game when working in Stencyl. As programmers, we often accept and welcome some level of abstraction. For you non-techies, that means we are OK with some program/library doing some of the highly-involved, low-level grunt work for us. A lot of games use music, but most game designers don’t need to write their own custom music streaming code. But to me, Stenycl “abstracts” or takes too much control out of my hands, or at least seems to make it difficult to move around different pieces of the engine to my liking.
However, I have started writing code for my next game in Python! Ah, feels great to get back to my roots!
So what happened is I ended up visiting the “One Game A Month” website and got hit with an idea by their theme of the month (theme = “change”). One concept I’d been throwing around in my head was to make a game that was simple to grasp and play but still equipped with a moderate level of complexity. In other words, its the kind of game so easy to understand my younger sibling could play it but it has nuances to it that will potentially amuse and engage the more seasoned gamer. The game idea I have may not have bone-crushing difficulty, but I still see potential for an overall fun game! Just trust me. 🙂
To put it concisely, it’s a strategy combat game. Past that, I won’t go into too much detail right now. I want to save some thunder for later. For now, let’s just call this new combat mechanic I’ve come up with the “2 + 1” system. What does that mean? I’ll let you ponder that one. Hehe…
I’m going with minimal planning since my timeframe optimally has me finishing the game at the end of the month. I did end up going through a couple design concepts before I made a decision, but I think the general idea that I’ve settled on will play well to the “2 + 1” combat mechanic. Still some potential kinks to work out, but hey.
Let’s Code
As for the coding, a simpler-style game means simpler-code, right? Well, maybe not. But on the other hand, it made me think about code structure and how to keep things simple. I think sometimes as game designers, we look at a finished product or game we’ve played and don’t necessarily see it completely for the sum of its parts. That menu you see there? Is that a menu object, or is that actually multiple pieces working together? When you view stats of a character, are those stats all coming from the same place, or are they being pulled from separate functionalities based on where they are most relevant?
For example: I decided to start with the basics: let’s hammer out a basic attack system. Attack with a certain power, defend against it with a defense stat, and lose HP. That’s a process we see a lot. But it occurred to me when I was hashing things out: when does one unit’s attack and defense stats really care about each other? A unit’s attack is concerned with the enemy’s defense, but what about its own? When your unit is the one being attacked, we need things like defense and HP, but not typically attack. I then concluded that it made sense to write up the offensive and defensive code as separate sections with their respective stats. The higher-level entity of the unit would be responsible for knowing which one to use and when (am I attacking or being attacked?). It’s just an interesting observation; we get so used to seeing things together in games that one might assume that they all belong to one big central glob of code under the hood. Is that really the case?
So I went to work writing the StatsDefense class for my game that would handle basic defense and health actions. Upon finishing version 0.1, testing it, and ironing out some bugs, it was probably a good 3-5 hour piece of work involving roughly 80 lines of Python code plus documentation. Whew! Good reminder of how involving this stuff can be. Quick summary:
- facilitation of HP modifications through damage, healing, and reviving by accepting an outside value
- HP modifications based on a damage algorithm, fixed value, or as a percentage of max health
- the ability to define your own damage algorithm and inject it in
- a simple Boolean “alive” that is monitored and managed for the purpose of checking an entity’s status
I still have a few things to iron out, but the code appears to be working well from what I can tell. It’s a basic functionality class, so there’s the ability to build off it the way I want and the possibility for re-use and extension later. I coded up a quick “Unbeatable Robot” text-game to test it out, where you attack the robot and, despite your best efforts, he heals himself, increases his defense, and will revive himself when he hits 0 HP! Perhaps 4 is the only viable option below…
Its working! (Note: strong defense is always 5, so that’s why you see no change when it says the robot takes on “strong defense”. He already had previously. It’s not a bug!)
So that’s all for right now. It’s nice to see things coming together so far, even if its simple stuff. Stay tuned for updates on this new game, the “2 + 1” mechanic, and more!
Photon Game Development 
Leave a Reply