About this blog
Just some ramblings of another hobby game developer
Entries in this blog
So this weekend (Still working on the power system by the way) -- I side-tracked a bit and started playing Minecraft some more. I like that game. Anyway, I figured it'd be a fun diversion to making a server mod with the "Bukkit" API
Since I just added disasters to the game I'm working on, I went ahead and added something similar. Here's an attempt at adding tornadoes to Minecraft:
It kind of looks like one ... It's really just a bunch of explosions that go off each second. There are also different sizes of tornado, damage, life time, etc.
I divided it up into three parts:
A Tornado class -- this is just a normal class that holds the information like location. It also has the code to spawn the explosions and update its remaining lifetime.
TornadoUpdater -- Tracks all of the tornadoes in the game and updates their states, removing them if they've "died."
TornadoMod -- serves as an entry point.
Right now it just spawns vi a command, but I Hope to get them spawning during thunder storms at some point...
I've been working on adding a "power" system to the game. I'd say powering buildings is a pretty fundamental task in a modern city building game, but I never included it for some reason.
Well, now I am! Part of the reason is that all of the code for it is written in C# and so it provides an excellent task to really test the interop abilities with VB6. The other reason I like it is because the "power simulator" as I call it is very unit testable.
I'm a fan of unit testing -- in the last project I worked on with a friend we had a pretty extensive test suite and maintained ~70% code coverage, and we had the tests run by the build server we set up. Anyway, I do try and test the more "logical" parts of the game. This power system is a perfect example -- here are some of the scenarios you can test:
- there should be unpowered buildings when the demand exceeds the supply
- there could be excess power, but one of the power plants may not be connected. At which point, the buildings should not receive power.
- all of the buildings adjacent to the power plant are powered
- a building that is connected to a powered building is not considered powered (must be connected to power lines)In addition, it's much easier to test this isolated than it is trying to try it out in the game. An even more important benefit is that it allowed me to write the simulation part while holding off on allowing the user to construct power lines. That's what will be coming next actually.. For the moment, there are just a bunch of unpowered buildings:
Here is what the unit test suite for the game currently looks like (keep in mind I just started extending it with C# a few weeks ago):
Last time I told you about my workflow for adding new units to the game. Well, before I talk about anything else, I have to make a few confessions:
I mentioned that I started the game 3-4 years ago and just recently dusted it off. One of the bad things about working on it is that the code sucks (I think all my code older than 1 month sucks).
But this code sucks more than normal. There are a couple reasons for this. The first is that it's written in VB6. That's not inherently bad, just the OO support is very lacking, and I can't unit test it easily. For the game itself there are about 31k lines of code. "That's not too bad!" you say. Practically nothing.
Except it's all in one source file.
Let's just say I've learned a lot since then. But before that, I hadn't worked on anything greater than say, 5k lines. So I dumped it all in one VB6 .frm file. Later additions added some separate files, but the OO model is still crappy. So I still have a 31k line source file.
Now you can see why I hesitated to dust it off over the years!
Why go back to it now instead of just dumping it and starting something new? Well, it's actually a pretty complete game. In fact, when I quit working on it the only thing I had left was some AI and more art work. I also like challenges. But don't worry, if the only way to extend it was writing more VB6 code in that file I would never work on it. And in fact I haven't worked on it for a couple years.
Luckily, I've been able to use .NET's COM interop support to write C# code that extends the game. In fact, the only VB code I've written is to provide more extensibility to C# objects. There are some quirks that require work-arounds (such as the fact that there are a slew of private types embedded in the form that I can't move), but I'm still managing along.
So now I'm able to write C# code for the game without touching the original VB6 code base, except to add more support. This is good, because it means I can:
- Write good, clean, modern OO code in C#
- Unit test game logic
- Gradually migrate VB6 code to C#
- Minimize the amount of new VB6 code
As you can probably tell, this project really is just for fun. I probably won't ever finish it, just keep adding to it as I see fit. But it's something that I like working on in-between projects.
Next time I'll show you the workflow for adding new, tested C# code to the game and wiring it up to the old code base.
Today I'm going to share with you how I keep track of things and work on the game. It all starts with issue tracking, because I like to track the progress I've made so I don't get demotivated.
For issue tracking I've been using a free hosted issue tracker called Unfuddle. It also provides source code hosting for SVN and Git projects, but I don't use either of those for this project (I'm using Mercurial).
Here's an example of my task list, this one is for the "Tornados" implementation (I'll share more about my current tasks later):
Once there is a task in the tracker, it's time to implement it. I'll just choose the task to generate the "small tornado animation." I'm not really an artist, but I've been using Blender for all modelling needs.
In blender, I have a base model for the tornado and then have a particle system attached to it. The mesh rotates over ~100 frames. Here's the model:
To generate the animation, I run a python script that moves a camera in 45 degree rotations for each animation frame (I only render 1 in 7 frames for the in-game animation). This generates a list of images for each frame and rotation.
Using a small C# program I wrote (mostly as a learning experience), the images are combined to yield a final animation. Here the tornado only has one rotation angle so there's only one row of animation:
Next: I add an entry to the gamedata file that describes a frame of animation, the interval, and other things like that. Nothing too exciting here. The animation is now loaded by the game.
The next step is to add a unit that will use the tornado animation. The unit is classified as a flying unit, so it's rendered on top of buildings. Again, this is just editing a text file so nothing worth showing. But at this point, I can add the unit in-game:
The last part is to commit the changes to the Mercurial repository. No code has been written but what's getting committed is the animation image and the game data file changes. By the way, I'm using a hosted Mercurial repository on Bitbucket. I've been using the service for about 9 months now and have no complaints (and it's free).
I'm not sure how exciting the revision graph is, but here it is:
You can see I sometimes branch out -- I tend to switch between to machines to develop on (desktop and laptop) and sometimes I don't have internet access.
Well, that's all for now. Next time I'll show you some code changes.