Monday, September 2, 2013
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.
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.
Even if I am in many ways more pleased with the result than last time, I will first focus on what when wrong.
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!).
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. |
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..)
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..)
Saturday, January 26, 2013
5.25" Floppy disks in Linux anno 2013
I was having some fun with one of my older machines, an IBM Portable 5155 XT.
I have a large collection of floppies, though some are of cause corrupted by wear and tear and time itself, but surprisingly many of them seem to stand the tests of time quite well.
I wanted to play some of the games I had played on my first computer, Alley Cat, Pac-Man and Sopwith.. However, having lost those floppies, I only had these game on my fileserver, and not on any floppies, so I decided to set out to get them transferred to the machine.
Luckily, it seems Linux is still well-versed in the dark incantations needed for communications with these old floppy-drives.
After a visit to IRC I discovered that one had to make special device-nodes to make non-(3.5" 1.44 MiB)standard drives function properly on Linux
The drive I have is a 5.25" model which takes 1200 KiB 80 track disks, however, the disks I need to feed the IBM are 360 KiB with 40 tracks, of cause the drive hardware has no trouble with this, as soon as Linux understand which drive and disk it is dealing with, this is where the special device nodes comes in.
The automatically (on my Arch dist anyway) /dev/fd0 is a block device with major, minor numbers 2 and 0 (Floppy disk on controller 0, autodetect format), however, according to devices.txt that comes with your Linux kernel, you will find that for reading 360KiB disks in a 1200KiB drive, you need a device node with major, minors of 2 and 20 instead.
Thus the commands to fix all my trouble:
$ mknod /dev/fd0h360 b 2 20
$ mknod /dev/fd0h720 b 2 24
$ mknod /dev/fd0h1200 b 2 8
This allows me to read the 3 kinds of disks that I suspect I have in my collection.
A note on formatting disks.
You might want to install the msdos-utils package.
Formatting from Linux caused me a bit of confusion and manpage digging as it is a two-step process. Assuming the floppy is either unformatted, or have been formatted for another system (such as commodore), it first need to be low-level formattet, if this is not done, mkfs.vfat will write out funny, strange and random error-messages which will have you think that you have a bad floppy or drive.. In short, if mkfs complains, try a lowlevel format.
In the following I will use use my 1200 KiB drive to format 40 track, 360 KiB disks.
Step 1: Lowlevel format using the fdformat tool, plain and simple
$ fdformat /dev/fd0h360
Step 2: Format the disk with the fat12 filesystem:
$ mkfs.vfat -F 12 -I -c -n "DusteDGames" /dev/fd0h360
-F 12 tells that we want the fat 12 filesystem.
-I Tell that there is not supposed to be any partitions on the device.
-c to check for bad blocks before formatting.
-n to name the floppy.
Mounting is no trouble, just remember to unmount your floppies before removing them! ;)
I have a large collection of floppies, though some are of cause corrupted by wear and tear and time itself, but surprisingly many of them seem to stand the tests of time quite well.
I wanted to play some of the games I had played on my first computer, Alley Cat, Pac-Man and Sopwith.. However, having lost those floppies, I only had these game on my fileserver, and not on any floppies, so I decided to set out to get them transferred to the machine.
Luckily, it seems Linux is still well-versed in the dark incantations needed for communications with these old floppy-drives.
After a visit to IRC I discovered that one had to make special device-nodes to make non-(3.5" 1.44 MiB)standard drives function properly on Linux
The drive I have is a 5.25" model which takes 1200 KiB 80 track disks, however, the disks I need to feed the IBM are 360 KiB with 40 tracks, of cause the drive hardware has no trouble with this, as soon as Linux understand which drive and disk it is dealing with, this is where the special device nodes comes in.
The automatically (on my Arch dist anyway) /dev/fd0 is a block device with major, minor numbers 2 and 0 (Floppy disk on controller 0, autodetect format), however, according to devices.txt that comes with your Linux kernel, you will find that for reading 360KiB disks in a 1200KiB drive, you need a device node with major, minors of 2 and 20 instead.
Thus the commands to fix all my trouble:
$ mknod /dev/fd0h360 b 2 20
$ mknod /dev/fd0h720 b 2 24
$ mknod /dev/fd0h1200 b 2 8
This allows me to read the 3 kinds of disks that I suspect I have in my collection.
A note on formatting disks.
You might want to install the msdos-utils package.
Formatting from Linux caused me a bit of confusion and manpage digging as it is a two-step process. Assuming the floppy is either unformatted, or have been formatted for another system (such as commodore), it first need to be low-level formattet, if this is not done, mkfs.vfat will write out funny, strange and random error-messages which will have you think that you have a bad floppy or drive.. In short, if mkfs complains, try a lowlevel format.
In the following I will use use my 1200 KiB drive to format 40 track, 360 KiB disks.
Step 1: Lowlevel format using the fdformat tool, plain and simple
$ fdformat /dev/fd0h360
Step 2: Format the disk with the fat12 filesystem:
$ mkfs.vfat -F 12 -I -c -n "DusteDGames" /dev/fd0h360
-F 12 tells that we want the fat 12 filesystem.
-I Tell that there is not supposed to be any partitions on the device.
-c to check for bad blocks before formatting.
-n to name the floppy.
Mounting is no trouble, just remember to unmount your floppies before removing them! ;)
Subscribe to:
Posts (Atom)