Create-ivity

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. :)

Yay, there goes my first finished game! After one month of working on top of someone elses code, I can finally say I’ve got a game under my belt. Ok, it’s a puzzle game, not quite what I expected to be working on, but it’s a great feeling nonetheless. :)
This week, I started working on a race game. Again, some core functionality was already done, so for me it’s mainly tweaking the menu code (which isn’t all that fun since the existing code was writted with much less functionality in mind) and adding race tournament logic as well as savegame functionality and such.

On top of that, I’ve also made some progress with Tar!. I’ve taken on the level loading code this time, which means I can now load levels into the game - click here to see the first Tar! level ever… There’s no collision system yet, so it’s not like the player cares about the carefully placed walls, but hey, that’s next on my list. Then comes the entity parsing, for which I still have to find a proper solution, one that saves me from modifying the parsing code for every new entity I develop, but that’s still some time from now.

Happy holidays to all of you, I’m certainly enjoying mine! :)

I received the book 'Effective C++' (Scott Meyers, third edition) just last saturday. While it looks like a small book, it contains a wealth of information. It's easy to read and comprehend and has already helped me solve several subtle memory leaks as well as giving me a better understanding of how C++ handles classes.

Definitely a recommended read for every C++ programmer.

A totally unrelated item: I recently started to like the word 'Woogle'. I've got no idea what it's supposed to mean (actually, I imagine it's a small, spheric, furry creature making high pitched noises) but it's a great name for some test classes. Heh. :)

Does that term ring a bell? No?

Just in case it didn't, it's a programming method that allows you to write functionality that can handle different types of objects. A template function that returns the biggest object of the two you send it only has to be written once, even if you use it throughout your code with different types. The trick is, the compiler generates an appropriate function for every different type you call the function with.

This means you don't have to rewrite your function for every new type it needs to support. If you're familiar with web-design, it's kind of like using .css files to store your websites style information in.

Besides creating a template quad-tree that can be used both by the renderer and the collision system, I've also made a quick model of the coggie enemy. It's meant to be sort of cute-looking, with a charming in-game behaviour: coggies go stand on their hands and rotate their wheels against another as a sort of greeting, and they occasionally operate cog wheels found throughout the level as well. :)

I'm investigating screen-capturing animated models like this one. It's faster and easier to animate than a hand-drawing approach, but probably still requires manual polishing afterwards. Interesting…