[Mattias Gustavsson]

I'm thinking about making my little library/game engine a bit more suited for making RPGs. Mostly because I think it would be fun to do :D

Also, with all the code being public domain, I guess it could potentially be useful to others as well...

So, I'd love to hear what you guys think would be the best things for me to add. What features would you expect from an RPG engine, what would you want in terms of tools/editors, etc...
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine

[Ninkazu]

It should make cake. And blow me.

In all seriousness, there's really no way to cover all your bases without making an extremely bloated engine (that people might still demand more out of), or a very minimalistic engine that requires so much scripting you should have just written it yourself.

My suggestion is to make everything that's controllable modular and able to be hooked either by scripts or dynamically linked libs that developers could add. Allowing compiled code can be very empowering if you provide good enough tools that are easy to interface with.

Step 1: Make your map render in a viewport. This way the developer can make multiple views of the map show onscreen if he so wishes. If you write this with 3D acceleration (which I suggest you do), then you can render the viewport to a texture and allow some funky effects to be added.

Step 2: Use LUA. No one wants to learn a new incomplete and most likely slow scripting language. Make all your API calls conform to a naming scheme you define so your engine looks uniform and well-made; not thrown together.

Step 3: Use threading to handle different tasks. This means rendering should be in its own thread AND IDEMPOTENT. Do NOT let your map renderer change state. This is a bad practice.
Your scripts should also run in a separate thread. You can do a thread for each, or all iterated through inside one thread (the latter is probably better to avoid resource conflicts).
Also, if you plan on allowing (and supporting) large amounts of data, file loading should be multi-threaded. You can lose a lot of loading time by having different modules load their files at the same time. The reason for this is because while one interprets the data it just loaded, the other is blocked waiting on IO. No more idle blocking.

Step 4: Support virtual filesystems. Hell, make everything load out of one or a small amount of zip files. It make distribution so much easier and the user doesn't have to look at a crap ton of folders and flat files everywhere in the game directory.

That's all I have for now. I gotta get to work.

[Mattias Gustavsson]

thanks. although, I was thinking more of higher-level stuff than what underlying tech to use...

I should have been more clear about this, but it's more of a library than a moddable game, in that the expected use is you write your game in C++, calling helpful functions of the library/engine.

And it's that functionality I'm considering adding. Things like dialog systems, pathfinding, procedural generation of environments, stuff like that. As basic helper functions, not as an already functional game you would just drop a few scripts in.

But maybe it's not such a good idea, and maybe noone really wants it? Is it perhaps the case that most people wants a scriptable game rather than a library?
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine

[Jinroh]

[RedSlash]

[Mattias Gustavsson]

Yeah, I guess you guys are right...

I've already got the basic stuff implemented (graphics, sound, input, platform abstraction etc) so I might just leave it at that...

Thanks for the input :-)
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine

[valderman]

Why care about we think? If you want to build it, build it for yourself and reuse for a game or two. If it's any good, others will too.
_________________
http://www.weeaboo.se

[Mattias Gustavsson]

Yeah, I'm using it for my games, obviously... What I was thinking was to add functionality to the library/engine to aid rpg development specifically, but I've reconsidered now, and I'll leave that functionality to my games (I usually give away the source code to those as well, so if anyone wanted to make use of it they certainly could, but I won't add it to the engine).

There's certainly valid points made by the people in this thread; and I do care what you guys think :-) I guess most programmers want to implement the game oriented things themselves.
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine

[Hajo]

There are so many engines made ... and I must admit I like to work on the engine often more than to make actual games with it. I often think it'd be good to work more together, instead of making new engines all over, but it seems to be difficult to organize.

My experience is that interest in game engines is low, almost no one is looking and since there are a number to choose, chances are very small that they pick just yours ... but it definitely will give your projects a boost if you can find interested people.

[Nodtveidt]

I would expect it to be procedural-based, not object-based. Of course, that's because I'm a procedural coder, not an OOP coder. Individual results may vary. :)
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[Bjorn]