Jump to content

On emulation, and why it should be avoided...


Guest Chiv

Recommended Posts

Well, I bet the topic title got a reaction. Before I continue, I'll just make it clear that it was in jest - please put down the knifes

 

Now, I have been observing GemRB from a distance for quite a while - the project excites me very much being a person that has played and enjoyed every single IE game more times than is healthy. The potential for those games to be made up to date and consolidated is tantalising. Having tried it for the second time since it was born, and now that much of the system framework is working I have to say I am stunned. I was initially somewhat skeptical about how likely it was the project would reach this stage, if only to avoid getting my hopes up.

 

I know that the vast majority of work is still yet to be done - emulating the actual behaviour of every spell, script, item etc, and that it will be a very long time before it can be considered playable without bugs/omissions. However, that is not the task that particularly intrests me. I've played all the games as they were originally constructed, and have invariably found each of them lacking in some particular area. BG1 has limited rules, IWD doesnt have two weapon fighting, some spells are in one game but not another, none of the games can match IWD2's interface, etc, moan moan moan

 

So that is what I have come here to comment on. The scope of the project was to implement all the original games in an open source, cross platform, easily moddable engine. It doesnt give much specification on how this should be done, and so with that fact my mind starts playing. What if a completely different approach was taken? Since the project is now open source, it automatically means that it is 100% moddable by anyone who downloads a compiler. Any of the file formats used by IE could be either improved or ditched entirely in favour of something new. Any of the internal rule logic could be changed, added to or completely reconsidered. Absolutely none of the limits imposed by IE need to be acknowledged.

 

With that factoid in my head and refusing to leave, for my own personal experience benefit I've started drafting a design doc for a completely new playloop and object heirarchy. I'm using D&D3.5 rules as a reference, and the open source doom port ZDoom (paradoxically enough) as a working example of a game to draw from. My aim is to create a completely internal system that can be for modified for different games much in the same way as quake game dll's. The logic in this is that since GemRB is open source, the word 'hardcoded effect' becomes a bit moot. I am attempting to design a system that is as flexible, intuitive and logical as possible, so that it can be easily extended in any way a modder would desire. It's my belief that such a system can be made simple enough on the surface that even non coders(like myself, heh), with some direction, would be able to customise it.

 

If I feel confident in it when I have finished, I will start implementing it piece by piece. I've never done anything like this before, apart from rather small scale mods to existing games - but damn, I have to try. The prize - in both personal gain and potential result - is too sweet :)

 

Anyway, this is not a specific offer to help or request for help, I just wanted to trigger a discussion on the idea of re-implementing the rules on a completely blank slate. I am intrested what people think of the idea. In the meantime I better get buried in some c++ reference ;)

 

-Chiv

Link to comment

Well, the main goal is to make the original games working.

We already added some fileformat improvements and new scripting actions that are not in any of the old games.

If you take a look at the source, you'll see that almost nothing is hardcoded in C++.

We don't have to implement every spell/item/AI behaviour

We just have to implement all the spell effects and script commands.

Seeing that GemRB already implemented more than 80% of the script commands and most of the spell effects are actually quite trivial to implement, i would rather say, we are past 50% of the complete engine implementation.

 

However even a 100% implementation wouldn't mean any working game, as there is also a lot of python scripting. All the gui behaviour and even some game logic is implemented in python, GemRB just provides an API. For example, any reasonable person could replace the stat rolling calculations. GemRB provides only functions like Roll, SetPlayerStat, etc.

It is relatively easy to completely rewrite the GUI, to demonstrate it, take a look at PST, BG2 and IWD2.

The engine contains almost no code that is specific to those games. It would be a piece of cake to increase the party limit, for example. Or what should happen, if the protagonist dies. All of these will be moddable by anyone who can write an NPC mod :)

 

You bring up Doom. Well, that is what we won't do. This engine will be 2D. This doesn't exclude 3D sprites for avatars, like in ToEE. But as the engine's title says, it is a game engine with (pre) rendered background. No 3d, no limited tileset.

 

About new fileformats. GemRB's plugin system fully supports new fileformats. The effects are hardcoded, that's true. But we will provide all the effects of the existing games, and add some missing ones. You'll be able to alter all stats of creatures.

Link to comment
It is relatively easy to completely rewrite the GUI, to demonstrate it, take a look at PST, BG2 and IWD2.

The engine contains almost no code that is specific to those games. It would be a piece of cake to increase the party limit, for example. Or what should happen, if the protagonist dies. All of these will be moddable by anyone who can write an NPC mod :)

Sorry, I've only been able to try it with BG1 so far, I'm in another country at the moment and I don't have my discs ;)

 

You bring up Doom. Well, that is what we won't do. This engine will be 2D. This doesn't exclude 3D sprites for avatars, like in ToEE. But as the engine's title says, it is a game engine with (pre) rendered background. No 3d, no limited tileset.

 

Heh, I wasnt suggesting to turn GemRb into Doom, I'm just using Doom for myself to get a general idea of how the playloop should work. Besides, if you wrote a top down renderer for Doom you'd esentially have a 2d isometric game anyway - doom is not quake :D

 

About new fileformats. GemRB's plugin system fully supports new fileformats. The effects are hardcoded, that's true. But we will provide all the effects of the existing games, and add some missing ones. You'll be able to alter all stats of creatures.

 

Of course, GemRB could potentially be expandable in anyway you like, as you are fond of saying, by any reasonable person ;). I just mean to have a go at making it mostly internal, relying only on external files for the tiles, gfx etc. As I said, this is purely a personal experiment to see if I can succeed, and also to see what it would be like - I don't expect you to adopt it or even acknowledge its prescence. Though from my experience with other games, it's much more fun to create new actors/items when you are working with the code directly, since you don't have to stick only to effects or actions that have been made by someone else. Thus my goal is to make the actual coding as simple to users as possible by creating an intuitive, almost template like layout.

 

So I apologise if I sounded high and mighty, I just wanted to announce my intentions ;)

Link to comment
This doesn't exclude 3D sprites for avatars, like in ToEE. But as the engine's title says, it is a game engine with (pre) rendered background. No 3d, no limited tileset.

Wait the minute, I thought ToEE did not use sprites but 3d models for characters? Could GemRB theoretically support them?

I think, i just said that. Though we would rather support avatars in the Blender format. Since blender is open source.

Link to comment
This doesn't exclude 3D sprites for avatars, like in ToEE. But as the engine's title says, it is a game engine with (pre) rendered background. No 3d, no limited tileset.

Wait the minute, I thought ToEE did not use sprites but 3d models for characters? Could GemRB theoretically support them?

I think, i just said that. Though we would rather support avatars in the Blender format. Since blender is open source.

You did but I was so pleasently suprised I was afraid I'm misunderstanding... This is great news!

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...