My second LudumDare48 ended, LD26, I once again participated in the 48 hour one-man-army compo. The minimalism theme was one I rooted for, and while at first excited about it, it soon became obvious that I did not have any idea at all what to do with it.
I don’t want to spoil the game by showing the ending.
Even if I am in many ways more pleased with the result than last time, I will first focus on what when wrong.
The megashort version:
Wrong
- No software design
- No idea about what to do
- Sleeping to much
- Working too little
- Silly crash bug (Related to first item on list)
- No inventory (Related to first item on list)
- Very little gameplay (It’s more like a shared experience than a game)
- More fail-states (Only time running out can give you game over)
Right
- Neat little wireframe models fit the theme
- Emptiness and strange music satisfies my idea of surrealistic minimalism
- The game is completable and fully deterministic
- If you only play it through one time, you won’t ever see that it is
- Very little code written
- Good use of engine-functions to generate content
Different next time
- More clear idea what to do (Make a design spec of sorts)
- Design the clientside framwork before creating gameplay
- Add more gameplay
The long and ranting version
I have never played myst, and I’ve always been facinated with it, maybe more the idea of myst, I’m too adhd to get into games like that, but I think they allow the developer to focus much more on story and content creation, and the style of a point and click game lends itself well to the minimalism theme in my opinion.
I started with.. A ROOM! Knowing not what to do, I added some pictures to the wall, and started the program, I found that I had forgotten to turn on texturing for the pictures. An idea.. Clicking the pictures could do that! And that’s the premise of maximumCuriosity.
While the theme should be considered quite forgiving, a lack of inspiration should not. Here in Denmark, the theme was announced at 04:00 Saturday morning after a hard week at work, so I was sweetly asleep when all that happened. Waking up and realizing that “my” theme had been chosen, I went back to bed, hoping a dream would bring to me the necessary inspiration, it did not. Waking up after oversleeping left me in a confused and unmotivated state, not exactly my expected state-of-mind, as I had been looking forward to participating the whole week! Nevertheless, Jenkins was prepared, and the skeleton code was waiting. The first (and quite obvious) thing I learned was that one should not rely on discrete states for complex progression behavior. I did not really know what to expect of the game, where it was going or what one should be able to do, so implementing some kind of state-machine never really came up.. There is no one state telling that the camera is now looking at this picture, or that to reach that state, other pictures need to be activated. Instead there is a mess of “If this picture has been clicked this many times while the room is blinking and the tree is spinning” sentences, NOT at all how one should do it..
And quite frustrating to debug too. This became harder when I decided to delete one of the pictures while the game was running. The next thing that went wrong was not really spending 3 hours learning to model the tree, it was that I did not continue to model more things, much more time could and should have been spent creating content, and the task of creating content for this type of project is a quite rewarding one, however again, a complete lack of direction did nothing to help me. Creating something you do not know what is is a frustrating and interesting experience. I though it could be a freeing experience because “hey, it will be whatever it becomes” but nothing comes out of truly nothing. The next thing to go wrong, where a series of strange and random crashes.. The first one I found was that I had forgotten to protect a (particle-system scope wide) variable containing the top datastructure of all particlesystems, this was an engine bug, I’ve called it psys, and much fun ensued when I created an array of structures called… psys in the game, this not-so-particle-related datastructure was overlaid ontop of the particle systems, but C, being the forgiving language it is, gladly did as it was told, and wrote particle-data into this memory-space, and all was good in the word, until ofcause, I took grab of one of the (game-scope) psys structures and wrote data into it, poof, particlecode crashed hard (who can blame it). Next up: Double-freeing data, this one was not really that difficult to find, I had removed a picture from the game-world at one point, then during the transition to the portal, I removed ALL pictures (including the one I already removed). Next up: random crash bug.. I’ve yet to find this, and not really sure what it is.. I did run the game through valgrind a few times, and apart from a few invalid reads (corrupting not-used uv maps during model loading), I did not found anything, and I also did not encounter the bug, I hate that kind of bugs.. However it seems less common with debugging symbols, so it’s probably overwriting internal data, not good, but well.. Can’t have it all, bugs are difficult to find when they don’t show up consistently. The engine is kind of crap, but that’s part of the fun! 😉 Next time I will definitely spend some time coding a basic framework for progression of gamestate. I may start building something into the engine to allow easy management of player inventory, atleast have the GUI support addition and removal of objects to a auto-resizing widget.
Not that much to say, I still believe that walking through the game is an interesting experience (the first time!).
