Concept stuff

Thought I’d share some more concept stuff with you. Wreckage has been worked on and refined. He looking much better and Ronnie still wants to do more to him so he can only get better 🙂 It helped me to put them next to each other to see how he’s changed over time, so here’s his evolution so far (you can click on it to see a bigger version):

The Evolution of Wreckage

Another character has also had his first sketch so here’s the latest addition to our merry band:

MR MEGATRONIUS

Half man half robot and sent from the future.  Mr Megatronius is really more of a machine than he is a man.  He has characteristics of a man, but his body is the equivalent of a giant pocket-knife complete with built in walkie-talkie; jet packs on his feet; hands that transform into lazer guns; built in super-computer;

Mr. Megatronius

Ange and I have been scripting out the first sequence of the game which will be introducing the player to the game mechanics and controls, and it’s proving to be more complex the I first imagined. It’s taking place in Zach’s bedroom and because of this, every detail in the bedroom has to be built around Zach’s character: what he likes, what a boy would have in his bedroom, what Zach (in particular) would have in his bedroom, and then the bedroom has to be structured in such a way that it allows for the puzzles and sequences that are going to be happening in there. It’s a very strange exercise and a bit of a mind warp to go from programming to doing this kind of work. I’ve also been trying to design some puzzles for this section which has been interesting too. Not sure how hard to make them (since it’s the start of the game) and how much to expect the average player to know (eg: I know some stuff about electronics and wiring circuits, but does the average player?)

Anyway, on with the show. We’ll have to see how this pans out…

Later

Checking in

So it’s been a while since I posted something, so I thought I’d just check in and let you know what’s been happening.

I’ve been working on the dialog system in the game. I’ve got the speech to come up automatically and stays on screen longer for longer sentences. So far I’ve had to hand code all the dialog sequences, but I’ve been working on a c# app that will let me script the dialog sequences in an easy to read and alter format. The app then takes those sequences and exports the lua required to make them happen. So far it handles speech, extra scripting that’s part of the sequence and i just got it to produce dialog branches, where the player is presented with a bunch of different things to choose from and different sequences are kicked off depending on which option is chosen. Here’s what my app looks like at the moment:

A sample game dialog sequence

The different colours are so I can easily see what lines belong to which actor :). In this sequence, Zach is talking to a door. That’s normal, right?

Here’s a video of some new-ish features: the perspective control and the current state of the dialog system.

The perspective control controls how small the character will get as they move towards the top of the screen and their velocity in different locations. The ratio between the lengths of the top of the perspective poly and the bottom control most of this. Sorry that the speech bubbles are mostly out of the screen, but you should be able to get the general idea. I got bored and started skipping the dialog, but usually it stays up for longer.

So there you have it.
Gavin out.

Genesis

Well, I’ve finally settled on a solution to my scaling problems. Since I don’t think I’m ever going to be able to cover every contingency and outlying case, I’m just going to go with this solution until it doesn’t work anymore and then worry about what it can’t do when/if I get to that situation. I was going to do a video about how it works, but I’ve got something even better to show off: Some concept art! 😀 So here we go with some character descriptions. Descriptions are by Ange (my wife) and art is by Ronnie (a friend of mine).

ZACHARY

Is a freakishly overdeveloped 10 year old boy. He shares a middle class existence with his parents and older sister Jenna.
From a young age Zach enjoyed picking things apart and trying to put them together in new ways, to both the dismay and delight of his parents.

Among his inventions are:

A skateboard powered by a lawnmower engine, with an attachable trailer.
A fairground for his pet hamsters (the first one died when trying out the roller-coaster, but thankfully the ensuing ones were of a stronger disposition).
A “voice box” for the resident cat that allows it to say some phrases.
A “fart” gun that is able to throw both a farting noise and smell in the direction it is pointed.

Due to his intelligence and propensity for trouble regarding his destructive tendencies, Zach finds it difficult to make friends. The cool kids don’t like him because he is too clever, and the clever kids don’t like him because he is always getting into trouble. To compensate for this he develops an overactive and vivid imagination which allows him to live in a world where his two best toys are also his best friends. This is the world where the game takes place.

ZACHARY APPEARANCE

There aren’t too many very specific things about his appearance. Obviously he’s a young boy, and he has a backpack. Through the game, General “Wreckage”s torso, head and arm will be sticking out the top of the backpack and participating in the game events. No glasses and I think he should be a brunette. Clothing wise possibly a kind of skater style but not too cool or grown up. He’s a trouble maker but he’s not a rebel and there’s a child-like innocence about his cheekiness. Something like takkies/long shorts and a hoodie over a t-shirt. With at least one or two bright colours in the mix.

The evolution of Zach

GENRAL “WRECKAGE” MCGEE

Only has one arm because he lost the other in the “war” (later we find out that a cat chewed it off ).  He’s a GI joe looking toy, but much stockier and overemphasised.  Basically a caricature of the old 80’s / 90’s style commando buff army types, complete with ammunition belt and other military paraphernalia.  I’m quite happy to have him as some sort of garish mish-mash of every military stereotype.

The idea is that he is a seasoned vet – a commando in the army until he was made general.  He’s roughly 45/50, and possibly grey or balding or bald.  He smokes a cigar pretty much all the time.

General "Wreckage" McGee

So there you have it. I think it’s looking AWESOME!!! 🙂 Nice to have something to look at and am looking forward to see how it’s going to progress. I’ll be releasing more details and art as they come, so stay tuned.

Horrible, horrible perspective in 2D

I am currently being tortured by an elusive solution to a problem. The problem is faking perspective in 2D, as in making the character become smaller as they move towards the back of the scene and adjusting the velocity they move accordingly. I’ve come up with a number of different ideas and had ideas given to me by a friend, but nothing seems to fall nicely in the two categories of “doesn’t require me to actually add a whole new dimension to my engine” and “will work in most situations”. I feel I should document the things I’ve considered, but I just don’t want to think about it anymore. I’ve taken to listening to very loud music to drive the evil thoughts about perspective out of my head by force, and that is where you currently find me. No doubt this will be plaguing me for the rest of the night. 😦

Latest changes and UI design

Lately, I’ve been making little changes here and there. I’ve changed the way that I’m storing fonts. I’ve split the font metrics and the font texture up into two different files, which has allowed me to make changes to the texture in an image editing program (namely add outlines to the font).

Like so:

The benefit is that during the game the text will be readable regardless of what colour the background behind the text is 🙂 Now that I type that out it’s pretty damn boring, but I was quite excited about it.

The other thing that I’ve been working on is the user interface. I’ve been thinking about how to improve the typical user interface that’s used in adventure games. On the whole, nowadays, there are two main designs used for adventure games:

(1) A row of icons depicting various actions is placed along the top (or bottom) of the screen. When the user wants to do something like open a door or pick up an object, they have to move the mouse to the row of icons, select the action they want,  move the mouse back to the object they want to interact with and click on it. It’s pretty clear that the number of steps required to perform an action is not insignificant and is clunky at best.

(2) The players performs an action by right clicking to cycle through a number of different mouse cursors which represent the various actions, until they find the action they want and then click on the object in question. Although better than the first design, it can also become quite annoying when you have to keep cycling through all your actions over and over, especially when you happen to cycle past the action you wanted and have to go through the whole loop again.

So, I’ve decided to be a bit otherwise and go with a design that I happen to like and haven’t seen in many places. Not sure why… hopefully it’s not because it sucks. The design works like this: If you want to interact with something, you click and hold on the object, an action “coin”… thing comes up and you move the mouse to the action you want, and release the mouse button. It seems far more streamlined and intuitive (at least to me) than any of the other designs, so lets hope it is 🙂

I’ve also added a task list type thing for the player character so that if you (for instance… just out of the blue) choose to use a door, I can queue up a number of actions, such as: walk to the door, turn to face the door, open the door. The cool thing is that the way I’ve made it means that I can interrupt the tasks at various points. For example: If I tell the character to go and open the door, the character will start walking towards the door. If I, at this point, change my mind and want to walk somewhere else instead, I can do that and the character will stop doing what it was doing and begin walking to my new destination.

Here’s a video to show off what I’ve just been talking about. Yes. I know my UI art is bad. Let’s just call it programmer art and ignore the fact that I was actually trying to make it look decent. My wife was kind enough to immediately point out how bad it was as soon as I showed her my UI. Nice.

The pain of threading and bitmap fonts

I had forgotten how much i hate using threading. It creates just as many problems as it solves. Although it’s cool that i can load stuff while the game continues to run (and probably just show a loading screen), it has complicated the flow of my code to a fairly unfortunate degree. Ah well, such is the way of things, I guess.

So anyway… my fonts. I have been fighting with these damn fonts for too long now. The mipmaps helped, but ended up making the fonts look quite fuzzy/blurry which, although better that just plain crap, makes you feel like you need to plan a trip to the optometrist to get laser eye correction surgery. I’ve tried a bunch of different filters to create the mipmaps and filter between at render time, but when it boils down to it if you reduce the size of an image, you are losing fidelity and nothing seems to be able to keep it nice and sharp. The best looking the fonts get is when they are rendered at a 1 to 1 ratio, meaning no mipmaps and no filters. 😦 So, my current solution is a sort of mipmap setup but instead of taking the original font image and downscaling that, I’m rendering a number of versions of the font image and different font sizes. My font manager then returns the one that is closest to the size you want. This reduces the amount of mipmapping needed when rendering the font out because you are close to (ideally) a 1 to 1 ratio. Obviously I can’t render out a different texture for every font size possible, but it’s better than it was. I think.

It’s still hardly perfect and I would love to be able to make it better, but as I said I’ve wasted too much time on this thing now. If I really need sharp fonts in my game, I’ll have to make the font images at the sizes I need them. So be it.

Now I’m back onto trying to sort out that whole depth sorting thing with the in game objects.

Fonts and textures

Hi guys. Sorry, not much to show this time. I’ve been trying to figure out how to get my in game fonts looking better which has taken me on a really long road. First I tried to get mipmapping to work which proved to be a pain because I either needed to generate them myself or get openGL to do it. It sounded like a better idea to let openGL do it, but that meant I needed to learn how to use openGL extensions (which is basically just how you say “using functionality newer than what was around in 1995”). So, after learning how to get extensions working and make openGL generate my mipmaps, I ended up with really fuzzy text. Yay! Totally worth it. It turns out that openGL generates really crappy and blurry mipmaps, so it was back to the generating the mipmaps myself. My one friend turned me on to FreeImage which is an open source image library. I stuck that into my code base and was able to generate decent mipmaps. Only problem is that it takes a while and stalls the whole program while it’s doing it, which obviously isn’t acceptable. So, I’m currently making my texture loading asynchronous using the threads from the boost library, which will enable me to carry on doing other stuff in game while this is going on… like showing a loading screen or something. (Damn. This is the most third party stuff I’ve ever used in my game programming) Boost is a pain to get up and running, but I finally got it to work right. Now to do the actual texture loading on my brand new thread.

Simple Anims and Some Editing

I’ve put some simple animation handling into my actor class to make it look a bit nicer than a white block moving about 🙂 Tried to put some form of depth sorting in the objects, but it turns out that it’s much more complicated than I gave it credit for… especially when there is this “faked” perspective thing going on in the scene. So I’m going to have to make something more intelligent to handle that.

In that line, I’ve begun work on an in-game room editor. It’s going to let me change things about the room in real-time instead of having to close down, change the data a bit, load the game back up, rinse and repeat. Faster iterations mean faster development so… yay.

Here’s a video of the new stuff I’ve added in. Hopefully it’s pretty self explanatory, but just in case, I’m showing:

• Walking behind the desk
• trying to walk up the stairs and failing
• showing the walkable areas
• adding in a new walkable poly
• walking in the new poly
• editing the poly
• deleting the poly

The program I’m using to capture these videos (fraps) is killing my frame rate which is a bit annoying and makes demoing things fairly painful. Although it did show me a bug in my code that was relying on a certain frame rate. You can see it in the video actually. The editor window comes up too far because I don’t have any checks to make sure it doesn’t shoot past the right height in a single frame. Oh well… swings and round-abouts I guess.

Awww… his first steps

I wrote a little Actor class which is going to handle character movement and animation, and hooked it up to my user interaction and pathfinding so I can now move a little white block (my actor) around by clicking in various places on the screen. My code takes the clicked position and finds the closest possible position the actor can get to that location and then the actor begins to move there. I am also able to interrupt the actor’s current path and send him somewhere else which is pretty neat.

Here’s a little video (the first one on this blog. YAY!) of my actor finding his way from the front door to the door behind the desk. It’s the same path (roughly) that you’ve seen in the last post, but I’ve taken all the debug graphics out so that it looks a bit more like a game. I don’t have any depth sorting implemented, so the actor is not going to go behind the desk visually, but you can see how he steers around the desk. (the fraps.com watermark at the top is because I’m too broke to fork out and buy the app that I’m using to capture this video). Enjoy!

Hooray for A*

So, things have progressed a bit since I last wrote. I implemented a Djikstra pathfinding algorithm, which isn’t very efficient. Made a smallish change to it, and suddenly it was the A* (pronounced “A star”) algorithm – the bread and butter of game AI programmers. Go figure. I thought there would be a bigger difference than there was.

I ended up with a workable (but not very intelligent) path from A to B.

As you can see, the path (starting on the left) always passes through the centre of the connecting bridge lines (the purple lines). It works, but it’s not the way a thinking person would walk. A person would walk towards a visible end point and then reassess their path. To simulate this behaviour, I’ve written a path smoothing algorithm which produces the following path:

Although it looks similar, there are some key differences. In the first one, the path is made up of 5 points. The second one, has only 4. This may not seem like a big deal, but what has happened is that point on the first bridge wasn’t needed because the path could go straight to the second bridge (based off a bunch or calculations). The less way points there are, the less direction changes there are. One of the things that makes characters look dumb is when they walk to an unnecessary location to get to another one. It’s not that pronounced in this situation, but in others it would be enough to break that vital barrier of suspension of belief, which is want we strive to avoid in game development. The new path is also the shortest route the character could take from point A to point B, which is also something humans do (ie: be lazy :))

The path-smoothing algorithm represents a couple days of head scratching and failed attempts, so I’m pretty stoked that it’s working. There are some inefficiencies (some tests are done more than seems necessary due to the unpredictable nature of the bridge point ordering), but at the moment it’s more than fast enough.

I’m hoping this pathfinding code will stretch to other applications in other game genres, but I guess that’s too long a way off from me to worry about now. I’ve tried to make it extensible and it’s much more than I strictly need for the current game, but it was fun and I’ll be thankful when I want to use it again.

Next… um, I’m not sure. I guess it’ll probably be something to control character movement and animation. I’m going to need to rip myself out of the framework mentality where I try to provide the functionality I’m going to need and actually use the stuff I’ve written in a game. That’s been my biggest weakness to date when it comes to making games. Farting about in the framework and building engines comes easily, but getting down and actually producing something… that’s something I’m still trying to learn