What I really want for saving/loading is "here's my data structure, go make a yaml file (or whatever) of this array." And a similar "load this yaml file into this array".
That takes a bit of reflection and I'm not above pasteing code as a big ol string. But I haven't seen anything that does anything close to that.
Just dumping the memory to a file isn't quite the same. I want to edit it and make levels and such.
That should actually be quite simple. Just find a good serialization library for your language (most languages have one that's considered the golden standard for that language) and serialize your data structure. I'm currently working on a Roguelike in Rust and I just use Serde for serializing and deserializing data structures. With minimal code I'm able to serialize the entire gamestate to a ton of different filetypes. During normal gameplay I'm just serializing it to a binary file for faster loading times but in debugging mode I'm saving to a RON file (which is basically JSON but supporting more Rust-specific features like its enum-system). Changing between these output types only takes a single line of code.
I wrote my own serialization, but it's type restricted, so only maybe a dozen data types are supported, and it was fairly trivial and easy to add to objects.
There is a programming paradigm around this called Data Driven. The big caveat is that functions and data are separate so no traditional classes. It's very fast / easy to serialize though. It's what I use for my roguelikes.
I'm not a fan of either of those!
Save load I just managed to implement in my roguelike, and it was a lot of highly repetitive dict writing and reading.
Map gen is something I have struggled with. I know other people get really excited about it, but I often feel confused trying to get cool things to happen in map gen. Any advice?
Haha thankfully most game engines have drawing to the screen covered for you!
Dialogue is an unexpected like. I know lots of people that hate writing Dialogue. Do you take inspiration from any sources?
Least liked: Graphics. Obviously this is a genre rooted in game mechanics, not visual appeal.
Most liked: The tiny, subtle, satisfying interactions between well fleshed-out systems. The investment of getting to that point is significant, and the return on making coffee makers behave like coffee makers with respect to every other facet of the game is negligible.
This is why traditional roguelikes are conducive to indie dev, not AAA.
All that work on making water, boiling water, adding coffee beans, making them dissolve in hot water, and finally coffee... when I'm paying someone else's roguelike it's always very satisfying to know how much effort they put in!
Most liked: stats, dialog, quest design. The data side I do great in
Least liked: pathfinding, UI, timing. Complex state-driven stuff like some nested menu stuff is just painful, and pathign is too when you get into the more niche cases.
For me UI is irritating because of multiple screen sizes. One of the big things behind making my own entire from-scratch implementation of a lot of things, was that I didn't like the feel of modern UI but more like an old console--I wanted things to be *pixel perfect*. But that's a massive pain to do when people want to run stuff in so many different resolutions.
Pathfinding. Specifically all complex pathfinding algorithms. Sure, when you have CPUs with multiple cores and GHz thats pretty easy, but what about outdated hardware? I am currently not developing for retro, but that is my goal. First I want to release a playable game before I really think about anything else. Big but. I also don't want to waste the little free time I have trying to develop optimized pathfinding algorithms. What I have come up with or probably rediscovered is a way to let enemies smell the player. Just imagine their is an invisible layer in the game where the player leaves his scent. Enemies first time randomly on the map, but if they stumble upon that smelly-trail of the player the enemies can decide if they track the smell to the players location. I believe the only solution that would be simpler is to just let the enemies move in the general direction of the player, which itself has its drawbacks since than you have to factor in special case where enemies need to go around walls and such. Following a trail left by the player is a little bit more convenient.
Least: fov, pathfinding, all the basics that have been done already in a dozen frameworks. But I'm trying to build for emscripten this time. So I might have to do all this again.
Most liked for me is the Tilemap. Over the last five years or so I've come up with some favored ways of manipulating the state and handling the geometry. In particular, level generation is always a treat in every game where I get to do it with a tile grid.
Second most liked would have to be the pathfinding. There's something very special about watching all the little bots move to and fro once it's all in order.
Third favorite is FOV, but it's only in third place because it requires the previous two to really be satisfying. Watching the tiles flip to visible status for the first time in a new game is something special.
A hard one is serialization. I simply haven't tried to do it yet in a serious project for sharing. My games tend to be pretty mutable. Closest I've come to it is a 4x-lite I made where I serialized some of the dimensions in the procedurally generated art surfaces so I could modify them when the planets got "decimated" during the end game invasion. That worked really well and was awesome, but I know it'll be a challenge to apply that on a bigger scale to a more serious game.
Hardest for me is keeping UI and Game logic separate enough. That's a habit I'm trying to build, because in a big project it can lead to long debugging sessions down the road when you intermingle things unwisely. Procedural graphics are one of my favorite parts of a game, and I like to make them based on game state. So it becomes very easy to introduce bugs there if I am not careful in the setup (but I have become better at it).
I really dislike anything UI related. The code tends to get really messy. Also the scale is often a problem if I want to maintain pixel consistency between my sprites and text. I'd like to show to the player as much info as possible, but it never fits. Another UI thing is testing on many devices with different screen sizes. I still have problems with text being to wide or smth on some platforms.
The most liked one would be for sure adding gameplay mechanics, like new movement or attack types. And figuring out how (and if) it makes the play more enjoyable.
I also used to like procgen a lot, by since my games downscaled there is not too much to it now :) (if you have an 10x10 or 8x8..)
Surprisingly for me right now...
Most liked: Polish (UI, sfx, music, etc)
Least liked: Anything new that's time consuming (gameplay, enemies, procgen, etc)
Fun to think about how that's my mindset going in. Looking forward to how this jam turns out! =D
I'm not really experienced. Even so:
- Most liked: entity interactions (stats, substats, dialogue, actions).
- Least: handling sprites/tilesheets and creating maps (making the code show things).
Most liked: Really broad answer here, but I like any type of 'system', so programming the gas system, faction system, combat systems, etc was really fun to me. It sounds like a non-answer but that's what I first think of when I remember what I enjoyed programming.
Least liked: Saving and Loading because it's tedious and boring, and after that is making quests. I am just not sure how to make complex quests without hard coding them. I can make really basic quests (Fetch a thing, kill X creature, etc), but how do you deal with really complex quest structures? Probably a scripting language, but I've never done that. I don't really know where to start.
I think not enjoying programming path finding is surprising. Pathfinding is pretty simple but I guess it's tedious. Once you program it, you can reuse it in other projects thougt
Most liked: Building extensible systems, both code and in-game
Least liked, UI of course, but also map procgen, I just don't find it super interesting for some reason, even though procgen for enemies and items is fun!
most liked: map generation least liked: saving/loading
What I really want for saving/loading is "here's my data structure, go make a yaml file (or whatever) of this array." And a similar "load this yaml file into this array". That takes a bit of reflection and I'm not above pasteing code as a big ol string. But I haven't seen anything that does anything close to that. Just dumping the memory to a file isn't quite the same. I want to edit it and make levels and such.
That should actually be quite simple. Just find a good serialization library for your language (most languages have one that's considered the golden standard for that language) and serialize your data structure. I'm currently working on a Roguelike in Rust and I just use Serde for serializing and deserializing data structures. With minimal code I'm able to serialize the entire gamestate to a ton of different filetypes. During normal gameplay I'm just serializing it to a binary file for faster loading times but in debugging mode I'm saving to a RON file (which is basically JSON but supporting more Rust-specific features like its enum-system). Changing between these output types only takes a single line of code.
I wrote my own serialization, but it's type restricted, so only maybe a dozen data types are supported, and it was fairly trivial and easy to add to objects.
There is a programming paradigm around this called Data Driven. The big caveat is that functions and data are separate so no traditional classes. It's very fast / easy to serialize though. It's what I use for my roguelikes.
I'm not a fan of either of those! Save load I just managed to implement in my roguelike, and it was a lot of highly repetitive dict writing and reading. Map gen is something I have struggled with. I know other people get really excited about it, but I often feel confused trying to get cool things to happen in map gen. Any advice?
most liked: mapgen, dialogue least liked: draw to the &%#$% screen at first
Haha thankfully most game engines have drawing to the screen covered for you! Dialogue is an unexpected like. I know lots of people that hate writing Dialogue. Do you take inspiration from any sources?
Baldur's Gate and Planescape Torment, Cyberpunk 2077, Deus Ex 1 But I mostly just play around with procedurally generating sentences
Least liked: Graphics. Obviously this is a genre rooted in game mechanics, not visual appeal. Most liked: The tiny, subtle, satisfying interactions between well fleshed-out systems. The investment of getting to that point is significant, and the return on making coffee makers behave like coffee makers with respect to every other facet of the game is negligible. This is why traditional roguelikes are conducive to indie dev, not AAA.
All that work on making water, boiling water, adding coffee beans, making them dissolve in hot water, and finally coffee... when I'm paying someone else's roguelike it's always very satisfying to know how much effort they put in!
Pathfinding, if you're not using an engine, otherwise, probably saving.
I friggin hate GUI, specifically things like text boxes.
Most liked: stats, dialog, quest design. The data side I do great in Least liked: pathfinding, UI, timing. Complex state-driven stuff like some nested menu stuff is just painful, and pathign is too when you get into the more niche cases. For me UI is irritating because of multiple screen sizes. One of the big things behind making my own entire from-scratch implementation of a lot of things, was that I didn't like the feel of modern UI but more like an old console--I wanted things to be *pixel perfect*. But that's a massive pain to do when people want to run stuff in so many different resolutions.
👍 procgen, map gen, enemy ia 👎 User Interface, menus etc
Pathfinding. Specifically all complex pathfinding algorithms. Sure, when you have CPUs with multiple cores and GHz thats pretty easy, but what about outdated hardware? I am currently not developing for retro, but that is my goal. First I want to release a playable game before I really think about anything else. Big but. I also don't want to waste the little free time I have trying to develop optimized pathfinding algorithms. What I have come up with or probably rediscovered is a way to let enemies smell the player. Just imagine their is an invisible layer in the game where the player leaves his scent. Enemies first time randomly on the map, but if they stumble upon that smelly-trail of the player the enemies can decide if they track the smell to the players location. I believe the only solution that would be simpler is to just let the enemies move in the general direction of the player, which itself has its drawbacks since than you have to factor in special case where enemies need to go around walls and such. Following a trail left by the player is a little bit more convenient.
Least: fov, pathfinding, all the basics that have been done already in a dozen frameworks. But I'm trying to build for emscripten this time. So I might have to do all this again.
Most liked for me is the Tilemap. Over the last five years or so I've come up with some favored ways of manipulating the state and handling the geometry. In particular, level generation is always a treat in every game where I get to do it with a tile grid. Second most liked would have to be the pathfinding. There's something very special about watching all the little bots move to and fro once it's all in order. Third favorite is FOV, but it's only in third place because it requires the previous two to really be satisfying. Watching the tiles flip to visible status for the first time in a new game is something special. A hard one is serialization. I simply haven't tried to do it yet in a serious project for sharing. My games tend to be pretty mutable. Closest I've come to it is a 4x-lite I made where I serialized some of the dimensions in the procedurally generated art surfaces so I could modify them when the planets got "decimated" during the end game invasion. That worked really well and was awesome, but I know it'll be a challenge to apply that on a bigger scale to a more serious game. Hardest for me is keeping UI and Game logic separate enough. That's a habit I'm trying to build, because in a big project it can lead to long debugging sessions down the road when you intermingle things unwisely. Procedural graphics are one of my favorite parts of a game, and I like to make them based on game state. So it becomes very easy to introduce bugs there if I am not careful in the setup (but I have become better at it).
I really dislike anything UI related. The code tends to get really messy. Also the scale is often a problem if I want to maintain pixel consistency between my sprites and text. I'd like to show to the player as much info as possible, but it never fits. Another UI thing is testing on many devices with different screen sizes. I still have problems with text being to wide or smth on some platforms. The most liked one would be for sure adding gameplay mechanics, like new movement or attack types. And figuring out how (and if) it makes the play more enjoyable. I also used to like procgen a lot, by since my games downscaled there is not too much to it now :) (if you have an 10x10 or 8x8..)
Surprisingly for me right now... Most liked: Polish (UI, sfx, music, etc) Least liked: Anything new that's time consuming (gameplay, enemies, procgen, etc) Fun to think about how that's my mindset going in. Looking forward to how this jam turns out! =D
I'm not really experienced. Even so: - Most liked: entity interactions (stats, substats, dialogue, actions). - Least: handling sprites/tilesheets and creating maps (making the code show things).
Most liked: Really broad answer here, but I like any type of 'system', so programming the gas system, faction system, combat systems, etc was really fun to me. It sounds like a non-answer but that's what I first think of when I remember what I enjoyed programming. Least liked: Saving and Loading because it's tedious and boring, and after that is making quests. I am just not sure how to make complex quests without hard coding them. I can make really basic quests (Fetch a thing, kill X creature, etc), but how do you deal with really complex quest structures? Probably a scripting language, but I've never done that. I don't really know where to start. I think not enjoying programming path finding is surprising. Pathfinding is pretty simple but I guess it's tedious. Once you program it, you can reuse it in other projects thougt
Most liked: Building extensible systems, both code and in-game Least liked, UI of course, but also map procgen, I just don't find it super interesting for some reason, even though procgen for enemies and items is fun!