Skip to main content

Revisiting Treasures of the Deep Dwellers

I ran in to some serious problems with Vinland 1936, so I'm shelving it for now and revisiting an earlier project. Kind of.

Treasure of the deep dwellers was a 3d team based roguelike. Some ways it diverged from standard roguelikes is that it had multiple player characters (a team of 4), real time game play (not turn based) and it had 3d graphics. Unfortunately it was a bit more than I could handle.

The new approach is an attempt to simplify the project so that it can function more like a traditional roguelike. A big problem I had before was keeping track of the 4 agents. They tended to run off or get lost. I had to calculate line of sight and map reveal from all 4 agents. Now I've switched to an "Eye of the Beholder" type setup, where the whole team is contained in a single tile.

Likewise monsters are represented in mobs of up to 4 agents in a single tile.
Other benefits of this type of gameplay is that you never need to see the player's characters (except for their portraits), so I don't have to spend a lot of time on art assets. Everything is simplified, from combat to magic and inventories.

A drawback is that first person games inevitably look worse than 3rd person games.
When you can see things up close they don't look as good as when they are far away. The tilesets above are the same but look much better in the 3rd person version. That gives me two choices; Either dedicate much more time and resources to graphics or go for a deliberately retro or stylized appearance.

The plan is to keep it simple and try and get a working game as soon as possible.

It's already given me some really useful insights, and helped me to understand some of the problems that were cropping up in vinland 1936.
One of the biggest issues which cropped up is saving and loading. It's not easy to save an agent which is active in real time. Such an agent is usually running several sub-routines, like movement and combat. These things are structured as python objects which can't be serialized for saving in JSON. There are also problems with saving the map data since I usually use tuples for dictionary keys, which is forbidden in JSON. It's possible to overcome these issues, but it would be better by far to write the game to take them in to account from the very start rather than trying to work them out later.

With this project the very first thing I'm working on is saving and loading. That way I can make choices with a better understanding of their significance. I'd really strongly suggest that any other inexperienced developers do the same. It forces you to always think about how the game is structured and keep in mind what is needed to keep everything in a form that can easily be saved and reloaded. For example with map keys I usually use tuples
(2, 12)
As these are really easy to work with. I could use strings:

..and split them with a function, but this means I have to do this a lot, everything becomes more complex. Better by far to continue using tuples and just write a encode/decoder function for saving and loading from disk.

After finishing the save/load function I also spent some time on the maps. Here's an area where structure is very important. Once I have them arranged how I want them I can start work on things like doors, pit traps and mob spawns.

I think this project will be very useful in helping me overcome some structural issues which were holding me back from finishing my games. I don't expect it to be anything special, but it should be fun and interesting to work on, as well as being an educational experience. I'm going to enjoy playing it too since one of the things that got me interested in procedural gameplay was playing "Dungeon Hack" about a million years ago.

I'm going to finish with an update on the story I was writing, set in the Vinland universe. For now the project is on hold. A lot of it revolved around Muslim characters, but I've had to be honest with myself. I want to write stories that humanize Muslims and not resort to lazy stereotypes, but the fact is I don't know nearly enough about what it means to be a Muslim right now to do that. The project needs a lot more research before I could reasonably continue with it. I'm going to keep all my notes and hopefully come back to it when I've had a chance to read up on 20th century middle eastern history, and hopefully talk to some real Muslim people about day to day life as a member of that religious group.


  1. Note that Stackless Python can serialise running Python code, with limitations in a way where you can move the pickled "tasklets" to a computer with a different architecture. The first paragraphs in the given link go into detail about that.

    So, if you adopted SLP, you could pickle your running game logic code and game logic state in one go.

    1. Thanks Richard. I'm not 100% sure, but from reading up on the subject i don't think stackless python can be used with the Blender Game Engine.
      I've considered using Pickle, since that's better for preserving Python structures, but I want to use the GameJolt API to save and game some data and that only uses JSON.
      So far I've been having no problems with the game as long as I bear in mind the decoder/encoder as I go along.


Post a Comment

Popular posts from this blog

Telling a story; Creating a Compelling Narrative.

Telling a story; Creating a Compelling Narrative. In this blog I will talk about my own recent brush with story telling and go on to talk about how tools from creative wring can help you to better author the narrative in your games, whether they have a traditional linear narrative or a procedurally generated interactive narrative.

Narrative and structure in traditional fiction  last week I started writing a story set in the world I'm developing for my game Vinland: 1936.

I hope the story will help me to flesh out my game world and develop my own expanded universe which will be a good place to set my games in the future.

After about a week of work, on and off I've progressed the story to outline stage. For each character thread I have half a dozen chapters which plot a course through the events of the story. Each thread is told from the perspective of a different character.

Actually I started writing as soon as I had my outline, but I've since gone back and deleted what …

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.

Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

Map screen designs

I've been working some more on the map window. Right now you can only see the base, it doesn't show items, enemies or even doors on the map yet. These would be decals.

In the top window you can see the modified result of last night's tile based map. It looks good but there are some visual artifacts related to the problems I encountered yesterday, and as well it takes much more code and time to calculate.

The second window uses a cheap trick to fake an beveled look from a smoothed version of the 32x32 map. It uses black to mask unexplored areas.

Finally the third version is meant to look like a had drawn map. I'm using a cross hatching texture to distort it and unexplored areas are shown as blank map paper.

There's going to be a mechanic in game where you need to use some paper every level in order to activate the map for that level. From there it will fill it in automatically. Paper will be pretty rare so it might be worth keeping it safe for the more complex level…