Sorry for the silence here. I’ve continued working out the collision and the rendering systems, and the collision is going a lot better now. I fixed a few stupid mistakes – for example, an object would get moved for every check it did against another object, and the movement would not be reset after the check – and cleaned it up a bit and it works quite fine now. There’s a few issues, such as objects leaking through others in crowded area’s, but I’m sure I can figure out something for that.
Here’s a screenshot showing the collision system at work. The level blocks are a bit off and so are the soccer ball shapes, but at least it works:
Oh, and the company I work for (or, well, it’s an internship, but it feels like work, so…) just released their first game: Drift Damage. I didn’t do most work on it, but I’ve refactored it a bit and ironed out a few bugs before my fellow internshipper started, so hey. :)
Anyway, time for a little holiday break. It’s going to be a busy and fun month and I’ve pretty happy with what I accomplished with Tar! so far, so it’s time to take a little rest from programming.
Ah! Yesterday I finished the animation system for Tar!. Basically, the engine loads a text file for each sprite, and based on the information contained in these files it loads a specific image file and sets the animation data as defined in this text file.
The content of such a file looks like this:
$size 128 64
$framesize 32 32
$frames 0 1 2 2 3 2 4 2
For now, it suffices, and it’s pretty fun to play around with some test images and animation settings. I might want to write a tool for generating these files and managing my images later on, or refine the system as it’s probably not going to be too manageable with large amounts of sprites. But at this stage, it’s pretty cool to have it up and running. :)
I also added text rendering support (based the same animation system) and I’m working on some primitive drawing functions, like lines and rectangles. Woo, feels good to make progress!
Since the collision system showed some undesired results, I decided to clean up the renderer somewhat first before moving on and debugging that thing.
See, all it does right now is loading images, managing all visible objects and rendering them. All of them. After refactoring a game at work, I suddenly realized this system is going to be a bit painfull if I wanted to add some menus… or at least, easy switching between them. Writing a screen system, where each screen is responsible for it’s own list of visible objects, allows some more freedom. I’m also going to tweak the renderers resource management a bit: images that aren’t referred to anymore can be flushed.
And of course, the renderer should be capable of writing text and some basic shapes like lines, dots and rectangles. Those things are going to be usefull for debugging and a console system I want to implement later on. :)
Well, lot’s of idea’s there. Let’s continue implementing them. :)
Just a quick update – it’s late here, and I’m late with updates anyway. I reworked the level file format last week, so I can now load various tile layers as well as loosely placed sprites, and there’s a seperate data chunk for the collision data. Since I wrote support for triangles, boxes and circles, Tar levels are not going to be as boxy as most tile-based games.
That is, once I get this collision system to work properly. I tested it outside the game code, which showed correct results, but some tests in-game obviously showed that something was wrong. The tar balls I’m spitting out hit invisible barriers and then fly off at incredible speeds. Probably something with the coordinate system or the way these objects are loaded. Or something entirely elsewhere…
Debugging. Ideally it’s pointless…
As for my internship, which takes most of my time these days, it’s finally speeding up. We’re getting close to the end of the QA phase now, which is a great relief: that first game will finally get published. Never expected this stage would take so long. That’s probably why first-hand experience is so important. You won’t really understand it otherwise.
Turned out collision handling was a bit more difficult than I thought. It didn’t came as a big surprize, as it’s not one of the easiest subjects anyway, but after I had finished the boolean collision checks (it collides, or it doesn’t), I started to think the rest wouldn’t be too hard anymore either.
My current approach is to look for the smallest intersection after moving an object, so to correct it’s movement. No problem with that, it’s just another few hundred lines of code. Then comes a problem: what if the corrected movement would cause the shape to intersect another object? No big deal, just check all other relevant shapes. But what if, after a few corrections, it would intersect one of the earlier shapes? That’s an issue I still don’t have an answer to.
Another issue is movement constraints. Certain shapes need to be constrainted to move only on a certain axis. Correcting movement becomes quite more difficult there – or at least, I haven’t found a way to correctly handle it yet. Currently I think doing multiple tests, at various points across the movement vector, might just suffice… hopefully.
Well, lot’s of stuff to test there. I hope I can get some substantial progress the coming time, as my internship takes quite some time and energy as well. It’s fun, though, and again encourages me to program in C++ at home. “Build once, debug everywhere” is the new latest motto at my job, and while I’m getting used to the don’t-worry-about-the-low-level approach, I still miss it at points. Sometimes it’s downright frustrating. Oh well, that’s probably the case with everything, so I’ll live with it. :)
These are the first style concepts I drew for Tar!, besides the many sketches I’ve done on paper. Yeah, especially the second one is pretty rough, but that’s what they are: quick concept images, style tests. Enough talking, here they are:
I like this one, though I want a little more happy colors, the wood is a bit too dark still but overall, I think it displays a nice, happy environment. Of course, this isn’t final art, it’s way too static and unpolished for that. :)
I invested less time in the second image, but I think it gets the technical, more oppressing environment idea across. I’m not really sure how to exactly display this, as I want the game to be accessible to kids, so a too dark and depressing environment is out of the question. I guess it’s finding a trade-off somewhere between a happy visual style and conveying the emotions I want to express in these levels.
If anyone has comments or thoughts on these concepts, feel free to post a comment here. It’s always interesting to hear the opinions of others. :)
Right now, I’m facing a few issues. One of them is the collision handling: some objects can’t pass through others, some can pass through them but not through the solid level blocks, others only ever need to react to a collision with a specific other object… It’ll take some thinking to get that all straight.
Right now, I’m looking towards a system that assigns a type value to every collision object, so when movement is being checked, only the types that the moved block should not be able to pass are taken into account. For example, a block of type ‘character’ doesn’t pass through ‘solid’, but it shouldn’t be hindered by ‘item’ objects.
I’m also going to add a collision check, without movement information attached, which sends every entity that collides with the given object a message. I assume that’s going to be a lot of messages, so adding a ‘listen to messages’ property to collision objects sounds like a good idea.
The second test level. Using some old Half-Life textures I once made to test some visual styles. This is probably not what I’m going for.
Besides collision handling, I’ve been working on the design document. Writing the design down helps ordering my thoughts on it, and I’ve been able to flesh out a few aspects. For example, each level will have multiple exits, and each of these exits unlocks the route to a next level. The player selects which level to play next on a map, that shows how these routes and levels are connected, and which ones are unlocked and played already.
I’ve also thought about the story and the visual style of Tar!. I’ve played Metal Slug recently and it’s visuals have really impressed me. There’s a very free feeling to it, unlike grid-based games. It’s like comparing Tomb Raider to Half-Life, for example. Of course, such a visual style means a heavy payload for artists, so I’ll stick to a tile-based engine, but I am thinking about supporting additional sprites in the file format directly, instead of through an entity, to make inserting additional sprites easier. It’s a sort of trade-off between a total free-form and a grid-based approach, I think. Let’s see how well it works. :)