From my experience, the problem you are talking about – figuring out what your code should ACTUALLY do as opposed to what you THINK it should do – is a pretty common problem in software engineering. The best way I’ve found to combat this problem is to write requirements for yourself.

This classic article by Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000036.html) explains it quite well, but I thought I’d complement it with some of my own experiences.

As a programming novice I always thought “Why should I write a spec when I’m the one implementing the software? I already know what I want to do, so I’ll just start coding it!”. The problem with this approach is that, more often than not, there is some aspect to the problem that you have overlooked. Eventually you will discover it and go back to the drawing board, but if you’re unfortunate this might result in a lot of code ending up in the trash.

A better solution (in my experience at least) is to start by writing down, in plain english, exactly what it is you want your program to do. Start with the bigger picture stuff and work your way down to the smaller details.

What usually happens then is that you start finding flaws in your initial assumptions; what you thought you wanted your program to do might, in fact, not be what you actually wanted it to do at all!

This is pretty natural because it’s hard to examine a concept in your head so thouroughly that you discover all these tiny exceptions and special cases. When it’s laid out on paper though, it’s much easier to analyze and make an informed decision on wheter it’s a valid solution or not.

As an additional bonus, if you break your whole program down into tasks which can be measured in hours then you have a decent attempt at a schedule as well! (Just don’t forget to multiply all time estimates by 2 ;))

If you write your requirements on the computer or with quill and ink doesn’t really matter, but I recommend using TeX (the package MikTeX + LEd is nice if you’re using Windows) to get some structure into your document.

Hope somebody found this helpful!

Reminds me of this:
http://www.notdoppler.com/voxpopulivoxdei.php

Amazingly fun, even without anything else.

Btw, first time poster. Love the articles you write. Keep it up.

Making it public, to me, is releasing it – even if you put an alpha tag on it. I won’t do that until it’s a fun, fully formed game with proper guidance, an objective, and all of the basic systems I have planned. Realistically, I’m still about six months away from that.

Warren Spector calls this “unity of effect.” Increase polygon count on a character model, and suddenly you notice that the animation is terrible, or that their eyes are always pointing straight forward like a zombie. Increase the visual fidelity of the world and suddenly you notice that the physical simulation doesn’t allow objects to tip over. Increase the realism of the world simulation, and suddenly you realize that vents large enough to crouch in are ridiculous.

Deus Ex was attempting to be realistic, but there was a minimum level of abstraction that was necessary just to get it working on PCs of the time, so it allowed a similar level of abstraction in gameplay. A Deus Ex made on current hardware could probably still barely get away with vent crawling. I suspect the next generation is out of luck. But a cartoony platformer? No problem at all. I bet you could put a double jump in there and nobody would think twice.

http://www.media.mit.edu/~jorkin/gdc2006_orkin_jeff_fear.pdf

I think it might be a great resource for you when trying to write A.I. code. Some googling and wiki-walking may be needed depending on your background on certain topics like the A* algorithm. You may not use the ideas presented in the paper, but it’s certainly inspiring.

Also, is Gunpoint open-source? Some commentators have mentioned playing an alpha build; is it publicly available?

Dave: yeah, I remembered that line as I was realising some of this stuff, and was struck again by how right Douglas Adams was about everything.

Florian: what browser and OS are you on? It’s true my site isn’t friendly to resolution widths below 1024, but on most browsers, you should see a scrollbar rather than anything overlapping.

Also, after seeing the comment about a hat being uncomfortable in a vent, i want my hat to occasionally fall off. Or to be so i can throw it to distract guards. Though, you lose if you leave it behind.

Kind regards.

“What really is the point of trying to teach anything to anybody?”
This question seemed to provoke a murmur of sympathetic approval from up and down the table.
Richard continued, “What I mean is that if you really want to understand something, the best way is to try and explain it to someone else. That forces you to sort it out in your mind. And the more slow and dim-witted your pupil, the more you have to break things down into more and more simple ideas. And that’s really the essence of programming. By the time you’ve sorted out a complicated idea into little steps that even a stupid machine can deal with, you’ve learned something about it yourself.

These are really excellent posts, and really important reading too. I can’t believe PCG aren’t interested in paying you to do this – mixing journalist and programmer is a great idea. You multi-talented rogue, you.

The issue of ‘adding a new event every time I want to change this’ leads into the extremely dull world of Software Engineering. People have developed templates for how to best lay out and organise code for when you have problems like that. It’s very boring, but effective.

Keep on keepin’ on.

I’m not sick of air vents, it’s a nice change of pace to running and can make the player feel enfeebled unannoyingly (so long as it’s not overdone). I think you could also add purpose for them beyond point a to b movement. Say you’re in an above room vent; as you crawl along you can’t see outside unless you pause over a grill, adding possiblities of tension and spying on enemies in the room underneath.

Though I can’t imagine a great coat and hat is comfortable vent attire.

Anyway, good choice – it’s a sound scheme for writing robust goal-oriented behaviours (and, like you say, much more comprehensible when written down than some of the alternatives). A robotics prof at Stanford, Nils Nilsson, described TR programs first, at least as they relate to AI. So you’ve bypassed about 25 years of AI community dithering; SkyNet to be done by, say, Thursday week?

But at the time I wrote it, it didn’t have the www in. So old links will be broken, but I don’t know where.

Nano: no, don’t worry. You’re so smart that explaining it to you didn’t help at all – you understood it.

I can’t help but feel that this arose from when you tried to explain your AI coding to me the other day. In my defense, I was jetlagged. *runs off crying*

More generally, for an example of the ‘making multiple routes in a sidescroller’ problem being solved, see Yahtzee’s game Art of Theft. Even if you’ve played it before, it might be worth a look at again for specific level design tricks. It really is quite lovely.

Oh, and the link to your GalCiv2 War Diary seems to be broken. :(

What I’m lacking is any knowledge of good practice, or established shortcuts – I have to derive everything from first principles. It’s not hard, and quite fun, but I’m always aware there must be spectacularly more efficient ways to approach some of this stuff.

On the topic of air-vents: As you’re doing a side-scroller, you could have the vents be pretty damn narrow. Just enough for the player to be able to lie down in and move very slowly along on their belly. I would not complain if they were included.

Climbing about in vents is kind of boring compared to leaping!