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:
"2$12"

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

Comments

  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.

    ReplyDelete
    Replies
    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.

      Delete

Post a Comment

Popular posts from this blog

Advice needed on tilesets...

I need some advice on which is the best way to handle building the dungeon. Right now I'm using prefabs for my dungeon, they have a north south east and west section for each "room": The basic tileset. This has several advantages, and also several disadvantages. Firstly I can have curved rooms, I can have tunnels and other interesting shapes. The tilesets can look quite nice with a little work. On the other hand I can't easily get the navigation data before building the map and once the map has been built I can't make changes to the layout, like having active pit traps or believable secret doors. Although the rooms are interesting, they are quite repetitive, and it takes a lot of effort to make even a few different variations. Also rooms are constrained to one size. A newer version of the tileset with a lot of variant parts for making more interesting rooms. To create a tile set is a real headache too. Planning how to lay out the UVs, trying to cra...

Upstairs / Downstairs.

I've decided to make my prefabs multilevel. Later this should allow me to add pit traps and other great stuff. It also makes it easier to line up stairs so that you can exit them on the same co-ordinates where you entered them. The prefab editor is pretty much finished, it just needs some code for loading up prefabs from a saved dictionary, so that they can be checked or edited. The entries will need to be forwards compatible, so I'll be loading each tile and then translating the indexes to a new array, that way if I add extra indexes or extra info (like traps or puzzles) I'll be able to update existing prefabs to work with the new standard. Click for a video.

Video Diary 8

Things are moving along well, there's been a lot of progress on the action manager side of things. Actions have finally moved to the UI, so you can initiate actions by clicking the appropriate button. I've set up some dummy actions to show what happens visually when actions are taken, but the actual dice rolls and such are yet to be integrated. The UI objects are also being added, though some are non functional or empty at the moment. Click on the image to see this week's development video. Every time I add something big I also add about a dozen small things. Like the selection box visualization. Previously this was using render.drawline, and old fashioned Blender function which can be impossible to see at certain resolutions, or at certain frequencies. I replaced it with a function that adds planes of the right size and scale in the right location. I also made all characters a little bigger. I still need to do some work with vectors and final target locations t...