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
..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.
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.
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.
ReplyDeleteSo, if you adopted SLP, you could pickle your running game logic code and game logic state in one go.
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.
DeleteI'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.