Blogs - mololu

Following my prior epithany that manegable code requires restructuring when faults are identified, I spent the last few days re-writing features I'd already implemented in a supposedly more sensible manner. In other words, I'm not entirely certain the rewrite achieved its best.

It's simpler, yes, since I added object support for specific tasks (e.g. picking up items, talking to people and other in-world interactions are handled by dedicated objects). But, on the other hand, the individual 'modules' are still bound loosely to their owner in specific cases. That isn't exactly what I'd hoped for. The original idea envisioned a system where individual modules would be entirely free of their owning elements - but that didn't work in practice. There are parts of the Engine which simply have to be accounted for (Objects not being allowed to interact with the wotld without an Actor to pipe their commands through being the key one) - and a few self-inflicted speed bumps I can't reasonably undo anymore.

On the upside, this modulized system offers an incredible benefit in maintainability and readability (though not transparency) of specific code bits. Tweaking specific behavior no longer means hunting through thousands of lines of code. And it isn't even that inefficient in the end. At least, with the game scope we have in mind, it won't make a noticable diference - which is a big yay. Unfortunately, fundamental changes to the system aren't any easier to manage. Hopefully we won't have too many of those once the engine moves into a 'productive' state.

Productive, yes, that's still a long way away. The basics are there, right now, and the model's in place. You can move, interact and set up a (horribly lacking) anim tree to match the intended ingame actions. But what happens next?

Way it looks, I'll be focused on the mundane bits which still need adding. Stackable items, ammo types, conversations and - last but not least - buying and selling are top on the todo list (or, to be precise, right after 'fix death anim' and 'code area damage'). The only thing I can say for certain is it'll be a long way to go before this mess becomes usable for anything close to a prototype. For that we still need a lot of bells and whistles - AI support being the key one. And, in the back of my mind, I'm haunted by little odds and ends which don't add anything code-wise but are needed for a reasonable user experience. There'll be hell to pay for that in future, I'm certain.

On the other hand, looking back, I'm really surprised how far I got in three weeks. Maybe I underestimated myself or I overestimated the complexity of UnrealEngine. Probably both. But the biggest accomplishment isn't the little bits and bytes turning into something that vaguely resembles a playable game. No, it's the feeling this brain-fart of an unterkating might actually be do-able.

Maybe that's naive. Maybe I'm too optimistic. Writing a custom game framework? Alone? Still sounds a bit crazy when I think about it. But I won't know until I try. Going back, giving up, isn't an option anymore. I'm not sure that's good for my overall mental and physical health but that's never been my concenr. And, despite all the frustration, I can't help thinking: this is gonna be fun.

I spent the last hour puzzle-building, which has to be one of the best analogies to humanity's futile nature: 'I make something and take it apart so you can have fun putting it back together'. But that makes me sound like I'm being philosophical, which I'm trying damn hard not to be right now. The real reason I spent time building my girlfriend's 3'000 piece puzzle is because I have to keep myself busy doing something. But let's take a step back...

After five days learning Unrealscript, which isn't half as hard as it seemed before I started, the nemesis of all programming reared its head: self-imposed complications which require ludicrously contrieved solutions - a pattern which recuses infinitely until the code in question becomes so complex it's own creator gives up and does something else. In my case, the root of this great evil would be my lack of forethought. I simply wanted to write my code and went about doing it in the stupidest way imaginable: without the slightest idea what I'd actually need to write.

So, without going into any specifics of WHY my code is such a mess, I've decided to take the next few days to re-think and re-structure everything I painstakingly wrote and debugged. The task is sort of hanging over me like a dark cloud (I don't WANT to re-code everything) but I know damn well, if I don't, the whole 'engine' will fall apart at the seams.

So where am I now? Well, I'll take a moment to get my head straight and then go back to the drawing board (or rather, the A4 paper shamelessly stolen from my printer so I can write unintelligible notes to myself). But I have to ask myself: why the hell did I ever listen to that guy who said 'let's go make our own game'. Yeah. Let's. Next time you write the code and I'll do the concept art.

Entry two on my experiences with UDK and Unreal Script:

With a sensible coding environment set up, the basics didn't take long to implement. But basics mean very little: player controls and camera. It's a good step forwards which took a bit of research, copy-paste and tweaking, but the experience showed me I'll need a solid foundation if I'm hoping to do anything complex with the Unreal Engine.

At this point in time I believe that foundation has to be a set of abstracted classes. In its simplest form, my idea revolves around 'core' classes which extend the Unreal Engine's native code as needed to implement whatever will later appear ingame. Those abstracted classes are then extended by the 'ingame' classes - which would ideally be split into a second package to keep abstract and game objects separate.

The idea behind this structure? Extendability. The abstract base allows any designer to later inherit and extend to suit whatever needs he has - while maintaining all common functions in a sigle place. I'm not certain at this time if this concept will work as I hope but it will be put to the test soon enough.

Another component essential to this design are config files. Assuming the abstraction works as well as I expect, the abstract and all inherited classes should posses configs which can be used to tweak values. That might be an unnecessary step when seen from a programming perspective - changing a few variables in the default block doesn't take long - it simplifies things for non-coders trying to implement objects ingame. Prior experience shows me most people don't like (or simply don't know how) to read code. And, honestly, a programmer doesn't really want to be fiddling with his code either - unless he actually needs to. So implementing config files seems to be the way to go.

If all the concepts above work as envisioned, the next step will be drawing up a conceptional object model of some kind. But I'm already thinking too many steps ahead. So far experience has shown that focusing on one thing at a time for as long as it takes yields less confusion and better results. I doubt I'll be able to continue implementing in 'little steps' indefinitely. None the less, it serves the purpose of familiarization and understanding. It also reduces risk of becoming overwhelmed by several tasks at once and wasting time later debugging all the problems caused by an unfocused mind.

And that's enough of my ramblings for one day. Off to see how weapons work in Unreal Engine...

After days of reading documents and doing little to nothing else, I spent three hours setting up UDK last evening for the purpose of getting to know UDK, Unreal Script and Unreal Engine 3. Man, what a slap in the face. But I figured I'd best share my lessons learned - if only to remind myself when I click on this in the future and re-read my thoughts:

- You're a noob again. Doesn't matter how good you are or how much you know, a new product, a new environment, anything new (like new shoes) means learning from scratch. The only question is how quickly you get the concept. This time I'm not starting with zero knowledge so I'm hopeful but it'll be months at least before it all makes sense.

- Be patient. Really, it's this. When I think back, I didn't know shit about LUA or the HW2 engine when I started PTV (or any of my other half-baked, never to be published mods). The same applies here. In time it will make sense. The initial frustration is simply a by-product of knowing you *could* do it but lack the experience. Work past it - there's no alternative.

- Act and plan simultaneously. Forgoing one for the other doesn't work. A plan only functions if you know how to implement it and you can only act if you have a plan. Until you know something back to front (in this case an engine framework), you have to work from both sides to get as broad a view as possible. Then, when you know what you're dealing with, you can put that plan you've had in the back of your head (or on paper) for months into action.

- Little steps. You can't imagine how good I felt when I managed to get Epic's generic tutorial working and figured out how to close the game pressing esc. Useless? Yes. Informative? Very. I'm three hours smarter on how UDK is set up than I was before. No reason to be discouraged because my first delve into Unreal Script wasn't a cool weapon that shoots pink rainbows. That might be a good step somewhere down the line though...

- Think twice. And use Google. Anyone into IT will know why this is important.

- Notepad++ is for scripting, not coding. Nuff said. Need a real coding environment. That's my next stop.

That would be the end of my thoughts on my first experiences with UDK. I'm sure, when I look back at this in a few months time, I'll feel like an idiot. But that's why I'm posting this, after all.