I don’t use debugger. Well, I start it sometimes in (mostly futile) hope of getting a better exception stack trace. Or to look at the generated machine code in disassembly when optimizing. Otherwise, I find it mostly useless.

I don’t use “debug” build. I always build “release” with debug information. So I’m testing the same code people will use to play the game. Debug info is for getting stack info on exceptions and in some other cases.

When I encounter an error (crash, wrong logic, glitches or whatever) I follow these steps:

• Thinking
• Reviewing
• Logging
• Debugging (or, rather, taking a break)

Each step’s purpose is to get some new info about the problem. If I get new info, I go back to the first step – thinking.
As you see, debugging is actually there, but I rarely get to it. Let’s look at the steps in more detail.

Thinking

Stop and think: what can cause this problem? Is it the result of the code I just wrote/changed? What did I do to cause it? Or was it there before? What subsystems is it limited to? When does it happen, in what conditions? And so on.
Just thinking about the problem often gives some new insights about what can cause it. When you do small incremental changes (and I try to work that way when possible), the changed code is small and easy to grasp with you mind, and the problem is likely there.

Reviewing

Look at your code. Review it. Do you remember it correctly? What is actually written there? (Strange things can happen, especially if you use copy/paste/modify a lot).
Look for things you didn’t think about. Look for things that differ from what you expect them to be. If you use third-party library/engine/whatever, look at the documentation for the things you use to make sure they do what you thing they do, and accept those arguments etc.

If you find something, go back to thinking.

Logging

The code is complex. It can produce emergent results (that’s why you use it in the game, right?) So you might need to look at some values it actually produces. That’s where logging comes in.

Logging is the code that writes some text message to some log. It can be a log file, console, stderr, socket, whatever. You must be able to view all log messages though, and searching and filtering them comes in handy too.

Why logging and not a debugger?
It gives you exactly the info you ask for.
It puts it in context, with other log messages. You can see when it happened in relation to other logged events. You can see how often it happened. You can see how the value changed over time.
You can easily filter what values you log when you have multiple objects and are interested in only one of them. Or only values above a threshold. Or both.
You can surround the code with log messages and find where the exception occurs even when you can’t get a stack trace (be sure to flush you log though).
You can do all this in the release build.
You can do it even when you code for console/mobile/set-top-box/toaster/whatever.
It’s easy to turn off when you release a build. And it can be useful when the problem happens on some other computer, not on yours.

Some pitfalls:
Make it easy to automatically flush the log after every message, it’s essential when diagnosing exceptions or freezing. Or flush it always (might be slow).
Make sure you actually log what you want to log (reviewing helps here). If you write wrong value to the log, it can mislead you for a while.

Visual aids

That’s not exactly logging, but it helps a lot in games. You can write bounding box coordinates to your log, but actually seeing the box on the screen with other objects is much more useful and effective.
Make it easy to add this form of “logging” to your code. Colored lines that fade out over time are useful, for example. You can add them anywhere in your code and see them on the screen for long enough (but not forever). You can make boxes, circles, spheres, arrows or whatever you want just writing a function that conveniently adds multiple lines based on the parameters you pass.
Visualizing AI state, targets, ranges etc is extremely useful too.

Debugging

If everything else fails, you can try the debugger. But what info can you get from it that the previous steps didn’t uncover? I guess doing more thinking or taking a break is better.

So, the next game updates will be at the end of September.

Instead, you’ll get a special link (the key) which you can use to download the game and all future updates. If you’d ever forget the key, you can request it to be resend to your email. The system is similar to what the Humble Bundle uses.

The old system is still in place, so if you already bought a game you can download the updates just as you did before. If you want a new key however, please email me and I’ll arrange that. I’ll reuse the account system for blog comments later, so it’s not going away.

You can also buy gift keys to send to anyone or use yourself. They differ in that anyone can change the email the key is linked to, but only once. So when you send a gift key to someone, they can link the key to their email to retrieve it if they’d ever forget it.

You can buy multiple keys now, so feel free to do so if you want to support me.

If you encounter any problems, please tell me: support@ranmantaru.com

Unfortunately, the new (more secure) account system uses different encryption scheme for passwords.
This means, people who are already registered have to reset their passwords to login.
I apologize for this inconvenience. You’ll get a message when you try to login, just use the “forgot password?” link. It’ll send you email with special link that allows you to change your password. You can actually just enter your old password there, it’ll work.

If there are any trouble, let me know.

Sublime Text 2 caught my eye before, so I started studying and tweaking it. And after 2.5 days of tweaking, I bought it. I’m still not happy with undo/redo cursor movement and other minor issues, but otherwise it’s awesome. Also, it’s cross-platform and the license is per user, not per copy.

So, it looks like I’m going to sharpen my other tools too.
People on Indie DB prefer installer to zip-file, so I’m going to automate building demo and paid version packages and release both installer and zip-file variants next time.
My build system needs some work too.
And I’m going to move game object compiler I wrote for Arcane Worlds 0.02 to common tools and rewrite LEVEL UP! game logic with it. Probably improve the compiler too.

Also, I started rewriting the site. It’s currently messy PHP code which is hard to expand/improve. And I want to drop WordPress eventually.
So I found a nice python web framework called web2py. I’m going to replace “games” section of the site first, and gallery and blog some time later.

This means separate page for each game in addition to current list-of-games page, with more info and videos. Better security. User profile page, and later (when I replace blog too) easy commenting for registered users.

If you’d like some other improvements to the site or have some questions, feel free to comment, e-mail me or send me a message on Twitter.

Against the Wall is an interesting exploration game. I think it has great potential.
And now you can support it, since the author has launched a Kickstarter campaign. $10 will get you a copy of the released game, and $20 will provide access to early beta versions, if you are curious.
If you’re in doubt, there’s alpha version to try out on the site.

LEVEL UP! now runs smooth both with vsync and without it, while updating game logic only 20 times per second. I was afraid of input lag issues, but it looks like they aren’t really noticeable.
And the new game loop will allow me to parallelize both game logic updates and rendering when I’ll get to it, so multi-core processors will get a boost.

Otherwise, the game still looks the same, so there’s nothing new to show for now.

Now I’m going to design plug-in system for Sproxel. I’ll need good tools to make enemies (especially bosses) for LEVEL UP!