Tuesday, April 30, 2013

maximumCuriosity postmortem

Disclaimer:
As a professional software developer, my approach to software development is very different from the freestyle hackings I'm doing in both my entries and personal games, they are my venting, my getting away from keeping in line and doing things right, it's the place where I break the rules, where I explore how to do things the wrong way. These hacks are not representative of my work as a professional, I am sure the arrogant argue that people are inherently messy or tidy, and that this quality will always reflect in any work they do, I disagree, I believe there is a place for both and that exploring one benefits the other, only in chaos and noise can we truly learn to appreciate order and silence.


The LudumDare48 Entry


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!).

Thursday, April 11, 2013

Making Solder of Fortune run with any resolution on Linux

So.. I wanted to play some SoF, a game I enjoyed many years ago.
Loki made a Linux-Native binary, and, with the update, it actually still works pretty well!
Two things:
1. The resolution is limited to 1600x1200.
2. If you are using pulseaudio you need the padsp script.

After messing around in gdb, I determined the structure of the video-mode datastructure and wrote a hook to LD_PRELOAD which allows you to use any resolution you want.
Be aware that the menu is not looking correct in wide-screen resolutions (reading mail and such requires you to change into a 4:3 resolution), but the game works just fine.

You can download the small hack at dusted.dk/pages/sof-resolution/SofResolutionHack.tar.gz
It is only 2 kilobytes. Both the source-code and the compiled version is there, along with readme telling you how to use it. This hack also includes the pulseaudio fix.



SoF running at 2560x1440.

And now..  back to what I wanted to do in the first place.. play the damn game in full-screen (yes, I have a screen that can ONLY run that resolution..)