Muscle memory and mouse movements

This one is not about mice. Hah, got ‘ya there, huh? It’s about the mouse of your computer, you know, that little… thing that you carefully move around your (just guessing here) probably messy desk. And even that is kind of pushing it, because actually, this one is about one little thing so unimportant, it probably doesn’t even warrant a blog post, even though I already did one for the size of the “f” in the font of… okay, whatever.

The way I implented a certain sequence, it worked like this: At first, I coded the character behaviour in there. After I finished that, I began work on the camera (see earlier entries on this on the blog! Normally, I’d link this, but frankly, I cannot be bothered right now). After that, I made the briefing to the sequence. But depending on what I change and on what I want to test, I may not want to have, say, the new camera system active, or the hint system. So I can switch it off before that sequence. There are threequestions in total: Do you want to see the briefing, do you want to activate the new camera system, do you want to activate the hint system.

Given that it all was finished for a while until I decided to rewrite the code, most of the times that I started the sequence, it was related to bugs regarding the camera and the hint system, so I always said “No, Yes, Yes”.

But then, I was rewriting the character behaviour. I didn’t remove those questions before, though (should have commented them out), so I was always asked these questions. I did not want to have the new camera system in place, instead to only have that overview-flythrough-one that I use for debugging, as well as not getting “frequent” hints from the main character, because that was really not what I needed. So basically, I had to choose “No, No, No” – which is easy enough to do, really, I don’t even have to move the mouse – but guess what, at this point, I was so used to hitting “No, Yes, Yes” all the time that even after I finished adapting that code, which took me hours and which, without a doubt, had me starting that sequence about a zillion times, I still misclicked it every once in a while. I got so used to it that I was faster clicking “No, Yes, Yes” – which involves moving a mouse, then “No, No, No”, which involves pausing for a second to think what I have to click. Muscle memory at its finest.

Incredible. Also kind of worrying, what with the frequency in which I start this sequence.

-E

The “other” kind of puzzle

You’ve probably played a game that included puzzles before. Depening on the game, this may hardly qualify as puzzle (“find the correct key!”) or it was so difficult that the whole game (or, at the very least, sequence) resolved around it (“create your own key, by following roughly 238,935 steps). But there is a also another difference to puzzles that I noticed one of those days.

Its pretty simple, actually: The mechanic itself may vary. Let’s say the puzzle is to get an object to a certain spot. If you click on the object, the main character may just take the object, adding it to the inventory. From there on, you just select it and click on the spot that you want it to be. In these kind of games, the spot will likely have a description and get highlighted and all that (“Suspicious Place” or whatever). The advantage for us “gamers” is that we know that what we’re doing is probably correct: The developers purposely made that spot a “certain” spot, giving it a name and all that. For us, it’s clear that this very position is a special position and will likely have a certain purpose.

For “non-gamers”, this is not necessarily the case. Why is that place “suspicious”? Just because it says so? They may not be able to clearly differentiate as “gamers” do. Which elements can you interact with? Technically, its really not that clear. Just because we’ve had training, we know it already.

So what if there wasn’t that text? Suppose the character would place it anywhere you want, and if its within distance to “secret spot”, then the puzzle is solved. It would still be the same “puzzle”, but without the advantage for “gamers”. Of course, the spot has to be marked in some other way. For me, these mechanic feels like a bigger accomplishment when you finish that puzzle. And thats why “that puzzle” in “that sequence” of “that game” we’re currently “working on” is done like that.

- E

Limiting options

Wait, what? Limiting options? That doesn’t sound good. Why would you want to do that?!

It sounds horrible. It sounds like we’re knowingly withholding features from you, like we’re only going to put them into a sequel or something. Rest assured, though, that is not the case. The point is: Sometimes, you simply have to cut stuff in order to make it a better game. It sounds like a good idea to let the player decide everything: Would you like the health panel at the top or the bottom, left or right? Which music track do you want to listen to, and when? How loud? Should we invert the y axis of your mouse? Or maybe only the x-axis? You see, the more you do this, the sooner it will happen that you also include pointless options (see the x-axis example). In the end, your options-screen will be filled with icons, most of them pointless or only relevant to 1% at the most of your target audience – and those are still looking for the option through the other 80 icons. At this point, it becomes a chore – you want to play a game, not set it up for hours. From this point of view, it makes sense and is simply necessary to decide some things for the player and to not give an option, although that wouldeeb technically possible and maybe not even difficult to implement. It’s just tempting to simply say “oh, we let the player decides, so everyone is a winner!”, but while it certainly sounds good, it doesn’t has to be a good thing.

You also have to keep these things in mind when designing the HUD: Which elements does the player really need to see and which ones can he do do without? How much space should we occupy at most, what font should we choose, how to ensure he understands everything at first sight and no questions arise? What information can be put into a seperate “Notes”-screen and how should that one look? If he activates feature XY, how many things should be displayed in addition to the general stuff? All that has to be decided. So next time you play a game, see how much useless information is displayed on the screen (note: I guess that isn’t that much of an issue for most commercial games, it’s just an issue I noticed during development).

Unique ways to waste too much time in the creation of games

This is a great title, because its longer than a summary of the following few billion paragraphs. Not that I’m going to write that much, but sometimes, or so I’m told, people think that the posts I write are too long. And because I always accept criticism, I didn’t set them on fire. Well, okay, not all of them, because that one guy got away.

And reading my posts surely is an awesome way to pass the time. It’s not quite as awesome as commenting – ahem - but then, I always like it if I get stats that I can interprete as someone reading this blog. But thats not what this blog post is about, oh no! Instead, I’m going to tell a little story from the development again. Gather round, as I start telling this amazing story.

In one of the “sequences” (imagine this to be the “super secret mystery”-kind of quotes), something happens that, according to ol’ Kiyaku is “pretty scary”. And it is – it’s designed to shock you and the way the game works, it also is unavoidable. But rest assured – “that feature” helps you with it – and makes the whole thing crazy fun. It was great the before, but due to the way it works now, it’s just amazing. Yesterday, I probably wasted way too much of my valuable coding time because I was doing “that thing” in “that sequence” over and over (there are no quotes for “over and over”). Actually, I just changed a large part of the code and its structure (as “regular” readers alredy knew!), and this has to be redone as well – it’s not quite completely working yet, and still I can’t stop watching it again and again. Insane. It is technically not needed for the game – it’s just a detail, an added effect. It does have a point, so there is a reason for its inclusion even at this point in development, but it makes this whole thing feel so much cooler.

Always remember – the main power of your main character should be useable often and should affect lots of things. For some things, thats easier (setting things on fire, for example), for some, its harder (great communication skills – but you could still allow the player to talk to everyone and get information in return), but you should still try to add it – the player should be remembered as often as possible that he is awesome.

This blog post would have been much better if I could just state what I’m talking about. I mean “that thing”? “That sequence”? You totally don’t know anything of it. Sorry, guys. But there is a lesson in here!

Few things are greater than a sudden realization like this: What we are doing works. And it’s fun. That’s reassuring – all prototyping aside, confirmations like this every once in a while are just what you need.

-E

“Try again”

You know how in some puzzle games, when you messed it up and you either lost or can’t continue anymore and the game tells you to “Try again”?. They are always so cheerful and, for whatever reason, naturally assume that I am as well, completely ignoring the faint possibility of horrible and powerful hate and rage flowing through my veins because OH MY GOD I messed up again and it’s way too late to try again, but then, you’ve already invested too much time and you can’t backup now – it’s too late. Now, you need to beat the game. Actually, that’s a good thing. It shows that you have fun with the game (although maybe not in a healthy way) and that the game concept is at the very least addicting.

As soon as you’ve managed that the player wants to finish a certain section, you`ve already accomplished something. It might be that the underlying mechanics are so fun that he wants to try again (your typical puzzle) – or just that he wants to find out how the story continues (not quite as elegant, but very effective, albeit in a different way). Ideally, he wants both. Of course, thats not possible in every game, but, ta-dah! It is in ours. If all goes well, that is. We’re certainly trying.

Certain sequences have a certain underlying structure that is at its core close to a puzzle game (with a bit of adventure mixed in) – and it is possible that you don’t reach your goal. Now, of course we could just show “FAILURE” in huge letters on the screen and be done with it (side note: Super Smash Bros. Melee does this and it works due to its feel – the audience going “ooooh” and sounding really disappointing works wonders), but in our game, we use a possibility opened due to the underlying structure referred to at the beginning of this increasingly long paragraph. From then on, it’s easy for the player to simply “rewind” – he doesn’t have to enter a menu to do this or wait for the level to load again, it will simply happen. It also allows him to see the sequence again and look for certain things that he might have missed. There is not the “Try-again”-message on the screen, but he can still try again – and is encouraged to do so.

We encourage the player to experiment anyway: There is no Game Over (not even a “Try again” that does, in a way, suggest that the player has failed and thus needs to try again), no harm done, it’s all okay, don’t worry about that. And that even though what happened might have been pretty bad. But next time – so we hope the player will think – next time he’ll make it!

The advantages of planning

Oh, it was so obvious that it would happen. Like many hobby game developers, there are many projects that I’ve worked on in the past (It’s not so long ago that it warrants writing “the past” in italics, but I like the athmosphere it creates, as if we were sitting around a campfire). Now, there were mini games and, of course, also bigger projects. It happens so easily, you get carried away with your amazing game idea that has never been done before (at least not in the same way or as awesome or…), you need to start right away, to make sure people – and, most likely, yourself – can play it as soon as possible! Who needs planning?! With all the motivation, you could finish it twice!

Yeah, only that this it not the case. Sooner or later, you will run into problems you didn’t think of. Thats really nothing to be ashamed at, its a risk that happens often. The more innovative your concept is, the more difficulties will you face: How should part X play out? What kind of reward should this give? Things might turn out to be just a lot more difficult than you imagined (and you have to find a way to make it easier), to be finished a lot quicker than anticipated or – and that is by far the most horrible of them – it might turn out to be simply not fun. It’s not a nice feeling to see that this amazing idea you had and all the work you’ve put into it is pretty much worthless – a game that’s not fun.

So… how do you minimize this risk? How can you guarantee that you won’t face any of these troubles? The surprisingly easy answer to that is: Probably not at all – it’s impossible. You cannot guarantee that, and most likely, you’ll run into one or two brick walls sooner or later. No, the question is how to minimize the amount and how to minimize the risk. And this is where planning comes in. If you have a new idea, an idea thats really unlike anything you’ve ever played, you ought to try it out first. Create a prototype and see if its fun, or see what values and mechanics you still have to tweak. I’ve basically only created prototypes for a while – some of them can be seen on this very blog (although I’ve spiced them up a little with graphics and sounds and all that).

Thats not all there is to planning, though. Yeah, yeah, we all heard more than enough about design documents and sure, they are useful and writing one forces you to decide things – which is good. Often when I think of a possible game concept and encounter a point where one has to decide between two things, I prefer to skip that decision and think about a part that doesn’t require deciding. It’s nice to keep things in your “OMG-AWESOME”-dream world, but not so much for real games. Sometimes, you just have to decide. Even if you take the wrong decision, often thats better than not deciding and keeping things in the air and having millions of options of which many aren’t really needed. If you only decide at the very moment in which you sit down to code the whole thing, it’s probably too late – you will decide for the wrong reasons or criteria (what is easier to code?). The more of your game concept is done on paper when you start coding, the better. Thats not to say that you can’t change things later, thats something that should and will happen.

I’m only writing all this due to this really big change I’ve talked about and that I’m now implementing. That was a big change in the plan, and while I’m still not done with it and am facing problems that I didn’t had to before, I still think that it was for the better. I already found solutions for most problems (although I didn’t implement them yet – see, my time is limited), so it’s really not that bad.

Now, if only I did better planning… and I assure you, I did plan this game – while not being extremely huge, the game is already so big that you’d lose the overview too soon with no planning. Well, I might have thought of this issue more, I might have thought of the other approach and I wouldn’t have to rewrite so many things. Well, maybe next time, I guess.

-E
Disclaimer: I actually have no clue of that, really. I’m doing that for a hobby, but the hobby is really more the process of developing. I like getting feedback and thus want to finish things, sure – but I’m not in a need to do that to pay my bills. So what do I know.

Collaborative To-Do-Lists & Changelogs for motivation

Today, I wasn’t so productive from a pure coding-standpoint. No, sir, I was doing something different – I created a wiki. This wiki won’t become an encyclopedia (hah! of all things), but is rather a way to organize: It holds a To-Do-List as well as a changelog, as well as a few other things (Buglist and a list of assets).

No, obviously, a To-Do-List as Wiki makes perfect sense: Every team member should quickly be able to see which tasks need to be done, for whom and why. It also avoids micromanagement when everyone can simply check him- or herself what he or her can do next. To help make things more interesting and as a nifty trick for motivation, items aren’t simply deleted from the list, but are rather crossed out. The idea is that its always more motivating to think what we’ve already accomplished, rather than what we still have to do. “Ooh, look at what we have done already! We’re almost there!”. The wiki also allows anyone in the team to edit the page and to add new things to the list. To keep things organized, things are sorted by type (Code, model, etc.) and get a color depending on how urgent it is (very urgent – red, not-so-urgent – green).

Also mainly there for motivation is the changelog – every team member is encouraged to do something – even if its only a little thing – every day. This should then be entered in the changelog. Ideally, you get lots of entries for every day and can see how the game evolved and grew. We`re toying with the idea to upload a screenshot every week to see the progress also in this visual way.

So… will this help? Will this ensure that we finish the game?

I hope so. I already added wikis two times for projects, and both failed. Granted thats really not the wiki’s fault, but what I’ve learnt from that is to keep it simple: Our team is pretty small, so there really is no need to create lots and lots of pages about every little thing. For example, everyone in the team already knows about the story (and can look in the DD if questions arise), so there is no need for an extensive story-section. Maybe I’ll create a story-overview, but I don’t really want to create a page for every panel, every animation frame, etc. Certain parts that warrant a closer look may get its own page, but I don’t want to overdo it – we want to work on our game and not our wiki!

-E

That sudden flash of genius

I didn’t expect it this time. I was so close to falling asleep, and I really needed sleep, heck, it was late already and then, without warning, it hit me. Of course. So obvious. Why didn’t I thought of that?! It’s so clear now. In these moments, it’s hard to hold back from jumping to the computer and code away until whatever you thought of works. But said tiredness was too strong. “Tomorrow”, I mumbled, “tomorrow I’ll do that”.

But even then, sleep was far away, while I was thinking and improving the idea. How could I do that exactly? What would I need to do? Wouldn’t it kill performance? What is with these kind of situations, how to handle them? How would this work?

Oh. Wait. Doesn’t that mean that I have to rewrite that huge part of the code?!

Maybe the idea isn’t that good. Actually, now thinking about it, its also not as innovative as I first thought it would be. Certainly it was done before. Would it really improve the experience? (Always a good question to ask before you change your plans!)

The reply after a bit more thinking to that was: yes, at least enough to warrant the inclusion and to warrant rewriting that part of the code. And now, I’m doing that. Certain parts of certain sequences have to be changed. And while it is not really an elegant solution, it is a working one thats simply good enough. It means a bit of work, but I believe it will be worth it. Early tests already point in that direction – It has also conveniently killed a bug that was really bugging (hah!) me to no end and allows me to improve a certain other feature to make it really usable. Even more, something else that was a problem before for which I had no real solution (I had an idea as to how to fix it, but it wasn’t really a good idea – certainly none that I was comfortable with) is now no real treat anymore. All in all, I couldn’t be happier. I guess. I’m not yet done with rewriting, so who knows what kind of problems will arise. I’ve made backups, just in case. I’ll also delete this post if I need to use them, because otherwise, you’d know how many problems that old code made (to be fair, it’s not as bad as it sounds here).

Wish me luck!

- E

A heartwarming story about minor characters that is actually not really heartwarming

Yeah, you’ve heard me rant countless times about “characters” and their “importance” and “story” and bla-bla-bla. What’s with the minor characters? Is there no love for them? The answer is: Of course there is, only not as much, because they are actually just there and don’t serve much of a purpose and could be replaced by anyone, really, and who cares about them anyway. But because we care, we’ve written a backstory for them as well! Okay, so not for all of them. But for the minor characters that are between “super-minor” and “almost important”. The ones that are needed to advance the plot, and whose characteristics affect it, but who are by no means really important for the story.

Unfortunately, I, as in “E”, keep forgetting about the dates in his backstory. When was he born again? I never know that. Today, I managed to put his birth about 60 years in the future, so it came close to the date of his death. I could still remember his age, and the cause of his death – but when? No idea. Thats why I was so bad at history.

T, however, is different. He knew that his birthdate was ‘63, he knew when IMPORTANT EVENT NO 1 happened and had also a general idea as to when what happened. Unlike me. I still knew what he did and why he did it and who his friends and what his problems were, but embarassingly had to admit that my projected birth date, as well as the date for IMPORTANT EVENT NO 1 was totally off. That is especially embarassing when you know that I actually wrote his story. But I have a reason for this! I not only wrote his story, but the story of all the other characters and then the “real” story and whats going to happen and how the game is structured and, and, and. I have all that – okay, so most of that in my head, so it’s only natural that I forgot a semi-important (“more like, not important at all”) number, right?

Uh… so don’t pay that much attention to the dates we give in the game, because they might have been in a line written by me, which means they are likely wrong.

-E

Flag-related humor

At one point in our game, you may or may not encounter an object more or less resembling something that could or could not be described as a “flag”. This mysterious object…

ah, whatever. Okay, so there is a flag in the game. But no, the game is not Capture-the-Flag. And as per usual, the player may, if he desires that, ask the main character to “investigate” (right-click). And that is important for objects with little details that could change how they react or what you can do with them – you might miss that the alarm clock is set to a wrong time, but the main character will convieniently mention that. Now it’s your turn to decide: Is that snippet important? Is it something that I should consider? Should I change that? How does it affect the characters, can I use that to my advantage? Etc., etc. These kind of things.

But sometimes, objects do not have these kind of details. In that case, there is actually no real point to the investigation – what kind of information should he tell you about a mug, for example? Thats not to say the object isn’t important, it’s just that there is no detail or thing you might miss otherwise. One of these objects in our game is, and now we’re slowly reaching the point of this post (not a great point though, sorry, I’m just trying to get back to semi-daily updates again!), a flag. A red flag with a yellowish emblem on it, but it’s not important in any way. Now, what line should the main character say if the player clicks it?

The general rule I try to follow is to either give a hint or something good so the player sees it as encouragement. It’s good that he investigates things, they may be important for the game! He shouldn’t have to wade through dozens of boring descriptions, things like: “It’s a flag”. So we try to make the text funny – and this is where things become difficult. What kind of line can you say about a flag that is funny? Without alienating anyone? Or, if anyone is impossible, at least a line that is funny for most people in your audience? And if its not funny, there may be another “fact” that the player may find interesting (although it is open for debate how many people actually want to know when the first flag ever was used or whatever you may think of).

So if you want to challenge yourself, try to think of a funny line about a flag. Then, post it in the comments. Who can post the funniest line??? Oh, the excitement!

-E