Archive for the tag 'screenshots'

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.

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 »

Generalizationismic

Phew, been a busy week, but today I got quite a lot done again. I generalized the code for input mapping, component subsystems (which are responsible for managing the entity components of a game world) and collision handling, and I’m quite happy with all of them at the moment. Terrain is also a bit more interesting now (see screenshot below). If I have time, tomorrow I’ll continue on gameplay. Though after that, there will most likely be a whole week without any progress for Real Life reasons.

arty5.png

My biggest problem at the moment is choosing starting locations for units. They need to be more or less level, but with procedural terrain it’s not always granted that there will be level ground at all. To start with, I think I’ll first randomize the general area the unit will be placed at, then look for a location nearby that’s level enough. If a location can’t be found, move the heightmap around to create a level spot. Later I’ll probably try to handle things like starting between two huge cliffs or facing a cliff wall that prevents you from shooting in that direction at all.

Another problem with starting locations is that since I have physics simulation going on, it will be really difficult to find starting positions that are stable. The problem will be even greater if I later introduce units whose shape is a bit stranger. I think I’ll solve the problem by first finding an approximate starting location for units, then running physics simulation at high speed for a while without drawing, then check if units are upright and settled down. If not, find a new starting position and repeat.

I have also been brainstorming the shmup with a friend. It’s most likely going to be my next project. We got some wild but doable ideas bouncing around, it should be really interesting. But more on that later as things get a bit more solid.

Day two

Like yesterday, I didn’t get what I wanted to done, but did get as much done as I wanted to. :) Summary of today’s accomplishments:

  • Physics simulation for all objects, thanks to Chipmunk (see screenshot #1 below)
  • Units can now shoot, but turns don’t change yet (screenshot #2)
  • Input mapping is done in a really nice, general and configurable way, though still needs more work, but that will be for later (this took quite a while to write)
  • Lots and lots of structuring and cleanup of code

arty3.png arty4.png

I’m really, really enjoying working on this project. Most problems feel bite-sized unlike the hurdles I was facing with complex 3D graphics. My current plan is to continue making smaller projects to ease my way to more complex projects. Along the way, I can start collecting and consolidating common pieces of code for the games, and hopefully end up with a much better game engine than the one I used to work on. For the next project I’m probably going to use at least some 3D graphics. After that… who knows. But first I will, of course, finish this one. I want to show I can get at least something released after too many years. :)

One feature I was going to write about this morning but forgot is the turn system. I’m not going to implement a traditional I-go-you-go (alternating turns) system, but not a we-go (simultaneous turns) system either. What I have in mind is very similar to what I’ve only seen one game, Titans of Steel do. The idea is that each action takes some amount of time, and you get a turn each time your action is done. What this means in practice is that if player A has a light tank capable of shooting one round per second with its light gun, and player B has a heavy tank firing one round per five seconds with its heavy gun, player A gets five times as many turns as player B. On the other hand, player B’s gun will probably do a lot more damage and create much bigger explosions than player A’s gun. And Player A’s tank is probably faster. This should give you some alternative strategies to choose from, and heavier tanks will not be absolutely better.

Tomorrow will probably be a bit slower on the gamedev front as I have people to meet and other things to do, but I’ll still probably get at least something done. And keep you updated, of course.

Day one

Ok, so I didn’t actually update during the day and didn’t get an actual playable game prototype done today, but I’m damn pleased with my progress in any case. :) And I don’t remember programming being this satisfying for a long, long time!

Anyway, I got randomized, heightmap-based terrain and basic units implemented. You can also freely scroll and zoom the camera using the mouse. I started on gameplay but didn’t get any actual game mechanics done yet. The basic groundwork is already there, but I need some kind of “game physics” going on next. I’m not sure if I should just make a quick hack or use something like Chipmunk right from the beginning (I’m going to eventually use physics simulation anyway). The code isn’t a horrible mess, but I have avoided getting bogged down perfecting a design. Instead, I’ve done what needs to be done to get a feature up and running, then structured it better afterwards.

Here are the promised screenshots anyway, testing 200 units randomly scattered around. I found the images / textures on Google and have no idea about their copyright, but this is just a prototype after all. Zooming isn’t constrained in any way yet. The units are actually resting on terrain, not floating above it, but the texture has a bit of empty space at the bottom and there’s no concept of offset for the units yet.

arty1.png arty2.png

Tomorrow I’m going to write a bit about what I have in mind regarding the design of the game, and of course continue actually programming. :) Stay tuned!

Memoirs of a Game Developer

Yesterday I stumbled upon my archives of old projects, and I felt a sudden breeze of nostalgy. Today I will take you along for a trip to my game developing past. My oldest games (or “gamelets”, as they were never really finished) haven’t survived. I remember a Mad Max -esque, text-based cab driving game and a space shooter similar to Star Control, but I don’t even remember their names.

Arty (1999) is my oldest surviving game, if you can call it surviving. Arty was an Artillery Duel clone written for DOS with the Watcom compiler; anyone remember the joys of DOS4GW? The code was horrible, since I had just learned C++, having programmed in C before that. I couldn’t get it to run (DOSBox might have helped, but I couldn’t be bothered) and couldn’t find any pictures, but here’s a peek at the jumbled mess of code, from particle system code (”smoke.h”):

void UpdateSmoke(long SmokeIndex)
{
Smokes[SmokeIndex].XSpeed/=(1+Options.Friction/2000.0);
 
Smokes[SmokeIndex].X+=Smokes[SmokeIndex].XSpeed
+Wind/500.0+((rand()%21)-10)/20.0;
Smokes[SmokeIndex].Y-=Smokes[SmokeIndex].YSpeed*(rand()%10)/10.0;
 
if(Smokes[SmokeIndex].X<0||Smokes[SmokeIndex].X>=SCENE_XSIZE
||Smokes[SmokeIndex].Y<0)
DeleteSmoke(SmokeIndex);
 
if(TypeBuffer[(short)Smokes[SmokeIndex].Y]
[(short)Smokes[SmokeIndex].X][0]==TYPE_GUN)
GunDamage(TypeBuffer[(short)Smokes[SmokeIndex].Y]
[(short)Smokes[SmokeIndex].X][1],
Smokes[SmokeIndex].Damage);
 
Smokes[SmokeIndex].Life-=(1+abs(Wind)/100.0);
if(Smokes[SmokeIndex].Life<=0) DeleteSmoke(SmokeIndex);
}

Despite being a huge mess, the game actually had some very nice features. Aside from cool-looking explosions, fire and smoke generated using “smoke.h”, it also had a fully flexible weapon system, where I could assign payload (”bombs”) to artillery shells. Bombs in the payload could have triggers (eg. impact or “I’m above a gun”), and explode generating new bombs etc. There was also separate concussion and kinetic damage; kinetic damage was based on the velocity of the projectile. Two of my favorite weapons were napalm, which burned a huge area for a while, and nuke, which was based on a series of different bombs, with the only piece of custom code being a screen flash when it exploded. Arty of course had fully destructable, random terrain.

As a curious detail, I had already started creating a game engine called Solid (revealed by a file called “solid.h”), though at the time only used for Arty. As soon as I realized Solid is quite common a name for absolutely everything, I changed the name to Spineless. Spineless was released as open source at the beginning of 2003.

The project Spineless was really meant for was mproject (2000-2004), a doomed, long-time sci-fi game project by a group of friends (yea, I have a thing for sci-fi). The M in the name stands for Master of Orion, which basically explains what the game was about. Btw, what actually prompted me to write this journal entry was that I had forgotten how far we actually got with it. Frankly, it wasn’t far at all, but I didn’t remember us getting even that much done. Here are some screenshots of the prototype. It’s actually much nicer looking in motion, since it’s exceptionally smooth.

mproject 1 mproject 2 mproject 3 mproject 4

sbproject (2004) was kind of a spin-off of mproject, focusing only on combat, á la Homeworld. In some far-fetched plans, it was to be the tactical combat part of mproject, but this project never really got off the ground either. A single image remains:

sbproject

After that, I haven’t really worked on any games. I want to change that now, and it’s one of the reasons I killed Spineless; I want to try and concentrate on actual game programming for a change, instead of trying to make a game engine usable by other developers. That might be a side product of my endeavors, but not a major goal.

If you are interested in more details, prototypes or source code for any of the projects, please drop a comment!

More infovis

Again, all my programming effort has been spent on the visualization prototype for my university course. On the positive side, I have lots of ideas on how to go on when I have time to continue my hobby projects. Working on the prototype has been a bit of a pain, as programming user interfaces and visualizations is all about the details, and there are loads of details in every graphical application. We’re quite tight on the schedule too, but thankfully the prototype doesn’t have to be fully functioning, it just has to demonstrate the idea.

I have mixed feelings about working with C#. On the other hand, the GUI facilities of .Net are the best I’ve ever worked with, but on the other hand, I’m often missing Python when it would make a solution much more straightforward than C#. And why the heck does the size of container have to be either Count or Length, depending on the container? I know, I know, choosing IronPython could potentially combine the benefits of both, but I don’t really have time to find out if that’s the case.

Anyway, here’s a picture of the prototype, now showing article topics. They’re generated from article keywords by a simple and crappy clustering algorithm because I didn’t have time to implement a better one, and laid out crudely, but that’s a start. The square icons are articles, and their colors match topic colors. Additionally, article icons should appear inside topic areas, but they don’t yet. I really hope I have the time to improve topic display by the end of the project.

citevis_2007-11-19.png

Information visualization

First, an update on the last post: I sent mail to the developer of generateDS, and he has located the problem and is looking into it. That was quick, nice. :) As for parsing C, I took a look at a couple of tools, including GCC-XML, but I couldn’t find anything I could readily use. So I’m still counting on Pyparsing or PLY to do the job. I realized Pyglet is using PLY, maybe I’ll look into that for insight.

The last few days I’ve been spending my programming effort on a university project. I’m on a course called “Information visualization project work”, where we’re supposed to design and implement a prototype of an information visualization (infovis) application. I already took the infovis introduction course and the topic seems quite interesting, especially since it’s related to user interfaces which I’m very interested in. Infovis is visualization of abstract data, as opposed to scientific visualization, which is about visualizing concrete data such as air flow over a wing, or the structural integrity of a bridge. Common applications include maps (although the underlying map might visualize concrete landscape, it’s almost always overlaid with abstract data such as routes) stock rates and weather charts.

We had three topics to choose from, and our group chose visualization of research article citations. Since there don’t seem to be any suitable visualization libraries for Python, and I don’t really like the GUI libraries for Python either, and I hate Java, and I don’t know Flash, we chose to do the prototype in C#. It’s much nicer to work with than Java, and I’m at least somewhat familiar with both the language and the .NET API. Granted, I could have tried to use IronPython, but I have no experience at all in it, so I decided not to take the risk of trying to learn it for this short project. We’re using a visualization library called Piccolo, which at least initially seems quite nice. It’s almost trivial to set up too, though the API and especially documentation is a bit confusing. Unfortunately the free version isn’t really maintained or updated anymore. It would be nice if someone did something similar for Python… or maybe a library like that exists, but I just couldn’t find one.

Very early version: squares are articles, circles are authors