For those trying to achieve a work-life balance, it takes careful consideration when taking on hobbies that end up being a lot of work. My main hobby project is my game The Day After. While I haven’t perfected the practice, I think I’ve gotten a decent discipline when it comes time to hit Projects Night. (Click here to read the rest of this entry)
Have you ever found a note written by yourself months ago? How it’s unmistakably you, but you have no idea what it means or why you felt it was important at the time? That’s basically the living reality for inhabiting any long-term, big project. It’s that curious combination of familiarity but novelty, like walking through a hedge maze I’m regularly surprised by Past Brett when writing The Day After, and mostly in a good way. It doesn’t make the progress swift, though.
At the risk of eliciting cries of “Oh ya mug!” I’ve made a change to my projects. Whereas before I was steaming away on Kung Fu Chronicles (aka Kung Fu Legends aka that-Kung-fu-game-you’re-making), I’ve shifted projects and priorities around. I’ve discussed before some of the game engine stuff I had been working on. As a proof of the ontological argument (or Omnipotence paradox), I had created parts of my game engine that were so awesome and featureful that even I had no idea how to use them. 🙂 So I was stuck.
I have also mentioned before that I was working on a board game called The Day After. Brief synopsis: You’re part of a band of survivors after a weird cataclysmic event, and should co-operate so that you all get to rescue… but is co-operation always in your best self-interest? The idea of The Day After was to make something in the vague genre that Arkham Horror lives in, but do it better. My main criticism with Arkham Horror is that with all the tokens, characters and special rules, it’d be better realized as a video game. Anyway, I’ve done most of the alpha design for The Day After, but was finding it slow to put things onto even prototype cards and get it all working as a cheap-ass board game to foist upon my unsuspecting friends. I wasn’t sure about a bunch of rules, or any of the numbers, amongst other concerns. Prototyping it for quick trial play was taking longer and a lot more work than I expected.
Late last year when I was brainstorming ideas, I tripped over the idea of testing some of the game elements by programming a dumb Monte Carlo simulation of the rules and run millions of test games to see what needed balancing. It was a great idea, but I realised to properly simulate it, I needed to put in certain AI routines. For example, to be rescued you need to achieve some goal (eg, restore power), signal the rescue (eg, with a radio) and get to the rescue spot. To get virtual characters to jump through these hoops they needed some basic planning or pathfinding, which sounded like too much work for just testing.
Anyway, I was talking about these issues with my mate Alex who floated the idea of programming it up as a game for prototyping, focussing on having debug capabilities to rewind games, tweak numbers and continue. Due to the way he phrased it I had the brilliant idea to make The Day After into an actual video game. It was a simpler project than Kung Fu Chronicles, but would provide me with a simple framework for testing out game engine ideas. I think I’m okay at general game design, but my game engine design experience is almost non-existent. By programming something simple, I could bootstrap my way up to smashing the block I had with Kung Fu Chronicles. Plus it could serve as a nice fundraiser for my other projects. I still would like to turn it into a physical board game, but that can be later along when the rules are more refined. Plus I can give the video game a board game aesthetic (like Dangerous High School Girls In Trouble!) which simplifies and unifies graphic design.
I’m doing much better with this as my primary project. Already I have a better events system, game loop and general approach to objects. When my girlfriend goes on holiday for a while I’m going all-out on my projects. Hopefully I can get The Day After and my long-suffering novel Breathe into much better states. I’ll keep you guys posted on how it goes.
Dev work on Kung Fu Legends has been chugging along. I’ve got the engine into a state where it’s not finished, but the important components are there. Sound, input, the user interface system and basic graphics are all implemented. You can work on the engine for the rest of your life, adding more bells and whistles, and polishing it all to a lustrous shine. But I need a game. I’ve put the game engine on hold until I get more done on the game itself.
I’ve been beavering away at my projects lately with not a lot of interesting news thus far. Nevertheless I’ve taken a bit of time on the side to write up a tutorial for using the debugger in TADS 3 Workbench. TADS 3 is an interactive fiction programming language that I’m quite proficient at, and a bunch of people wanted guidance on using the debugger, so here we are.
As a project update, Kung Fu Legends has moved into some deep design phase for the underlying simulation. The Day After is still waiting on action cards. Breathe still tickles the back of my brain. And my other projects sit on the backburner, as always.
I’ve taken this week off from work to spend some time on my creative pursuits, which mostly means Kung Fu Legends and my novel Breathe. I’ve toiled away at Kung Fu Legends and I’ve finally got some tangible results! The very first screenshot is below. (Click here to read the rest of this entry)
I’ve been a bit sick lately, so instead of going out and having fun, I’ve been cooped up inside. On the upside, I’ve been writing Kung Fu Legends code. So far I have the main GameManager, Options, Graphics, Input, Event management and some testing frameworks set up. I gave the UI a good Harvard try, but fell in a heap. I tried to integrate MyGUI and CEGUI, but both were annoying to attach to my code. Not because of the library code itself, but the accompanying documentation is sparse and scattered, and presumes that I’m using Visual C++. I really didn’t like Visual C++ (it has a workflow and feel counter to my ingrained habits experience). I’m using MinGW so I get all the goodness of gcc, with the convenience of being Windows native. In any case, I wasn’t entirely ready to roll my own UI code at this point, so I moved onto something else.
Next I tried adding sound support. The obvious choice was OpenAL. But alas, it doesn’t seem to come with codec libraries automatically, so I was off on another hunt to get the libogg and libvorbis packages. “This should be easy,” said I, not learning my lesson from the previous paragraph. All the code for the two libraries were there, but to compile it, you needed the autotools library prebuilt. This is kinda okay if you use CygWin, but I don’t. Grr. Getting the autotools compiled through MinGW was too much of a hassle for my extremely low level of caring. I mean it was two libraries distant from my work, so any time working on that meant time not working on something personal. I’m sure it’s not insurmountable, but spending an evening wrestling with that stuff, all the while knowing that my friends were out getting drunk… well it rubbed me up the wrong way, so I put it too on the To Do pile.
So where did that leave me? There are a bunch of engine components that I could write, but seemed overkill. Kinda like installing a glovebox when the car didn’t have a steering wheel yet. Coincidentally, at this time I had gotten a few queries from friends about the game simulation. While I had a half-skeleton of a game engine up and running, by sheer amounts of self-control I didn’t have the simulation even sketched out on the code level. So tonight, I started. Here’s the first demo of the game, in all its glory:
Dude A created in Place A. Dude B created in Place B. Dude A went to Place B.
Woo! To get this unexceptional pile of bits I had to implement a few hacked frameworks (hacking around the EventManager, a specialised TextOutputManager and how I’m doing Events and Actions)[1. And oh god, work around the annoying peculiarities of how compilers deal with C++ templates. My handy-dandy, super-powerful Options framework failed because the compiler was either too smart about types, or completely stupid. As a result, my spiritually beautiful code constructs had to be hacked down to things that the compiler wouldn’t barf on]. But it’s a start and its sorta within the framework that I’m designing[2. Sure, I could have just dumped that string to std::cout, but that’s no challenge.]. An earlier attempt at writing the whole game left me implementing detailed systems I didn’t need yet, but wanted to program. I’m starting to warm to YAGNI (You Ain’t Gonna Need It) because it’s easy to disappear down a rabbit hole of design and implementation relevant to very little. Hopefully I can build up more and more supporting systems so I can start to develop the game simulation in parallel with the game engine. This way I can see if the game idea works in principle, and once the engine is more capable, I can see if it’s “fun”.
So yeah, like all my projects, progress is slow but measurable.
So despite my recent blue-sky posts, I have been writing actual honest-to-goodness code for Kung Fu Legends. I’m working on the boring bit at the moment which is getting all the helper libraries set up and working. Currently I have options, logging and graphics subsystems primed and running. I had to rewrite and refine a bunch of my previously-written stuff to fit a new engine model and set of standards. The next bits to implement are:
- Input (mouse and keyboard)
- User Interface
The UI is the hardest because previous attempts to graft on a library led to disastrous results. I’m tempted to write my own, mostly because I want a lot of custom widgets and not a whole lot of the standard widgets. But this is of course a biggish undertaking.
The reason I’m doing all this instead of the fun stuff is that I need to be able to test my world model. I have two directions I can take at the moment: develop a basic UI and test within that, or leave the engine stuff until later and just test via copious amounts of logging. Both have their merits. For now I’m going with the former, but might just get annoyed and go the latter. You have to be careful though, leaving all the boring stuff to later makes it tough to face it. Ideally you’d work on the two (engine and game world) in concert so the requirements of one can inform and evolve the other.
The other main reason for the focus on the engine is that it’s a reasonably known quantity. My game world and game mechanics are still being formed so it’s hard to set off too far in any particular direction. But the important thing is that I have code that compiles and runs. Woo!
In my last post I discussed a few ideas I had rolling about for motivating players to play my (currently vapourware) Kung Fu Legends. It was focussed on intrinsic motivation – ways inside the game to make players play more. Now I want to talk about a few ideas I had for extrinsic motivation – ways outside of the game to increase motivation. This motivation is not just the players, but how I want to motivate myself to actually write the thing.
I’ve been working on the game engine for Kung Fu Legends for a while now and I’m slowly building it up. It could initialize a bunch of subsystems and print a message on the graphics plane. Real cutting-edge stuff. Anyway, there were a couple of minor things in the implementation that bugged me – my Manager class was written in a weird way with respect to the game loop, and my git repository started some ways into my development and I would have much preferred a complete history. Stupid minor things, but I wanted to rewrite what I had.
Moreover, I had some idea in my head of The Proper Thing To Do which was to separate the development of the game engine (graphics/sound/UI engine) from the game itself, and the best way to do that was to encapsulate it in a separate static and/or dynamic library. This way I had a Proper Division of the code responsibilities and could have parallel development on game and engine. I’d also have hand-made Makefiles because that was more portable and I had a better control over what I was compiling (previously I had used Eclipse’s generated makefiles).
So I tried this new approach. A few days later, I had to concede defeat. The way I was organizing my source code made the Makefiles annoying. And the Ogre3d libraries wouldn’t link against my source. And then my own source wouldn’t link against itself. And then when I updated Eclipse to achieve some daft goal with Makefiles, Eclipse would crash silently to the desktop as soon as I ran it. I’m not a bad programmer or organizer of software, so I don’t think it’s totally my fault. The only other thing I could think was that the Computing Gods had decided that I shouldn’t be messing with things and should just get on with development. To teach me a lesson they sent me plagues of linker errors and bizarre IDE faults.
I’ve since fixed the Eclipse issue and I’ve given up on hand-crafted Makefiles. Oh well. The whole little ordeal reminds me somehow of old MIT hack stories where clearly there is something supernatural going on in the world of computing and it’s not all bits and bytes. The Computing Gods are fickle, but they have good intentions.
Have you made a sacrifice to your compiler today?