Brainfold On Python, game development and everything

30Jun/08Off

Bullet through the wall

My work with the entity system is pretty much finished for now. Everything seems to be finally working and the code is reasonably clean. I don't want to get stuck polishing the code while it's still missing most of the planned features. I didn't get to gameplay / user interface stuff yet, but I hope to do so next week. Time to get something concrete done for a change.

I did run into some problems with collision detection though. Shells that are fired travel relatively fast compared to their size, which leads to the infamous bullet-through-wall effect when they collide with ground. In other words: they go straight through it. I tried fixing this both by making the terrain collision shape consist of polygons instead of line segments, and decreasing the step size so that shells wouldn't jump over the line segments. Both of these were too much for pymunk though, and the game ground to a halt. Note this isn't a problem with Python either, since all the physics number crunching is done in C code.

I now have a couple of options. First, I'll try pyBox2d, based on the Box2D physics library (which chipmunk is based on, which pymunk is based on...) Box2D has continuous collision detection, meaning that objects can't jump through each other between steps, but the pyBox2d bindings are based on SWIG, which is much slower than ctypes, so it might have performance problems of its own... Additionally, I just (literally a minute ago) stumbled on Elements, which is another Python 2D physics library based on Box2D, so I'll take a look at that as well. A backup plan is faking continuous collision detection by making the collision shapes of shells longer than they actually are. Because the action in Artillery Brawl isn't very dynamic, this shouldn't cause any noticable errors in collision detection, but I'll have to see about that if I'm not satisfied with pyBox2d.

EDIT: At least these results look promising for Box2d.

29Jun/08Off

Final stretch

Yet more entities

The entity system overhaul is almost finished. Everything looks all right now, but doesn't really behave... there must still be some bugs left in the physics system. I'll concentrate on bug hunting and cleanup tomorrow, and hope to get to gameplay as well, next week if not tomorrow. It's really nice to have some real progress for a change.

Architecture

As every programmer knows, or at least should know, program architecture is a hard subject. Really hard. A lot of my development time during the last couple of days has been spent thinking about the perfect architecture for parts of my entity system. I want to get this at least mostly right this time to avoid having to make huge, sweeping changes again in the future (like I'm doing now, but with a relatively small codebase). I feel I have succeeded quite well, with a couple of minor warts I'm going to remedy at some point in the future.

More issue tracking

Today, I wasted an hour or two trying to install Roundup. To my surprise, it got stuck trying to initialize the database, the same problem I had with Trac yesterday. Digging into the problem a bit deeper, it seems sqlite (or its Python bindings) is to blame! Specifically, it dies, claiming that the database is already locked. That means I might give Trac another chance if I get the sqlite problem sorted out, or maybe I should just try to use Roundup with another database backend. I gave up on issue tracking for now though, so more on that later.

28Jun/08Off

Entities ahoy!

Entity system

Today I've continued work under the hood, on the entity system. Both components and entity types are now loaded using the plugin / entry point system of setuptools, which means custom components and units will be really easy to create and distribute. And much easier for me to load. :) I have a habit of making too many sweeping changes to code at once, and this is no exception. On the other hand, this does result in massive improvements to the entity system and especially creation of entity type files, so it's all for the greater good.

No screenshots to show for my efforts, but see the end of the post for examples of what entity type files currently look like. This might change before these changes are completed.

Entity editor

I'll probably have to start working on an entity editor at some point, since I recon unit and other entity creation will get quite complicated when multiple linked entities, collision shapes, etc. etc. get involved. I'm no big fan of GUI programming, especially since Python's GUI libraries all seem kind of shoddy (though that seems to apply to other languages too, at least C# and Java). Anyway, I'll probably use wxPython for it. Making it in-game would be cool, but too much effort at the moment.

Trac

I tried installing Trac (again) today since they just released version 0.11, and couldn't get it working (again). After getting over a few hurdles, I was finally stumped when trac-admin hanged while trying to create the environment. Every time. I really want to like Trac, since it's excellent when it works, but I've had nothing but problems trying to get it working myself. It seems I'll have to let it go and find some other issue tracker when I really start needing one. I'd like it to integrate with Mylyn, but the (free) options there are a bit limited. We'll see...

25Jun/08Off

Artillery Brawl goes public

No coding today; instead, I've released the Artillery Brawl code! The game now has a project page and Bazaar code repository on Launchpad. The code is licensed under the BSD license, and I changed the art assets to free ones. They are marginally better than the old ones; see screenshot below.

Also, I combined the old Projects and Tools page into a shiny new Portfolio page. Though I do want to make it a bit nicer looking at some point... Anyway, tomorrow lots of capoeira. On the weekend: hopefully lots of progress with actual coding.

22Jun/08Off

Artillery Brawl

Today, I got back from Sweden, Arty got a new name, and I continued a tiny bit on my entity system. Rather than keeping the name of my old game, I'm making a tribute to Artillery Duel and naming it Artillery Brawl. Also, I already have some cool ideas for a possible sequel. Of course, that will be far in the future if it ever becomes reality, but at least I can store ideas in its brainstorming wiki instead of throwing them away if they don't fit in Artillery Brawl. ;)

I'm in the progress of generalizing my entity system a bit. My current step is creating a "component library" so that unit files and other entity type definitions can load and create components by name instead of importing them, which would get really messy, really quick. I'm going to load components using entry points in setuptools, which allows me to trivially support both builtin and modder-provided components. This means it's going to be easy to make and distribute units with new functionality without the need to modify the source code of the game.

19Jun/08Off

Arty, first look

Finishing unit placement was actually a 5-minute job, so here's the video I promised. It's not great, and as you can see, you can't really see the shells they shoot at the moment (especially since the video quality isn't that great). That's on the todo list, though. But as I have previously said, I really like the camera, though it might be just a bit too quick at the moment. It's fully configurable, so that isn't really a problem.

Youtube's quality was too shoddy, so I used Vimeo (which is also kind of shoddy, but oh well...). But if you are logged in on Vimeo, you can download the original, decent-quality AVI version!

Full-size video.


Arty, first look from Jussi Lepistö on Vimeo.

18Jun/08Off

Groundwork

This week, I've done more groundwork with entities, and just started on unit placement. Unfortunately, I don't expect to finish it this week, since today I've got other things to do, and tomorrow I'm leaving for Sweden for a couple of days. The entity system is starting to look really nice though, and I've got lots of ideas to make it even better. After unit placement, I think I'll concentrate on those ideas and some cleanup to pave the way for gameplay stuff and particles I was talking about earlier. At some point, I'm also going to write a whole post about the entity system, its design and development, and my experiences with it. But that will have to wait until the entity system is more complete. So, until next week!

13Jun/08Off

The problem with CRPGs

Today, two posts for the price of one! This was going to be a game design -oriented post about character development in computer roleplaying games (CRPGs), but turned into a rant. I'll write about game design later. :)

In my opinion, the problem with CRPGs is that they are either direct ports of, or heavily influenced by table-top roleplaying games (RPGs), especially Dungeons & Dragons (D&D). Like board games, RPGs are designed with the advantages and limitations of human beings in mind. Specifically, we have awesome imagination, poor short-term memory, and don't like complex calculations. Conversely, computers are excellent at making calculations, have perfect memory and zero imagination. It should be obvious that CRPGs should be designed for the advantages and limitations of the computer. It also means CRPGs will never be real role-playing games unless they are completely multiplayer or someone develops a sentient AI.

I particularly don't like the "classes, levels and skill points" style of character development prevalent in CRPGs. It works great in action games like Diablo 2 where it's an excellent reward system for the player. In "real" CRPGs, not so great. Of course, most of the content in most CRPGs is action, and specifically combat, which is a separate problem itself... Some games, such as Morrowind, implement a "learn by doing" system, where you gain skill points in eg. swordfighting by fighting with swords. It's a step in the right direction, but Morrowind's implementation wasn't that good. It smells too much like spreadsheets with all the numbers, skill increase messages etc. and is easily abused (Morrowind was famous for players jumping around all the time to raise their strength stats). I think computers can do better.

I'm all for complex simulations with simple interfaces in (computer) games for a couple of reasons. First, computers are good at simulation, so why limit simulations to what a board game could do? On the other hand, people like simplicity to avoid their brains exploding, so you can't show all the complexity to the player. At least not directly. Second, complex simulations result in emergent gameplay, and emergency is awesome. Therefore, I'm thinking skills should be far more fine-grained and interrelated than they are at the moment.

Let me give an example. Practically every modern and sci-fi CRPG has weapon skills for different types of weapons. There might be eg. pistols, rifles and heavy weapons. But usually this means that if you can fire a pistol, you can't fire a rifle. And you can't be an excellent sharpshooter, but poor at hitting moving targets. An alternative could be "micro-skills" for aiming, burst control, hand-eye-coordination, leading (as in leading a shot), reloading, jam repairing etc, with "affinity skills" for different categories and even models of weapons. All of these would be improved by training or actual experience, and a combination of these skills would determine the actual result. It would be no problem for a computer to handle all this information, especially if all the micro-skills already match an action in the internal simulation, but it would be too complex to show the player. The game interface might simply read "you are good with rifles, and very experienced with the M-16". This is still just a rough idea, but I'd like to try and take it further by designing and perhaps even prototyping it in the future. And that will be the topic of my game design post.

13Jun/08Off

Alternating states

Every programmer knows that sometimes you have to spend time to work on code that no one will ever see. Background work for new features, cleaning up, restructuring or refactoring old code etc. etc. This week I have been doing exactly that. In preparation for implementing unit placement, which requires a bit more interaction with terrain than I have currently (ie. any at all), I have been working on the entity/component system and the terrain entity to make them ready for that. I have also cleaned up some code here and there, but nothing that will show in screenshots. Expect that next week, when I'm going to finally implement unit placement for real. I'm also thinking of capturing my first ever game recording video of the results.

After unit placement, I think I'll spend some time on the interface. The current unit is not highlighted in anyway, and artillery shells are impossible to see if you don't zoom in ridiculously close. I'm not too keen about making them bigger since I'm aiming for a semi-realistic look. Besides, that solution won't scale if you want to zoom out even further. That means I'll have to invent some other type of highlighting for shells. After that, I have a couple of option. I could work on hit effects, which means particles, which sound like fun (especially making them fast enough in Python). Or I could work on the actual game, ie. player management, menu structure etc. I haven't decided yet, so we'll see what I'm going to do.

Btw. if anyone can recommend a good program for capturing video from a game, I would be happy. I've found recommendations on FRAPS and Growler Guncam thus far, but both look a bit... amateurish.

5Jun/08Off

There’s noise in my pictures

It took a bit longer than I expected (coding progress if inversely proportional to outside temperature), but my noise experiments are done at least for the moment. So, time for some explanation and pretty pictures.

I decided simple value noise (essentially just random values) with Fractional Brownian Motion (fBm) would be enough for now. Besides, with my implementation it will be easy to expand later to Perlin, Simplex or some other type of noise. Natalya Tatarchuk’s talk that I already linked previously has an excellent explanation of fBm when applied to noise. I already have vague plans in mind for more complex multi-stage terrain generation with terrain types, maybe some erosion etc, but I'll have to concentrate on more important stuff first. Like gameplay. But first, the pictures I promised, click for larger versions. And don't mind the ugly terrain texture.