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.

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.

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.

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!

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.

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.

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.

Read more »

Day n: noise

I’m back again. Yesterday, I continued game development for a change by taking advantage of some Pyglet 1.1 features in my game, and doing small improvements to controls. Then I noticed how awful the current terrain generation method is, and decided to start researching noise. Perlin noise at first, then I found about Simplex noise, Fractional Brownian motion… and I’m still on that path. Natalya Tatarchuk’s Game Developers Conference talk was especially helpful. I hope to get something concrete done with noise next week. The good news is, that means finally more screenshots! And hopefully a longer entry for a change…

Flashy stuff

So I’m learning Flash now. It actually seems quite interesting, though I’m not a big fan of the scripting language (I’m using version 3.0 of ActionScript). But why did they have to make every window of the IDE have the same style, ie. dockable tool windows? Also, since they are not standard windows, the scroll wheel and some standard hotkeys don’t seem to work… *sigh* It’s impossible to use the built-in help this way, so I’ll rather use the online help with my browser. I’m just doing a small project for a university course though, and I’m not planning to do anything gamedev related after that. Still, nice to get some new experiences development-wise.

I’m going out of town this weekend, and next week I’ll probably have to concentrate on the Flash project, but after that I’ll try to get back to game development since I shouldn’t have any courses left for this Spring. So, until then!

Camera, lights, action!

As promised, I actually did some game development this week for a change. First I upgraded to Pyglet 1.1 (beta 1) and pymunk 0.7.1. After that, I finally implemented a better camera for the artillery game. It’s really nice now, smooth scrolling and zooming with constraints so you can’t move or zoom “beyond” the playing area. Unfortunately, none of the improvements can be seen in static screenshots. Next thing I’ll probably add is some kind of a background so it’s not so easy to get lost while moving around. After that, I need better controls. I should also try and take advantage of Pyglet 1.1’s new features.

But unfortunately, now I have to concentrate on Prolog programming to get rid of a university course. I have the exam for Logic programming next week, and I have to do a couple of bigger excercises before that. But after that, probably more game programming, so stay tuned!

« Previous PageNext Page »