Archived

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

no one

my new engine design...thoughts...

Recommended Posts

no one    133
Hiya During my nightly evaluation of my progress and writting down my ideas, I realized something that changed the entire way im going to make my game engine, this idea has been done with the Unreal engine but I never realized why exactly until last night. The unreal tournament engine is basically a 3d engine with a fiew generic game entity classes such as actor, weapon, terrain etc. The bulk of the game code is written in script, which means that to make a new game with the engine, you simple make a new collection of scripts (packages). With that said, my general design plan looks like this: engine.exe - windows code, input,sound,math lib, renderer (I may put the renderer in a dll), scene graph, entity classes, physics, script engine (lua), UI system (menus, hud etc), etc. The entity system, UI system, parts of the renderer and physics engine, math etc will be interfaced with lua. As far as scripting, I think Ill do something like this: CSomeGun = CWeapon:New() //CWeapon is found in the engine CSomeGun.filename = "data/models/weapons/somegun.ms3d"; ... then when you want to add a new instance of the CSomeGun class, obj1 = CSomeGun; obj1.SetPos(...); //automaticly set when the designer places it in the world. etc. Im not sure if you can do things like that in lua, although I dont see why not. Im still a bit unsure about how to handle the scene graph, I think that the objects when loaded into the engine, ill have them all added to the scene list. (Im already using a linked list tree for objects now, so the addtoscene function will simply be recrusive and add the children as well. Alrighty, well any comments, thoughts or ideas, feel free to share! ~Jason Edit: I would imagine that this is what is known as a data driven design, right? [edited by - no one on January 24, 2004 3:30:11 PM]

Share this post


Link to post
Share on other sites
gwihlidal    1004
That was a design that I had worked with before. I had it working with Lua, and then changed to SpiderMonkey (Mozilla javascript engine) for *somewhat* better OOP support.

The biggest issue is speed. Running EVERYTHING in scripts is a lot of extra overhead. Here''s a couple tips that might help:

1) Aim for a scripting language that supports some simple form of bytecode script compilation. Lua and SpiderMonkey kind of have this, it speeds the scripts up a little

2) Put as MANY functions you can into the engine to call from your scripts. I wouldn''t define too many functions in the scripts. I would make a massive library of useful functions in the engine, and just use the scripts for the logic and event handling for the games.

3) If you would like to finish off the engine exe and hardly go back to it ever, (do most work in scripts), perhaps write a DLL plugin system for your engine that could define new methods and register them with your scripting engine. That should keep your scripting libraries (DLL) and scripts separate from your engine framework

Hope that helps you out,

~Graham

----
while (your_engine >= my_engine)
my_engine++;

Share this post


Link to post
Share on other sites
no one    133
Awsome gwihlidal. Do you have any screen shots of your engine?
I will probably do what you said and write a ''massive lib of
functions'' in the engine or dll, whatever, and call them from
the script.

The game will be a 3D rpg which a few of my friends will be making data for. We want to have a ton of charactors, weapons,
powerups, etc so this method seems to be the best for our purposes.

Anyway, what about game monkey, angel script, xml, ... can any of those output bit code? Are they faster then lua? hmm. This could be a topic for a new post

Thanks again!

Share this post


Link to post
Share on other sites
Arwin    122

Hi ''no one'',

I''m interested in the same topic. What should be let to scripts and what should not.

This functions u said that will ve called from the script... are there methods? Can you share some thoughts on this?

And using Lua, how do you plan to send messages to specific instances of some classe?

Thanks!

Share this post


Link to post
Share on other sites
Taulin    100
There was a game called Vampire:masqaurade that came out in 99 I believe that had a similar architecture.

Thay made dlls with all their core code. Then used JNI and javascript to actually make the game. Therefor, all their menus and game logic was done in javascript and called upon the C++ code for the core items. The game was pretty good, so your basic idea is not flawed. I think Gamasutra had an article on it.

Share this post


Link to post
Share on other sites
Arwin    122

Thanks, Taulin, for the reference. The two links below talk about that game...

http://www.gamasutra.com/features/20000802/huebner_02.htm
http://www.gamasutra.com/features/19990611/java_06.htm

But i''m still lost in thoughts...

Share this post


Link to post
Share on other sites
Promit    13246
Be warned that most scripting languages, notably Lua, don''t integrate especially well with any serious OO programming designs...

Share this post


Link to post
Share on other sites
Evangelion    122
I''d check out Python before I decided on a perticular scripting language. Its very OOP orentied, and can output in byte-code. I''ll admit I haven''t used it very much, but most of my scripting needs could be meet with Lua. I''d write out what the scripting engine will have to do, and how you think you will implement it before I picked a scripting languge.

Share this post


Link to post
Share on other sites
olle55    122
Hmm, im not very familiar with scripting for games, but im having a big difficulty to imagine that writing everything except the engien in a scripting language would have any advantage over coding it, except that maybe you can have artists and other nonprogrammers write the game. But for real.. there must be some other advantage?

As i see it you have two parts of a game:
Engine -> Game Logic

What point would there be to write the logic it in a scripting language?
Im not flaming im just intressted.

Share this post


Link to post
Share on other sites
OrangyTang    1298
quote:
Original post by Taulin
There was a game called Vampire:masqaurade that came out in 99 I believe that had a similar architecture.

Thay made dlls with all their core code. Then used JNI and javascript to actually make the game. Therefor, all their menus and game logic was done in javascript and called upon the C++ code for the core items. The game was pretty good, so your basic idea is not flawed. I think Gamasutra had an article on it.


The scripting was done in Java, Java != javascript.

[S-Type] [V-Script]

Share this post


Link to post
Share on other sites
joelmartinez    338
quote:
Original post by olle55
What point would there be to write the logic it in a scripting language?
Im not flaming im just intressted.

At it''s most basic level, this promotes abstraction and reusability in your game engine. If done correctly, you could in theory take the engine and make an entirely different game by simply supplying different scripts and art. This is the whole concept behind mod communities for games such as Quake, Unreal, and BF 1942.

Joel Martinez
http://www.codecube.net/

Share this post


Link to post
Share on other sites
Max_Payne    757
There is not much point in doing that. Apart from the cool factor, it just complicates everything. If you code the engine in C++, you can simply share the code base (fully or partially) with a game DLL, just like Quake and Half-Life.

Putting the game code in a DLL gives you much more speed than what you would get with a script. It also avoids the burden of actually interfacing a scripting language. Finally, you might think that programming with a scripting language is easier, but its not. Its still another language to learn, which will not encourage programmers to code for your game.

I''m sure many of you will not agree, but face the facts. The only people who would be attracted by a "simple" scripting language is those who are not already experienced with programming. Imo, this might be one of the reasons why many of the UT "mutators" were actually very bad, while some Half-Life mods have a very good quality.

And there is yet another disadvantage. Scripting languages involve that all modifications have to be open source. This means more power to the cheaters, the copycats and the general annoying people. Unless you always require them to be compiled to bytecode outside of the engine, but then whats the whole point (if any)?

So, to sum it all, scripting languages involve:
- Loss of speed
- More limitations, less flexibility
- Interfacing a language with the engine/more debugging
- Another language to learn
- All mods have to be open source

And don''t even tell me about compilation time of C/C++... It takes about 30 seconds to compile the Half-Life game DLL, and it only has to be done once, while with scripting, everytime you load a new script package, it has to be compiled, and it will most likely be slower than compiling C code.



Looking for a serious game project?
www.xgameproject.com

Share this post


Link to post
Share on other sites
Taulin    100
quote:
Original post by OrangyTang
quote:
Original post by Taulin
There was a game called Vampire:masqaurade that came out in 99 I believe that had a similar architecture.

Thay made dlls with all their core code. Then used JNI and javascript to actually make the game. Therefor, all their menus and game logic was done in javascript and called upon the C++ code for the core items. The game was pretty good, so your basic idea is not flawed. I think Gamasutra had an article on it.


The scripting was done in Java, Java != javascript.

[S-Type] [V-Script]



Sorry, it has been over three years since I read that article and looked at their SDK, so I forgot they had used Java.


[edited by - taulin on January 29, 2004 4:12:24 PM]

Share this post


Link to post
Share on other sites
Evangelion    122
I disagree with max_payne that scripting languages are not a good idea for small dev teams.

Advantages:
* Easy to learn - Artist and level designers will be able to levels themselves.

* Quick Prototyping - Scripting Languages usually allow the team to prototype an idea more quickly as they do not have to plow thru 10,000s lines of of code to add a new weapon, or monster. They just write another script to handle it.

* You can release the scripting language without releasing the source code - This might not be a big help to small teams, but its worth considering.

* The experience - Any good programmer wants to learn new things all the time, and learning to implement a script (or make one) is an exciting experience.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
quote:
Original post by olle55
What point would there be to write the logic it in a scripting language?



The main advantage I see is fast develpment time.

You don''t have to recompile everything when your writing a game in scripts and like some people mentioned its very easy to prototype things in a script rather than recompile a DLL just to test minor changes.

And alot of games that I know of have been made with scripts, with their main engine code being elsewhere in DLLs, things such as Severance (aka Blade, Edge of Darkness) and Vampire, and from what I understand, Asheron''s Call 2 is mainly scripts, but I could be wrong on that last one.

And finally, when developing a engine to use scripts its best to put things that are called every frame into the DLL. Scripting can slow things down, but if your using the scripting for game logic and the engine for rendering/updating etc then you shouldn''t have a problem.

Conan Bourke.

Share this post


Link to post
Share on other sites
DigitalChaos    215
Wouldn''t Elder Scrolls 3: Morrowind be a perfect example of a game made with a scripting language? I love that game so much and love modding it and creating new things.

Share this post


Link to post
Share on other sites
IFooBar    906
quote:
Original post by Max_Payne
So, to sum it all, scripting languages involve:
- Loss of speed
- More limitations, less flexibility
- Interfacing a language with the engine/more debugging
- Another language to learn
- All mods have to be open source


Could you please explain from all the experience you''ve had how scripting makes things less flexible?


Other stuff:

Scripting languages *are* easier to learn. For example "ch" which is a subset of C++ and a superset of C is very easy to learn. Acutally, you''ve practically already learnt it if you know C/C++. All that''s left is learning how to call real functions from within the script (which is also extremely easy).

Scripting languages reduce development times once you''ve got them up and running simply because your prototyping speed is increased Ten (probably more) fold.

Also the loss of speed would only be a concern in some places. Some games wouldnt care about the loss of speed depending on the language, the memory footprint, and other factors. For example a turn based story driven RPG...Well it would simply be crazy not to use scripting for that...

It''s probably because either you havent given scripting a chance, or you havent been able to integrate it properly that you think it''s not all its cracked up to be. Cause it is.


| C++ Debug Kit :: GameDev Kit :: DirectX Tutorials :: 2D DX Engine | TripleBuffer Software |
| Plug-in Manager :: System Information Class :: D3D9 Hardware Enum | DevMaster :: FlipCode |

Share this post


Link to post
Share on other sites
Well, I implemented my own scripting language for my 3D engine (Yeh yeh, could have used many good others like lua, ruby, AngelScript etc..,but I wanted to waste 2 years in doing it for teh sake of learning all about compilers and virtual machines :D )

I also did what gwihlidal initially said: having time consuming code + as many as possible other general functions done in C++ that the scripting language calls + its pluggable.

What have I learned from this ?

o It becomes so quick and easy to create new things + modify existing things.
o Performance hit is minimal, provided the ''heavy'' stuff is done in native code and called in script.
o When releasing your game with its SDK/Mod kit included, no external (and possibly expensive) tools are required to MOD the game. Therefore more people will be able to do it
o Simplification! Whoever is modding your game don''t have to know the inner workings of your engine to make simple/medium changes
o But, it takes a lot of hard work, I mean a LOT, creating your own scripting language to fit your needs -- If you choose to use a scripting language, use one that integrates/extends easily

In short, for me, scripting is the way with the benefits outweighing the drawbacks.


just my 2c....

Share this post


Link to post
Share on other sites
Max_Payne    757
quote:
Original post by Evangelion
I disagree with max_payne that scripting languages are not a good idea for small dev teams.


I said that?

quote:

Advantages:
* Easy to learn - Artist and level designers will be able to levels themselves.


Eh? Level designers don''t have to deal with the game code. And you shouldnt need actual scripting code in the levels. Half-Life had entity based scripting and it can do just as much, if not more than UT, when it comes to scripted events in maps. Its just something else level designers have to learn... And many level designers chose level design because they don''t like scripting/programming...

quote:

* Quick Prototyping - Scripting Languages usually allow the team to prototype an idea more quickly as they do not have to plow thru 10,000s lines of of code to add a new weapon, or monster. They just write another script to handle it.


What? Faster prototyping? That is once you have integrated and debugged your scripting system and added a certain bank of engine functions available to the scripting system, which will take eternity to do properly.

You can provide useful functions from the engine to your game DLL as well... And its actually easier than it would be with a scripting system. Also, I never add to codd 10000 lines of code for a weapon or monster... Just need to write a small inherited class to handle it...

quote:
* You can release the scripting language without releasing the source code - This might not be a big help to small teams, but its worth considering.


The same can be done with game libraries... Half-Life released a game SDK, just like Quake 2 did, without releasing the actual engine source...

quote:
* The experience - Any good programmer wants to learn new things all the time, and learning to implement a script (or make one) is an exciting experience.


Thats about the only valid point I can find. Its a challenge to implement. Personally I have enough challenges here as it is. Come back to me when you have a complete engine with this feature fully implemented and tell me how "exciting" it was to do... See ya in 10 years.

quote:
Could you please explain from all the experience you''ve had how scripting makes things less flexible?


Certainly I can. Your scripting system is never going to be able to do all that a game library can do. A game library can actually interface things outside of the engine. The scripting system, unless it is JIT compiled, will not be able to create substitutes for any engine routines. It will rely entirely on what the engine has, effectively limiting it. Your scripting language will never be as complete as a language like C++ is, which will make it less flexible... Simple.

quote:
Scripting languages reduce development times once you''ve got them up and running simply because your prototyping speed is increased Ten (probably more) fold.


Do you have actual *proofs* of that? I mean actual *proofs*.

quote:
Also the loss of speed would only be a concern in some places. Some games wouldnt care about the loss of speed depending on the language, the memory footprint, and other factors. For example a turn based story driven RPG...Well it would simply be crazy not to use scripting for that...


Certainly, some games don''t take that much performance, but some seriously do... A turn based RPG is fairly simple, it would be a pure waste of time to try implementing a scripting engine for that.

quote:
It''s probably because either you havent given scripting a chance, or you havent been able to integrate it properly that you think it''s not all its cracked up to be. Cause it is.


Nope, I haven''t ever implemented it, cause its a waste of time? Have you? Can you show us?

Anyhow... I don''t see the point of complicating everything, reducing performance and flexibility and trying to turn level designers into programmers. You people should really face the facts... Yes, I know, you can''t... Ah, kids.






Looking for a serious game project?
www.xgameproject.com

Share this post


Link to post
Share on other sites
Mezz    571
Max_Payne, for all your arguments (and I agree) it has to be pointed out that the original Quake used it''s own scripting language, and was very successful in terms of reuse and modding

Still, my favourite architecture (from the perspective of this argument, ignore the fact that it''s not OO or whatever) so far is Quake3''s, they have simple stuff for level designers (material scripts) and the cross-platform game code is written in C, run with a VM at runtime.
This saves learning a new scripting language and everything is still very flexible.

-Mezz

Share this post


Link to post
Share on other sites
IFooBar    906
quote:
Eh? Level designers don''t have to deal with the game code


They dont *have* to, but it will be extremely convinient if there was someway for them to interface with the engine to see what they made in action in different scenarios. Take for example a particle system, you''d probably tell an artist to make a nice looking particle effect and all since they are have the creative mind and all, so you have 3 options.

1: Let them code up their own particle system effects in a dll and compile and do all that stuff that they hate.

2: Give them a ready to use editor from which they can just tweak values and scroll bars to get the effect they want

3: make particle systems scriptable and let them set particle properties in a script and have the program just interpret the script.

Option number 2 would be the way to go, and would make the most sence to an artist. However, option 2 is actually a superset of option 3. Once the artist tweaks values in an editor, he will save the particle effect for later use by the game engine. Where does it get saved? In a script file of a sorts. More like a property file but still, you get the picture.

quote:
What? Faster prototyping? That is once you have integrated and debugged your scripting system and added a certain bank of engine functions available to the scripting system, which will take eternity to do properly.


Yes, faster prototyping. And it donst take an eternity to integrate a scripting system, that is utter nonsence. If it took an then 1000''s of games would have never been released. Oh Im sorry, did Jak & Daxter never make it to the market and sell millions of copies?

quote:
See ya in 10 years.

see above.

quote:
It will rely entirely on what the engine has, effectively limiting it. Your scripting language will never be as complete as a language like C++ is, which will make it less flexible... Simple.


It will rely on what the engine can do. If your engine can do it, then your script can do it. If your engine cant do it, then your script cant either. If there is something you want the script to do, it has to be supported in the engine its using. A scripting language dosnt not have to be as complete as a language as C++ is. I can say for sure that there are scripting languages as complete as C. And with C at your disposal you have a lot of flexibility.

quote:
Do you have actual *proofs* of that? I mean actual *proofs*.


Oh you dont have to take my word for it, but...

Ritual Entertainment''s Heavy Metal: F.A.K.K. 2

"in a nutshell the scripting language gives the level designer complete control over any object or entity in the game. The functionality it provides ranges from the simple linear movement of objects around the level to the complex scripted sequences that exist throughout F.A.K.K. 2"

Postmortem: Ritual Entertainment''s SIN

"Finally, our scripting system let us add some internally developed features fairly late in the development cycle. A level designer might, for instance, need a special command to perform a particular type of interactive element in his level. Because it was so easy to add commands to the scripting language, the programmer would usually oblige. We added two to three commands to the scripting language daily. In the end, we had over 400 script commands total. So, while we did experience some feature creep, and though these last minute details did push our release date back even farther, we were able to add a lot of detail near the end of SIN’s development cycle."

Treyarch''s Draconus

" The scripting language for Draconus was much more powerful than one used in Die By the Sword. Charles Tolman had a B. S. in computer science from UC Santa Barbara, where he took a two-semester class on compiler design. In under a month he had written a full-on, object oriented, C++ style interpreted scripting language."
"The scripting language turned out to be doubly useful when the artist who was designing the magical effects found out about it."


you can goto gamasutra.com and then in the search area search for "scripting", you''ll get around a 100 results and go browse through them. If all the above hasnt convinced you then there is no point in arguing because it''s clear that you are just being stubborn for the sake of argument.

For your convenience, I''ve extraced a few portions and underlined a few important bits. There''s one bit that I''ve underlined, italicized and bolded just to show that it dosnt take years to create a scripting language (and a fully functional C++ style one at that).

quote:
A turn based RPG is fairly simple, it would be a pure waste of time to try implementing a scripting engine for that.


Again, nonsence. A turn base RPG is not simple at all. And with hours and hours (AND HOURS) of cut scenes, it would be stupid not to use scripts to control the scenes.

quote:
Nope, I haven''t ever implemented it, cause its a waste of time? Have you? Can you show us?


Figured.

Yes I have. no I cannot show you.

quote:
Anyhow... I don''t see the point of complicating everything, reducing performance and flexibility and trying to turn level designers into programmers. You people should really face the facts... Yes, I know, you can''t... Ah, kids.


Yes of course all kids. Many many pro developers in places like Microsoft, Bungie, BHG, THQ, EA, SquareEnix, Monolith, all the dev houses mentioned above...(the list goes on) - All kids...

Plague on them for using scripting...


| C++ Debug Kit :: GameDev Kit :: DirectX Tutorials :: 2D DX Engine | TripleBuffer Software |
| Plug-in Manager :: System Information Class :: D3D9 Hardware Enum | DevMaster :: FlipCode |

Share this post


Link to post
Share on other sites
gwihlidal    1004
"no one" and "downgraded", thanks a lot for the kind words, it's nice to hear comments like that, keeps me motivated

In a month or so I might be releasing a whole bunch of more screens, including the new CSG\BSP\PVS world editor.

Scripting engines are all about design, they suck if the design sucks. If the design is well thought out and designed, then your scripting engine works quite well and efficiently.

~Graham



----
while (your_engine >= my_engine)
my_engine++;

[edited by - gwihlidal on January 30, 2004 11:33:51 AM]

Share this post


Link to post
Share on other sites