Herein lies the tale of Gridfolk the failed 7DRL. It is a tale of ambition, time squandered, determination, excitement, and defeat.
I admit my ultimate vision for this game was over ambitious. I wanted to create a multiplayer roguelike, where players could dig and construct in a 3D world, similar to popular games like minecraft or dwarf fortress. My unique twist was to merge this with the roguelike notion of grinding through deeper levels with harder enemies. Players would mine and collect minerals, which could be crafted into all the items they would wear. Deeper minerals would have better base values, which would in turn create better gear. Rather than a procedural dungeon, Gridfolk’s depths would be player created. I also had some interesting plans for resource conversation. Players would only be able to keep their worn gear when logging out, and dead/abandoned characters would have their gear stripped and made available to spawning monsters.
I almost completely wasted the first day, doing little more than setting up my development folder and ripping code from other projects I thought I could use. The second day I spent getting that ripped code to work in it’s new home. I started with the core of a MUD I had written for a Ludum Dare, code to turn images into a map array, and some poorly written widgets for libtcod.
The next 3 days were spent on the map, it’s display on the client, and the entity layer that informed clients of what was in view. I made some poor decisions in the beginning, jumping into things that should of been planned carefully. It wasn’t untill day 5 that It was mainly working. I really began to question if the project would amount to more than a tech demo of map streaming.
I fixed every bug I could find, then moved on to the menu system. The client was really a ‘dumb terminal’, the server kept track of whether the player was in a menu, otherwise routing input to the normal game state. It worked well, and I was able to quickly create all the menus or information screens. I wrote a random monster generator, that could create level appropriate monsters with interesting names:
‘the grospi’, ‘the horse’, ‘the trout slime’, ‘the humuga’
I got the monsters spawning, and wrote the simplest ai move-to-player script possible.
I upgraded the ai to flow to some degree. Then I implemented the real time combat. Monsters died, and after sorting through a web of pointers so did the players. I began soliciting friends/family to test it as I coded, and found out it needed 32bit python to run. I added the run and dig commands, added the hp bar, and in the last 40 minutes put in a simple exp/level/class bonus system.
I initially submitted the game as a success, and was exited to have people log into my server and try it out. Then I began finding bugs. Dependencies that were unused but prevented it from running, the leveling and class system wasn’t giving boni on level ups, the map I had drawn was far too shallow, and the game crashed if you dug lower than that. I also found that I didn’t have my ports forwarded and couldn’t receive connections. After checking out a few of the other (excellent) entries I decided to reclassify Gridfolk as a failure.
What I’d like to do differently next time:
- Take advantage of the features of libtcod, especially pathfinding and FOV.
- Set up my generic engine ahead of time, I’m not sure if next year I’ll attempt something multiplayer, but my week should be spent making game features, not base architecture.
- Learn how to use py2exe to package the game.
- Set aside much more time for testing and debugging, perhaps even two days.
I’m not sure if I’ll continue work on the project, the mess of competition code is already fading from my memory and I have plenty of other game projects in the wings.
If you’re interested, the project files can be found here: