Save us all!

One of the things nobody ever talks about when it works is saving and loading your game. People only always yell at you when it doesn’t. “The save points are too far apart!”, for example. “There is no quicksave function!”. I can almost hear them yelling right now. True, this makes falling asleep much harder, but on the bright side, it also makes sure that there is the option of saving in our game.

In fact, the engine we use (more on that maybe soon, or maybe never, who knows what happens with these updates!) has saving implemented natively, so it’s all not such a big problem. Given that I like to make things complicated – and that there were a few problems related to certain properties of objects, as well as the pointer and handle-management, it would have been a total nightmare to fix these problems. Another problem: The game has a big emphasis on events that happen on a timeline (its not a rhythm game, even though this could be interpreted as if it were) and I was worried that saving and loading could mess that timing up. So we put a certain restriction to that in place – it sounds stupid on paper, but it’s not that dramatic and makes our lives much easier. Another advantage – albeit a small one in this day and age – is that the save files are much smaller. You can have up to eight save files at once, although you really don’t need that many. You can name them however you want. As soon as you’ve choosen the name, the game saves the part at which you are (i.e. what level to load and what characters to place), the items you have, etc. etc. all in the file. That’s all there is to know, but it was work to create it and as such, it is worth to write about!

I hope.

Tomorrow: Loading said save file.

-E

Secret Mystery WIN!

Wow. So now, with all the daily updates, the Secret Mystery Game category has surpassed not only any other category as far as the number of posts goes, it also surpasses them all combined. So many things you know about the new game! I hope you all learned something.
I certainly did. Never, under any circumstances promise daily updates when you can’t simply make a screenshot and use that.

-E

Different styles collide!

Wow! That sounds… that sounds as if that post is going to be awesome, and not in the “not-really-that-awesome”-way. It’s not, however, but it certainly has a nice title.

In our oh-so-secret, oh-so-mysterious game, there are, in fact, several styles colliding. However, one could say that they become a new style in that way. See, there is the “normal”, realistic, kinda boring style. It’s what everyone is trying to make these days, I guess, only we don’t focus on it so much we cry foul when there is not enough grass on the floor. No, it’s just about giving a general feel of the environment and to create the athmosphere. Given the circumstances of these scenes, only a realistic style, with a few exceptions here and there, would make for an believable sequence. However, the character you play is actually not part of that scene – he doesn’t fit in. He also doesn’t have a realistic style. Certain facial features are exaggerated, the proportions aren’t 100% how they should be, all that stuff. I was worried at first that this would make things look weird, that the character would stand out too much and it all would look inconsistent and like a big mistake. Thankfully, that wasn`t the case and the desired effect was achieved: The two elements that actually have no real connection between them have different styles and as such also a visual difference that makes you see immediatly whats going on.

There are also other sequences, where it may just be the other way around. Different people of different worlds meet, and so do their styles. You have to make the differences noticable (otherwise it seems like you just messed it up), but you mustn’t overdo it – but then, thats always the case, huh?

-E

Whats grey on a babyblue background?

The answer to this is the current state of Dennis level. I can prove that, too.

Are you happy now? That is a top-secret behind-the-scenes development screenshot. I’d love to tell you more about it, like how long it took to create it or what part was the most difficult of it or why the background is babyblue of all colors – but I can’t. Because I simply don’t know. I’m not the one creating that level. I’m only the person who does the code and writes this stupid text that barely qualifies as placeholder.

There is also a second screenshot, and it’s more exciting than the other one, because it uses perspective and gives you that decidingly 3d-ish feel.

That is quite cool. You feel like you are really there. And… wonder why there is no ceiling. It makes you wonder what kind of people live there. Maybe… maybe magical, powerful beings who struggle with their situation. Maybe dwarves and elves and unicorns move around those floors. Or, it is a secret building of the FBI. Or maybe, the mafia lives there. Who knows? We do, of course. But we’re not telling. We promised to keep it secret.

And thats it. Maybe some day, a certain person, by which I mean Dennis, to completely eliminate any possible doubts, will elaborate further on this topic and tell us the exact amount of windows, how tall these are, what room was the most difficult to create, what kind of textures he wants to add in the future and how he handles lighting. In the meantime, you’ll have to do what we all do now and continue ogling at the screenshot. It’s the only thing we have, and it’s definately showing how you look good in babyblue.

-E

Here is something interesting, then

You thought that pixel-thing would be the only update? Oh, surely not! Let’s have another look at the dialog editor!

Click for the full dialog-editor related goodness

There is the dialog editor again! The things underlined in red are commados, but then, you already knew that. By the way, the editor does not underline these. I did it for explanationary purposes… in Paint. Lets have a look at the upper right part. This is where “Conditions and triggers” are set. You can have up to five for every dialogsnippet. You can break up a dialog in as many snippets as you like (but between two snippets there has to be a break in which the user has to hit the left mouse button to continue), and you can have up to 255 different snippets. And thats just one dialog, which can be all about … anything you want. Like, chocolate. Or candy. Or whatever you want.

In these conditions, you can set things like “If the player hasn’t heard this dialog yet, set it as read”. It’s not that easy, actually, you have to do that via certain parameters of the entity you talk to, but it can be used in that way. Its certainly helpful to know a bit about the binary system here. You can also increase a value to show how annoyed the character is by you. Each time you say “I once knew a man that looked just like you, except he looked good”, for example, he could get more annoyed. He could quit the dialog at a certain point or give different replies when asked something. Thats all possible! It is stored in a few bytes that set which kind of condition it is, the values you set and all that stuff. What happens when the condition is met is the drop-down menu further down – and it includes things like “increase value x”, “quit dialog”, “jump to snippet y”. There are other things, but these are the most important.

So there, that’s all for now! More about this and other tools in other posts.

-E

Sinking to new lows

“F”: 14, “f”: 16

It’s “Courier”.

Todays interesting fact is actually not really that interesting, but still qualifies for an update

Here you go!

With all the talk of facial-animation code and all that, let’s sum it up rather quickly. Old version had bonemanipulation of the mouth (to simulate different emotions and open and close it) and only skin changing for the expressions of the eyes (3, not more). New version does that via direct manipulation of the position of the vertices (in simpler terms: We morph the eye), and does not change the skin. Mouth is still manipulated via bones.

That all is in the file “faceanim.wdl”. It also includes the code for a simple test-section. And it currently has ~2035 lines. Whoa! Thats a lot of lines. If you disregard the testing-code, you still end up with 1905 lines. Of course, lots of these are comments (there are plenty of comments in this file, more-than-average for my standards). Also, this includes both versions. The old one uses just a little more than 220 lines, so you can see that most of that file is for the new approach. Now, can you see why I keep talking about it?!

Tomorrow: How many pixels are in the letter “f” for the font I use in the Editor. Hopefully not.

- E

Movement miracle!

Yesterday, I finished the facial animation code (and fixed the bug mentioned in that blog post). When I sent the current version to T, he quickly noticed that there was a bug in the movement. Obviously, thats totally not what he should test, but then, good thing he noticed!

Long story short, the character was able to walk through windows – in more accurate terms: There were holes in the walls where the windows where supposed to be (no glass there yet). And when you clicked on a spot behind that, he simply “jumped” through it. Which he actually shouldn’t do (Note: In the current version of the level, nodes for the pathfinding haven’t been set yet, which is why the character attempted to go through the window in the first place). So I had to look at the code from many months ago and see where the mistake was. Naturally, it ended up in a more or less sloppy workarund, but at least it works… or so I thought. For some reason, he now didn’t walk through that one door! Where could the mistake be?

I had the character placed further down for the movement (and placed him back on his feet afterwards before the scene was rendered), so maybe, he was placed too far down. So I changed the level to check that. Didn’t work then, either.

As it turned out, the mistake was much simpler and involved changing one value. But then, the character wouldn’t stop when going to the desired target. He’d simply stand there and turning and turning. That’s although related to the movement and at this point, I should probably have just rewritten everything from scratch – but no! I changed the part where the distance was calculated – there was a misunderstanding for the height-difference. I also used bigger values for the distance he may be away at most from the target, that helped too.

And now, everything works. Let’s see for how long.

- E

I expect more professional programmers to point out how extremely sloppy of a solution that is. But I exaggerated in my post, the movement code isn’t that complex. No need to worry!

Slowly going insane

would be a good title for any article about game design, really. “Go insane in 7 days! (… with programming)”, soon avaible on amazon. Until then, we may as well point and laugh at the sad individuals who experienced tales full of dark moments. Surly, that is hilarious for everyone else. Or, it may completely alienate them. Still, its an update for this blog, and thats good enough for me! See how we keep this high quality standard?

This past week I didn’t had much time for my beloved hobby. Thats a shame, gjven that it means that it will take longer until our game full of awesomeness will be released. Anyway, I wanted to change something on the face-code (don’t worry, this update won’t be all about it) – but it didn’t work. I passed both the start- and endpoint of something to the function, but for some reason, they were both the same, regardless of the values I set! Was there a mistake in the function? I checked and the search revealed nothing. Maybe, the mistake was in the calculations? So I went through all of those. Nothing. Well, maybe passing of those values is the problem, I said in a very doubtful voice and used global variables to test. Didn’t change anything. So I reverted again and was clueless: Why won’t this work?! Of course, in the real version, I had more workarounds in place in an effort to circumvent the problem, many, many more.

The problem was entirely in the test I quickly slapped together: When I called the function that triggered all that stuff, I failed to replace a variable that gave the strength of the effect. So I always passed zero, or, in other words, that the face shall not be changed at all. There was no mistake, yet I went through all of it a million times (at least it feels like it!).

The good news is that the code is at least a little more clean than before. The bad news is the amount of time I just wasted.

Meh. Oh man, I always wanted to say “meh” on a blog. For a moment, the internet and, in essence, the whole world pauses and just awaits your comment – and then you say “meh”. Great.

- E

Camera control

One of the important things, again, is the camera. After all, with a bad camera, you won’t be able to see what you’re doing! And thats happening quite often in games – and its always sad to see that. Who knows how much fun this section could be, if I could see what I’m doing. Of course, nobody goes out and says “I’m going to create a horrible camera” (nobody in their right mind, at least), but there are some difficulties you face.

For example, what DOES the player actually want to see? It’s easy to say that when you’re sitting next to him, playing it, but doing it in advance, its not so easy. He might be at section X, but maybe he wants to go back to Section W, so the camera actually doesn’t have to face the direction he should be going to (Section Y, of course). And then, players do all kind of crazy things. Maybe he doesn’t want to go to either Section, maybe he wants to see whats up there on the wall. Again, the camera has to face a different section. You see, it’s pretty hard to do that – and then there are so many other things to consider? Where should the camera go, where should it look at? How fast should it move, how long should it wait in place before it moves, shall it even move or just switch directly?

And then, there are player-controlled cameras. In our game, we have those as well as the non-controllable camera. The controllable camera is used during certain sections and feels like in your typical 3rd-person-rpg, only that you can move the camera freely around the player. This doesn’t work all the time (not in dialogs, for example), but when you are freely able to move or to do anything else, you can place the camera wherever you want. Thats not the perfect solution, oh no. But it would be incredibly time-consuming to create an automatical camera there. So probably, we won’t be doing that. But who knows? Maybe, we will…

-E