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

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting. Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective.

The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work.

I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography.

You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject...

..,or as part of a fully lit scene to add some subtle highlights. See how alive the subject look…

How to... build a strong art concept.

So you want to make some art assets for your game. The first on the list is a Steampunk Revolver for your main character to shoot up Cthulhu with. Quickly opening your internet browser you start with a Google image search. Ah, there is is!

It might be a good idea to find a few influences so you don't accidentally end up copying a famous design.

Just mash them up and you're ready to go! Off to your favorite modeling program.
But wait! isn't there more to building a strong design concept than that?

Of course there is.
One of the diseases of modern design is that of recursion. Everything is a copy of a copy of a copy. This is especially a problem with "historical" concepts. Over the course of that recursive process the concept becomes infected with modern design elements, and ends up looking very similar to everything else that anyone else has ever made.
If you want to come up with a really fresh idea, you have to get beyond secondary references and go look at real …


Ok, so it's not exactly skynet, but I have got my first AI state working, kind of.

The first state is "HOLD" in which case the agent stays in place where they are and shoots at any unit that comes in range. When I started writing this module, I found that the existing method of triggering actions wasn't good enough to allow the AI to choose the best weapon or target. It worked by simply sending a command to the unit to trigger the currently selected action.

If the action is valid, it triggered, if not it didn't.
That's fine for play controlled units, as that's all they need to do. But AI needs to know in advance if the action is valid. The player can get that info from UI feedback, but that wasn't available to the AI player.

There were three problems:

1. The UI feedback duplicated code in the action trigger function. These  two sets of code could get out of phase so that UI feedback was wrong.

2. The action trigger didn't give enough feedback for …