Re: what do i need in an rpg engine?
@13
SO I don't have the time for the long version, but I've been giving a lot of thought to this lately.
Firstly, as a blind programmer, coding your game in code isn't actually unreasonable. In fact on my to prototype as a Synthizer test list is a map language that's basically just a bunch of Python classes. If you go really far with this (and you shouldn't--it's hard enough that things like "Use C++ to embed V8 to..." come up) you can go so far as reloading the entire game while it's running with a keystroke. You should have your levels be separate from your game in the sense of being decoupled, but there's nothing saying your levels can't be .py files that build the objects, and a bunch of helper methods to build the common things. If we were sighted, dialogs and stuff would be nice, but I tried that. It's a dead end for anything really complicated, no matter what you do there's just too many things to tab through.
Being in code also lets you define your events right there in Python in the same file that says this is a sword that does 10 damage, then you .add_magical_effect(percent_chance, my_function) and done.
Second, give your objects ids, I like strings, "the-magic-sword-5" "western-temple-orc-guard-7" etc. Then you can look up any object from anywhere and you can have well-known ids somewhere, plus saving to disk/the network/etc are all pretty easy.
Saving quest progress etc. usually happens through quest flags, which you can either save manually or, if you go the route of being able to just save object hierarchies, you let the object hierarchy saving thing do it and just give the player a bunch of quest flag child objects (but getting into how to write really good serialization is the long version I don't have time for).
The solution I came up for with items on maps is this, but it comes with a disclaimer that the solution was invented because how I was doing it failed and I haven't coded it because Synthizer etc. There are actually two kinds of items, not one kind of item. The first kind of item is the magical sword of magicalness: a concrete description of something with some code attached, which you edit in the level editor and give a descriptive ID to. The second kind of object is a reference to a weapon, which gets the id of the weapon, and holds any other state about the weapon that modifies itself while the player is playing. Why do you do this? Because then when you modify the sword as the level designer, the sword itself isn't in the player's save file, all that's in the player's save file is the ref, which records that the player has the sword.
To actually deal with spawning them, it's the same thing as quests, if you want some items that don't respawn. You just put whether or not the player got the object in the quest flags and don't spawn that ref into the map if they did. Or you examine their inventory and see "do they have a copy of me" or etc.
You're thinking one level too far down the chain of abstraction. In actuality you don't retain a bunch of specific lists of things, you don't want to write this as some giant overarching algorithm that figures out spawning. Let objects make decisions about themselves. For example there is nothing wrong with always having objects on the map, but letting all the objects in the game disable themselves, and if an object is disabled it's still there but you never tick it, whenever you iterate you skip it, etc. Then your refs on maps can just switch themselves off and on due to whatever. And for object hierarchies, juist give every object children and then the map object knows how to simulate itself by looking at what it's immediate children are.
And okay, so your next thought is going to be--but how do I spawn these things? Just make a spawner object that knows how to check a quest flag or whatever, and tell the spawner to invent a unique object id and spawn an instance of this other class over here in whatever it's parent is.
But also...you're thinking too much about data structures too. Think backward from the end product some. How does a level designer use it, if you're going to describe the levels in code what does a convenient level language look like, what specifically saves on the player's save file (hint: much, much less than you seem to think, I'd look up how sighted games do this).
Maybe I'll explain serialization later when I have the time to write something that makes this look like a short post. I sort of want to write a library for it, but time and higher priorities. Suffice it to say that you can knock together something that will save literally the entire game world as it is at any point during gameplay in a day if you know what you're doing, probably less, and that the actual problem once you have that isn't saving too little, it's not going overboard and saving too much and backing yourself into a corner with player save file migration issues that are basically impossible to deal with. I had this, the reason I arrived at refs as a solution isn't because they're convenient. They're convenient but the real advantage is that when you have something that can save anything, it's a convenient way to not save things that the game designer needs to change later.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
