A day in the C++ life of T2D
by Smaug · in Torque Game Builder · 04/02/2005 (9:09 pm) · 60 replies
So, you're not content with a TScript-driven Torque2D. You want to have code run the show. You want to have TScript as helpers, not masters.
But, of course, the design is working against you. There's no interface for it. If you want to do this, you're going to have to hack the code in order to make it possible.
So, where does this go? That's what we're going to explore; the C++ internals of T2D's initialization and game loop. Note that I have not yet attempted to create a functioning T2D using an alternate initialization sequece or from adding additional elements to the game loop. This discussion is for how the standard T2D loop works with discussion as to which steps load/run scripts and where the user might best insert code.
Obviously, it all starts in main() (found in, if you're using Windows, platformWin32/winWindow.cc). However, this function does rather important initialization (and deinitialization) stuff that you'd probably do well to not touch. The next step is an abstract class (yay!) called "GameInterface".
It is an abstract class, but it is also a class that has functionality. It provides "Journal" functionality; you can read more about this in the comments to "gameinterface.h". It is not important for our needs.
What is important are the virtual functions of GameInterface. Specifically:
The real C/C++ main() function does initialization and then calls the global GameInterface object's (called "Game") main() function. No scripts have been loaded; only the most basic setup has been done. There isn't even a game window yet. It is GameInterface::main() that is expected to handle all the significant initialization, like creating a game window and so forth.
The standard T2D build comes with a derived and fully implemented child class of GameInterface called DemoGame. We will be using this implementation as a basis for user-defined implementations.
DemoGame is declared in game/demogame.h, but the definitions are all in game/main.cc.
The very first thing that DemoGame::main() does is call initLibraries(), a static function that does what it says. If it returns 0, then it failed.
After this, the next big step is running the global function initGame(). It takes the same arguments as main(), and it's job, among a few other things, is to run the user-specified startup script. This is clearly a step that should be avoided/ignored if the user is wanting to build the game from code rather than script. However, initGame() does some other things as well, like calling Sim::init(). I haven't investigated this step, but from a cursory glance, I wouldn't suggest not calling this function. It also creates an action map named "GlobalActionMap". It is up to you whether or not you care about this.
Now, we enter the main game loop. As such, if you want to do some code initialization before this (perhaps something like what your TScript would do in the setupT2DScene() function), feel free. Though the initGame stuff should probably happen first, so that the simulation is ready. In later looks at initializing T2D manually, I'll be walking through TScripts to emulate what they do in C++.
Here's the main game loop code in question:
<Why do we have this silly character limit? Posts with sentences are good.>
But, of course, the design is working against you. There's no interface for it. If you want to do this, you're going to have to hack the code in order to make it possible.
So, where does this go? That's what we're going to explore; the C++ internals of T2D's initialization and game loop. Note that I have not yet attempted to create a functioning T2D using an alternate initialization sequece or from adding additional elements to the game loop. This discussion is for how the standard T2D loop works with discussion as to which steps load/run scripts and where the user might best insert code.
Obviously, it all starts in main() (found in, if you're using Windows, platformWin32/winWindow.cc). However, this function does rather important initialization (and deinitialization) stuff that you'd probably do well to not touch. The next step is an abstract class (yay!) called "GameInterface".
It is an abstract class, but it is also a class that has functionality. It provides "Journal" functionality; you can read more about this in the comments to "gameinterface.h". It is not important for our needs.
What is important are the virtual functions of GameInterface. Specifically:
virtual int main(int argc, const char **argv); virtual void postEvent(Event &event); virtual void processEvent(Event *event); virtual void processMouseMoveEvent(MouseMoveEvent *event); virtual void processInputEvent(InputEvent *event); virtual void processTimeEvent(TimeEvent *event);
The real C/C++ main() function does initialization and then calls the global GameInterface object's (called "Game") main() function. No scripts have been loaded; only the most basic setup has been done. There isn't even a game window yet. It is GameInterface::main() that is expected to handle all the significant initialization, like creating a game window and so forth.
The standard T2D build comes with a derived and fully implemented child class of GameInterface called DemoGame. We will be using this implementation as a basis for user-defined implementations.
DemoGame is declared in game/demogame.h, but the definitions are all in game/main.cc.
The very first thing that DemoGame::main() does is call initLibraries(), a static function that does what it says. If it returns 0, then it failed.
After this, the next big step is running the global function initGame(). It takes the same arguments as main(), and it's job, among a few other things, is to run the user-specified startup script. This is clearly a step that should be avoided/ignored if the user is wanting to build the game from code rather than script. However, initGame() does some other things as well, like calling Sim::init(). I haven't investigated this step, but from a cursory glance, I wouldn't suggest not calling this function. It also creates an action map named "GlobalActionMap". It is up to you whether or not you care about this.
Now, we enter the main game loop. As such, if you want to do some code initialization before this (perhaps something like what your TScript would do in the setupT2DScene() function), feel free. Though the initGame stuff should probably happen first, so that the simulation is ready. In later looks at initializing T2D manually, I'll be walking through TScripts to emulate what they do in C++.
Here's the main game loop code in question:
while(Game->isRunning())
{
PROFILE_START(MainLoop);
Game->journalProcess();
Net::process(); // read in all events
Platform::process(); // keys, etc.
TelConsole->process();
TelDebugger->process();
TimeManager::process(); // guaranteed to produce an event
PROFILE_END();
}<Why do we have this silly character limit? Posts with sentences are good.>
#42
I was referring more to the "beginners" - I guess I just find it a little discouraging as a "beginner" to know that I'd be "blooming stupid" to try and complete my game in script.
Other beginners will probably feel the same, and attempt to move into the C++ side of things, posting a lot of questions about a lot of things where in turn people will respond with questions like "Couldn't you just do that in script?" It's a waste of everyone's time.
04/09/2005 (9:35 am)
@Mr Clam - Sorry :) I quoted you, but I wasn't referring to you specifically I'm sure you know what you're doing. I was referring more to the "beginners" - I guess I just find it a little discouraging as a "beginner" to know that I'd be "blooming stupid" to try and complete my game in script.
Other beginners will probably feel the same, and attempt to move into the C++ side of things, posting a lot of questions about a lot of things where in turn people will respond with questions like "Couldn't you just do that in script?" It's a waste of everyone's time.
#43
note they did the rpg system in "phython"
while you say
would you now consider your outlook on scripting languages just might be underestimated?
04/09/2005 (10:12 am)
Quote from Josh Ritter... his team has an MMORPG (both Massive Single and Multiplayer) in Torque in its Alpha stageQuote:
Briefly, on the whole engine fiasco MoM has endured...
I worked my buttocks off making Quake2 do what that version of MoM did... b-u-t-t-o-c-k-s... it still had a debugging cycle... then, Quake3 was announced to be GPL... Quake3 was an obvious choice....
Quake3 was working very well and looked great... then, the GPL license was delayed with no timeframe for it's release... MoM would be in limbo until this...
We started using Torque on January 17th, or so... it's been a very busy 2 months and Torque has performed like a champ... the rpg system is quite modular, and written in Python which made moving engines feasible...
note they did the rpg system in "phython"
while you say
Quote:
Both have their place, but I personally don't see the purpose for the Perl/Python method in game development
would you now consider your outlook on scripting languages just might be underestimated?
#44
Yet I still don't understand why either of us are reading this :)
04/09/2005 (10:28 am)
Odd, Matthew. We seem to be reading the same posts at the same time.Yet I still don't understand why either of us are reading this :)
#45
To go back to the games that have been referenced above like Tribes; it was composed of a huge volume of script-code but it also contains lots of custom C++ work. This is the same for lots of major titles and the advantages of scripts stand for themselves but are not necessarily in all cases. In-fact, I'd be a liar if I said I knew what the statistics were for the use of scripts in "major" titles. It'd be interesting to find a well informed source for that info.
It is unlikely in the extreme that even at the release v1 that T2D will allow you to do everything in script. There are only so many methods to provide abstracted objects that provide enough features but are not unecessarily bloated, complex and/or slow. If we go too far, games will be using monster T2D objects for simple tasks, cracking the proverbial nut with a sledgehammer. Can anyone say "GameBase"? (TGE joke)
A typical T2D development is to code-up a C++ object (maybe AI, maybe some fancy rendering object) and then add in the support calls for script (assuming it needs external logic control). Some objects will interact with other objects and not have script exposure but lots will.
Describing a game that needs 'heavy' C++ work is hard without making it sound wrong. Doing a "big", "professional", "production-quality" will more than likely require C++ work. Not everything can be abstracted behind a script-interface and be useful in lots of genres. Eventually you've got to get specific. This is not always the case for every game but I don't want to think of how to classify this type of game without it sounding insulting. "small", "quick", "simple" make them sound inferior and are quite frankly insulting but these games can be done with little to no C++ custom work.
For non C++ programmers, the situation may sound dire but T2D has just started and as TGE has proven, there will be lots of custom C++ objects / packs available that will give you a helping hand. Ultimately, forming small teams will also help so that you've got the relevant experience on your team to do some of these sometimes minor extensions. There is also the reality that lots of people using T2D may not be using it to produce "production-quality" games or maybe not even games at all.
Understanding the boundary for Script / C++ for your particular project is an important step.
Again, I'm preaching to the choir a little but I'd like to think that the energy here has been focused on the disagreement of ALL in C++ and it's not just a misunderstanding.
- Melv.
04/09/2005 (10:30 am)
@MrClam: Just to be sure that everyone's on track here. I'd like to think that the opponents to Smaug doing C++ stuff are opposing doing everything in C++ and not leveraging script to gain the advantages it provides. If that's not the case then I completely disagree with that.To go back to the games that have been referenced above like Tribes; it was composed of a huge volume of script-code but it also contains lots of custom C++ work. This is the same for lots of major titles and the advantages of scripts stand for themselves but are not necessarily in all cases. In-fact, I'd be a liar if I said I knew what the statistics were for the use of scripts in "major" titles. It'd be interesting to find a well informed source for that info.
It is unlikely in the extreme that even at the release v1 that T2D will allow you to do everything in script. There are only so many methods to provide abstracted objects that provide enough features but are not unecessarily bloated, complex and/or slow. If we go too far, games will be using monster T2D objects for simple tasks, cracking the proverbial nut with a sledgehammer. Can anyone say "GameBase"? (TGE joke)
A typical T2D development is to code-up a C++ object (maybe AI, maybe some fancy rendering object) and then add in the support calls for script (assuming it needs external logic control). Some objects will interact with other objects and not have script exposure but lots will.
Describing a game that needs 'heavy' C++ work is hard without making it sound wrong. Doing a "big", "professional", "production-quality"
For non C++ programmers, the situation may sound dire but T2D has just started and as TGE has proven, there will be lots of custom C++ objects / packs available that will give you a helping hand. Ultimately, forming small teams will also help so that you've got the relevant experience on your team to do some of these sometimes minor extensions. There is also the reality that lots of people using T2D may not be using it to produce "production-quality" games or maybe not even games at all.
Understanding the boundary for Script / C++ for your particular project is an important step.
Again, I'm preaching to the choir a little but I'd like to think that the energy here has been focused on the disagreement of ALL in C++ and it's not just a misunderstanding.
- Melv.
#46
04/09/2005 (11:03 am)
Exactly. Its the people that seem to want to do one or the other to exclusion that bother me. Some stuff works best in one aspect, some in the other. But making EVERYTHING in C++ is just overkill. Theres a reason that nearly every single major game on the market has a script engine, even if you never see it. Do you have any idea how much of a huge boon it is in a large scale development to be able to have level designers, artists, etc do thier thing through script without having to bother programmers for 90% of what they do? Prciceless.
#47
Hence my statement about (paraphrase) "experienced TAP developers knowing intuitively when to development functionality in the most appropriate manner".
04/09/2005 (11:38 am)
Quote:Understanding the boundary for Script / C++ for your particular project is an important step.
Hence my statement about (paraphrase) "experienced TAP developers knowing intuitively when to development functionality in the most appropriate manner".
#48
I've shipped 3 titles (at work) in the past, and am working on my 4th, so I can chime in with something. Granted, this is just our method of doing it. The first 2 used no script at all. However, these were "simpler" games, and plus the game engine that was handed to us had no scripting functionality. We certainly had no time to add a scripting language along with the support that needs.
The third (and fourth) one use script significantly. However, it functions in a high-level capacity. Regular AI is written in code, but it can be "poked at" through script; the behavior of a guy can be changed from its current behavior into one of the other possible behaviors. Script runs game missions, spawns finished entities and responds to various events about those entities. Scripters have neither the time nor the inclination to get into any significant AI work; they want to be able to set up finished characters with specific behaviors and let them run around and do stuff.
Obviously, that's just our experience. But we tried to allow the scripters to get their hands into some actual AI work, and they patently refused our offer.
Which is one reason why I asked for a C++ forum. So that discussion of C++-related things can happen outside of the eyes of those who do not wish/need to see it.
True. But this thread is (or was, at least) about starting the game off through C++ code initialization rather than script initialization, as well as having C++ code break into the render loop. Something I'm going to get started actually implementing later today.
04/09/2005 (12:16 pm)
Quote:In-fact, I'd be a liar if I said I knew what the statistics were for the use of scripts in "major" titles.
I've shipped 3 titles (at work) in the past, and am working on my 4th, so I can chime in with something. Granted, this is just our method of doing it. The first 2 used no script at all. However, these were "simpler" games, and plus the game engine that was handed to us had no scripting functionality. We certainly had no time to add a scripting language along with the support that needs.
The third (and fourth) one use script significantly. However, it functions in a high-level capacity. Regular AI is written in code, but it can be "poked at" through script; the behavior of a guy can be changed from its current behavior into one of the other possible behaviors. Script runs game missions, spawns finished entities and responds to various events about those entities. Scripters have neither the time nor the inclination to get into any significant AI work; they want to be able to set up finished characters with specific behaviors and let them run around and do stuff.
Obviously, that's just our experience. But we tried to allow the scripters to get their hands into some actual AI work, and they patently refused our offer.
Quote:Other beginners will probably feel the same, and attempt to move into the C++ side of things, posting a lot of questions about a lot of things where in turn people will respond with questions like "Couldn't you just do that in script?" It's a waste of everyone's time.
Which is one reason why I asked for a C++ forum. So that discussion of C++-related things can happen outside of the eyes of those who do not wish/need to see it.
Quote:But making EVERYTHING in C++ is just overkill.
True. But this thread is (or was, at least) about starting the game off through C++ code initialization rather than script initialization, as well as having C++ code break into the render loop. Something I'm going to get started actually implementing later today.
#49
- Melv.
04/09/2005 (12:17 pm)
Sorry, Stephen. It was a bit of an overstatement. You are quite correct of course.- Melv.
#50
From my viewport here it seems like there's been some basic misunderstanding of what it is you're trying to achieve and that seems to be causing friction. Your description of how your company works seems to be what people are proposing? Motherload of brutal work on C++ and game-logic in script (poking), although you don't mention game-logic so I'm assuming that.
Well I'm not here to disgree with you and I'm trying to avoid speaking for everyone. Quite the opposite, I'm interested in seeing your results (if you don't mind) and I'm sure it'll uncover some interesting stuff, maybe some feedback on how we can improve the engine in general, both T2D and TGE. Who knows?
I would like to understand your intent here (because I'm nosey). There are systems in-place to create objects so that you can run AI microcode, do rendering, whatever, totally autonomously (without script) and I was wondering what stuff over and above this you're doing, especially as T2D didn't modify the underlying TGE platform to get where it is.
I think you're just discussing how to leverage the existing capabilities as you defined in the virtual functions above? I'd like to ensure that whatever work you do will be compatible with networking.
If I can help you in anyway then by all means start another thread up or take it to private email.
Of course, I'm also happy to just leave you alone to get on with it. ;)
- Melv.
04/09/2005 (12:29 pm)
Just saw your post Smaug.From my viewport here it seems like there's been some basic misunderstanding of what it is you're trying to achieve and that seems to be causing friction. Your description of how your company works seems to be what people are proposing? Motherload of brutal work on C++ and game-logic in script (poking), although you don't mention game-logic so I'm assuming that.
Well I'm not here to disgree with you and I'm trying to avoid speaking for everyone. Quite the opposite, I'm interested in seeing your results (if you don't mind) and I'm sure it'll uncover some interesting stuff, maybe some feedback on how we can improve the engine in general, both T2D and TGE. Who knows?
I would like to understand your intent here (because I'm nosey). There are systems in-place to create objects so that you can run AI microcode, do rendering, whatever, totally autonomously (without script) and I was wondering what stuff over and above this you're doing, especially as T2D didn't modify the underlying TGE platform to get where it is.
I think you're just discussing how to leverage the existing capabilities as you defined in the virtual functions above? I'd like to ensure that whatever work you do will be compatible with networking.
If I can help you in anyway then by all means start another thread up or take it to private email.
Of course, I'm also happy to just leave you alone to get on with it. ;)
- Melv.
#51
Personally, I love it - as I hate C++.
04/09/2005 (12:56 pm)
I think what it comes down to is a lot of people coming to T2D are from other engines, that are not "mod-friendly" so to speak. As for myself, I am from the TRIBES community (anyone remember Mr_Help4, or IntauaraMods?), as well as various other FPS games. They are all mod-centric and primarily written in script. Since T2D is built off of this framework, it only makes sense to me it is as well.Personally, I love it - as I hate C++.
#52
That's why I stick to using script for as much stuff as possible. If I need to optimize, I drop out to C++ the same way a C++ coder drops out to ASM.
And I like scripting, even though I was initially totally against using it :) My experiences with Torque made me realize that making a script-driven game is the best approach for me and my project.
04/09/2005 (1:38 pm)
One reason I think people like to totally stick with one or the other is because of a rather big time-overhead it takes to connect code from the engine to script (writing all those consolemethoc functions and all the ugly strting manipulation that entails...)That's why I stick to using script for as much stuff as possible. If I need to optimize, I drop out to C++ the same way a C++ coder drops out to ASM.
And I like scripting, even though I was initially totally against using it :) My experiences with Torque made me realize that making a script-driven game is the best approach for me and my project.
#53
04/09/2005 (2:00 pm)
@Smaug: I am respectfully waiting for your reply on my post above... where I find your statement about Python completely invalid with proof... I do not mean this offensively, I am curious if you will re-evaluate your stance on scripting considering an MMRPG/MSRPG uses and rpg system using Python...
#54
In fact I think to ensure a system is as efficient as possibly it should be challenged... so I think its good your trying to evaluate another way of doing things... I'm simply trying to defend what I think doesn't need challenged... heck maybe you'll find a more efficient way to do things, if so great!
04/09/2005 (2:03 pm)
Btw Smaug please don't get my posts wrong, I really mean none of it offensively or insulting... In fact I think to ensure a system is as efficient as possibly it should be challenged... so I think its good your trying to evaluate another way of doing things... I'm simply trying to defend what I think doesn't need challenged... heck maybe you'll find a more efficient way to do things, if so great!
#55
You never explained what they did with Python. You didn't explain how they used the Python method (which is what I was talking about, not scripting languages in general) in their game. Nor did you explain how this would be useful in the vast majority of games.
Python has been embedded before (see Blender3D for an example of embedded Python). I understand that this technique is not without pain, but it is quite possible. However, it goes against the Python method, which was what I was arguing against.
Well, define "primarily written". The games are defined by script, but that's because, ultimately, one FPS really isn't that different from another. A multiplayer FPS is a very event-driven thing. It is probably the 3D genre of games that best fit the "simulation/event" model that Torque provides. Most single-player games don't fit that model nearly as well.
Yes, binding code to script is a real pain. That's the primary reason why I prefer Lua, personally. Someone went through the trouble to make LuaBind, which makes attaching code to script almost effortless. It makes script code seem like a .dll or just another object you instantiate. Indeed, LuaBind has been applauded in the community to the extent that other script libraries are considering taking the (open source) code and modifying it to work with their script interface. I think the Boost people even once considered using LuaBind as a foundation for making an entirely script-language-neutral way of binding script code to C++ code, allowing the various script writers to simply plug in backends to make their scripts work.
04/09/2005 (3:09 pm)
Quote:would you now consider your outlook on scripting languages just might be underestimated?
You never explained what they did with Python. You didn't explain how they used the Python method (which is what I was talking about, not scripting languages in general) in their game. Nor did you explain how this would be useful in the vast majority of games.
Python has been embedded before (see Blender3D for an example of embedded Python). I understand that this technique is not without pain, but it is quite possible. However, it goes against the Python method, which was what I was arguing against.
Quote:They are all mod-centric and primarily written in script.
Well, define "primarily written". The games are defined by script, but that's because, ultimately, one FPS really isn't that different from another. A multiplayer FPS is a very event-driven thing. It is probably the 3D genre of games that best fit the "simulation/event" model that Torque provides. Most single-player games don't fit that model nearly as well.
Quote:One reason I think people like to totally stick with one or the other is because of a rather big time-overhead it takes to connect code from the engine to script (writing all those consolemethoc functions and all the ugly strting manipulation that entails...)
Yes, binding code to script is a real pain. That's the primary reason why I prefer Lua, personally. Someone went through the trouble to make LuaBind, which makes attaching code to script almost effortless. It makes script code seem like a .dll or just another object you instantiate. Indeed, LuaBind has been applauded in the community to the extent that other script libraries are considering taking the (open source) code and modifying it to work with their script interface. I think the Boost people even once considered using LuaBind as a foundation for making an entirely script-language-neutral way of binding script code to C++ code, allowing the various script writers to simply plug in backends to make their scripts work.
#56
Now that I have that out of the way, I really believe that if you were designing an MMORPG that required massive scalability, and a complicated RPG system, programming it in C++ would be the only way. MoM is very nice granted, but at the same time what I am talking about is an AAA MMORPG, not an indie RPG. There are many reasons for this logic, but the most critical are speed (of course) and full type checking. When you have an extremely complicated system that is going to be under heavy load, you really need as much help as you can get with making sure you code is valid. You don't want a single line of incorrect code crashing a game server.
You could use something like Java or C# to code the game server, but honestly I see very little benefit. Some people will site things like automatic garbage collection, and so on, but honestly when you have a large enough of a system, things like that usually don't matter as much. In many large, complicated applications you end up having memory leaks and allocation issues even in garbage collected languages. This is a very common issue, especially with complicated simulations (ie, games).
With managed applications you will typically have even more memory issues with a large application, than in C++. The first thing you are probably thinking I will say is that managed languages like Java and C# user way too much right off the bat. In reality, garbage collected languages allocate a lot on load for a good reason. Memory allocation, especially in Windows, is very slow. So the runtime will allocate a big chunk of memory for the application when it launches. This allows the runtime to allocate memory in a little more sane of a way, than Windows. Most game engines do something like this too, when you launch them, so the game can perform its own memory management.
Now even though C# and Java allocate a bunch of memory when the application loads, memory allocation and deallocation is a very slow process. This is due to the fact that the runtime has to do a lot of work to make sure the memory is allocated / deallocated correctly and so forth. The most expensive process in C# and Java are allocation and deallocation of memory. On the other hand, you cannot just allocate a block of memory and use it however you wish in C# or Java. There are some tricks you can do to work around this issue, but things end up a lot more funky than they would be in C++.
Another issue is that sometimes it is really hard to know when you are creating new objects, because operations that you would not expect to create objects are creating objects. What ends up happening then, is you run into the infamous freeze issue, where the application freezes for a second, every maybe 10 seconds, when the GC kicks in. The great thing about these sorts of issues is that they are almost impossible to find, in a large system.
Okay so let us get back to the main topic. I would not even consider Java or C# for an MMORPG. For the server side of the game I would use C++ with a nice network library like TNL. For the client, I would use a game engine like Torque, with most of the game objects done in C++, and a lot of the communication to the server done in C++. On the other hand, for the actual game UI, and so on, the work could easily be done in script, and not matter.
Now to wrap things up, I don not think any of this matters to most people that will be visiting this site. For most games, you could get away with using TorqueScript for everything in TGB. Unless you are going to have some complicated distributed game system with 20k+ users hitting it at the same time, you are not going to have too much of a problem. Most games really aren't going to have more than maybe 100 users per server.
But on the other hand, I have to admit I like coding in C++ better than TorqueScript. I have done quite a bit of TorqueScript code too. The only reason why I ever use TorqueScript is because I can do something in a couple hours that would take days to do in C++. This is especially true in TGB.
05/14/2006 (6:22 pm)
I know I am opening this thread again for no reason, and honestly I have no idea how I even opened this thread. I can agree that scripting languages have benefits over C++, and vice versa. I also believe that C# really has no real advantage over C++ in larger programs. I don't really see C# as a scripting language at all, since to me, scripting languages are typically dynamic languages. Dynamic languages let you do things in ways that you could never do the same way in C++ or C#. Of course this leads to bad programming practices in some cases, but what you have to remember is that scripting languages are usually the last level of the development pipeline. Scripting languages are designed towards end users, that aren't necessarily programmers. You also have to consider in games, most of the script code will never, ever be reused. So if you do something hacky, its okay, as long as it works.Now that I have that out of the way, I really believe that if you were designing an MMORPG that required massive scalability, and a complicated RPG system, programming it in C++ would be the only way. MoM is very nice granted, but at the same time what I am talking about is an AAA MMORPG, not an indie RPG. There are many reasons for this logic, but the most critical are speed (of course) and full type checking. When you have an extremely complicated system that is going to be under heavy load, you really need as much help as you can get with making sure you code is valid. You don't want a single line of incorrect code crashing a game server.
You could use something like Java or C# to code the game server, but honestly I see very little benefit. Some people will site things like automatic garbage collection, and so on, but honestly when you have a large enough of a system, things like that usually don't matter as much. In many large, complicated applications you end up having memory leaks and allocation issues even in garbage collected languages. This is a very common issue, especially with complicated simulations (ie, games).
With managed applications you will typically have even more memory issues with a large application, than in C++. The first thing you are probably thinking I will say is that managed languages like Java and C# user way too much right off the bat. In reality, garbage collected languages allocate a lot on load for a good reason. Memory allocation, especially in Windows, is very slow. So the runtime will allocate a big chunk of memory for the application when it launches. This allows the runtime to allocate memory in a little more sane of a way, than Windows. Most game engines do something like this too, when you launch them, so the game can perform its own memory management.
Now even though C# and Java allocate a bunch of memory when the application loads, memory allocation and deallocation is a very slow process. This is due to the fact that the runtime has to do a lot of work to make sure the memory is allocated / deallocated correctly and so forth. The most expensive process in C# and Java are allocation and deallocation of memory. On the other hand, you cannot just allocate a block of memory and use it however you wish in C# or Java. There are some tricks you can do to work around this issue, but things end up a lot more funky than they would be in C++.
Another issue is that sometimes it is really hard to know when you are creating new objects, because operations that you would not expect to create objects are creating objects. What ends up happening then, is you run into the infamous freeze issue, where the application freezes for a second, every maybe 10 seconds, when the GC kicks in. The great thing about these sorts of issues is that they are almost impossible to find, in a large system.
Okay so let us get back to the main topic. I would not even consider Java or C# for an MMORPG. For the server side of the game I would use C++ with a nice network library like TNL. For the client, I would use a game engine like Torque, with most of the game objects done in C++, and a lot of the communication to the server done in C++. On the other hand, for the actual game UI, and so on, the work could easily be done in script, and not matter.
Now to wrap things up, I don not think any of this matters to most people that will be visiting this site. For most games, you could get away with using TorqueScript for everything in TGB. Unless you are going to have some complicated distributed game system with 20k+ users hitting it at the same time, you are not going to have too much of a problem. Most games really aren't going to have more than maybe 100 users per server.
But on the other hand, I have to admit I like coding in C++ better than TorqueScript. I have done quite a bit of TorqueScript code too. The only reason why I ever use TorqueScript is because I can do something in a couple hours that would take days to do in C++. This is especially true in TGB.
#57
I, as a (self proclaimed) C# guru have to tell you that you are missing the point of the language entirely.
Sure, on a purely technical level, there is no reason for anyone to code in C#. they should be coding in C++. Though by that logic, there is no reason anyone should code in C++ either, they should be coding in Assembly, or even better, in binary.
I know I'm being a bit extreme here, but i'm just trying to illustrate my point. C# (like Java) is all about being more productive. it lets unskilled developers tackle complex problems, and it lets skilled developers tackle otherwise imposible problems.
For any type of programming task, with the very possible exception of real-time applications (such as a game engine's core) having these tools at your disposal is a very very good thing.
Some of your issues/concerns with managed languages (.NET or Java) are true, but most of the problems you describe are due to your lack of experience with the environment. For example, there are all sorts of memory performance related tweaks that can be done by leveraging the System.GC and System.Runtime.InteropServices.Marshal classes.
05/15/2006 (5:53 pm)
@Ray: good post. I, as a (self proclaimed) C# guru have to tell you that you are missing the point of the language entirely.
Sure, on a purely technical level, there is no reason for anyone to code in C#. they should be coding in C++. Though by that logic, there is no reason anyone should code in C++ either, they should be coding in Assembly, or even better, in binary.
I know I'm being a bit extreme here, but i'm just trying to illustrate my point. C# (like Java) is all about being more productive. it lets unskilled developers tackle complex problems, and it lets skilled developers tackle otherwise imposible problems.
For any type of programming task, with the very possible exception of real-time applications (such as a game engine's core) having these tools at your disposal is a very very good thing.
Some of your issues/concerns with managed languages (.NET or Java) are true, but most of the problems you describe are due to your lack of experience with the environment. For example, there are all sorts of memory performance related tweaks that can be done by leveraging the System.GC and System.Runtime.InteropServices.Marshal classes.
#58
Has anyone seen of TorqueBASIC? Its an alternate scripting language, surely you could hook lua/python like they hooked that?
Also, what is the point in a fast game if its messy/hard to patch..? Personally, for the few ticks I loose, Id rather use TS for all of my code than none. =) Speeds up development.... = More money. =P
Jason has the right idea. It helps people to tackle the solutions quickly. Rather than be baffled for a few days and have nothing done. =)
-- Ricky
05/21/2006 (2:19 pm)
This is slightly relevant: (I skipped the last couple of posts so someone may have said this.)Has anyone seen of TorqueBASIC? Its an alternate scripting language, surely you could hook lua/python like they hooked that?
Also, what is the point in a fast game if its messy/hard to patch..? Personally, for the few ticks I loose, Id rather use TS for all of my code than none. =) Speeds up development.... = More money. =P
Jason has the right idea. It helps people to tackle the solutions quickly. Rather than be baffled for a few days and have nothing done. =)
-- Ricky
#59
05/21/2006 (2:42 pm)
Actually, all "TorqueBasic" is, is a new grammar for the same TorqueScript byte-code compiler, through the magic of lexx/yacc/whatever it is that handles the grammar down at that low level (it's been a LONG time since I've poked at grammar syntaxes)--it isn't actually a different scripting language, simply a different grammar for the existing one. 
#60
05/21/2006 (4:57 pm)
I tried TorqueBasic, but from the look of the sources its been removed over the last 2 releases. I made a resource for Lua and Torquescript to communicate with one another... maybe not as useful as the Python bindings but it may work for some projects.
Torque Owner Dave "Jellybit" Freeman