New SDK Game-Genre Frameworks...
by Melv May · in Torque Game Engine · 11/11/2003 (5:43 am) · 27 replies
Guys,
Now that we're going down the road to having multiple genre frameworks as part of the SDK and not just FPS, it would be nice to remove some of the genre nomenclature. So far the GG guys have done a terrific job of tidying the codebase but I believe there are a few more steps we can take. Maybe there's work in-place to look at this and I'm not sure if my ideas smack in the face of what's going on or not but I think it's an interesting discussion to start.
A major one that comes to mind and something that I quickly removed from Strategem and other projects that use the TGE is the use of the word 'mission'. The concept of a mission can be used within lots of genres but it doesn't quite 'fit' in lots of cases.
I changed all these occurrences to the word 'simulation' which is more abstract and accurate in terms of what the engine is doing. Loading the simulation is completely abstracted away from the specific game type. MissionGroup/Cleanup become SimulationGroup, MissionType becomes SimulationType etc.
The MissionInfo object is something that would either need to be removed, shunted to the FPS genre or abstracted away as a SimulationInfo object to pass simulation info for loading.
Other work includes moving the concept of the current SCORE away from COMMON and adding a little more consistency in locations to "put things" such as server/client side commands etc.
The work to convert the existing [HEAD] to use this took under two hours and I believe results in a more genre-agnostic SDK.
Of course, this is mostly a personal choice and far from important in the scheme of things and I don't want this to sound like I'm critising the existing SDK but I believe that the fewer FPS-style references the better and easier it is for newbies and veterans alike.
It would be good to bring the turn-based framework I developed for Strategem to the SDK and this could be done but things such as the concept of a mission didn't quite fit. I'm genuinely interested in helping out with adding some genre-frameworks next year, hence my post. :)
Any other ideas anyone?; dicuss?
- Melv.
Now that we're going down the road to having multiple genre frameworks as part of the SDK and not just FPS, it would be nice to remove some of the genre nomenclature. So far the GG guys have done a terrific job of tidying the codebase but I believe there are a few more steps we can take. Maybe there's work in-place to look at this and I'm not sure if my ideas smack in the face of what's going on or not but I think it's an interesting discussion to start.
A major one that comes to mind and something that I quickly removed from Strategem and other projects that use the TGE is the use of the word 'mission'. The concept of a mission can be used within lots of genres but it doesn't quite 'fit' in lots of cases.
I changed all these occurrences to the word 'simulation' which is more abstract and accurate in terms of what the engine is doing. Loading the simulation is completely abstracted away from the specific game type. MissionGroup/Cleanup become SimulationGroup, MissionType becomes SimulationType etc.
The MissionInfo object is something that would either need to be removed, shunted to the FPS genre or abstracted away as a SimulationInfo object to pass simulation info for loading.
Other work includes moving the concept of the current SCORE away from COMMON and adding a little more consistency in locations to "put things" such as server/client side commands etc.
The work to convert the existing [HEAD] to use this took under two hours and I believe results in a more genre-agnostic SDK.
Of course, this is mostly a personal choice and far from important in the scheme of things and I don't want this to sound like I'm critising the existing SDK but I believe that the fewer FPS-style references the better and easier it is for newbies and veterans alike.
It would be good to bring the turn-based framework I developed for Strategem to the SDK and this could be done but things such as the concept of a mission didn't quite fit. I'm genuinely interested in helping out with adding some genre-frameworks next year, hence my post. :)
Any other ideas anyone?; dicuss?
- Melv.
About the author
#22
I really like the idea of Stage. Without getting too dug-in with semantics; you can be on the stage but not necessarily visibly so. Things that can go on the stage are SceneObjects. During download, you get the stage objects e.g. datablocks & ghosts etc and finally the stage is lit rather than referring to the terrain.
To be honest, thinking about it, something like 'Scene' would probably fit with the existing code. The server does a 'LoadScene' and places them into the simulation and clients, upon connecting, get a ghost-scene.
This may not make a physical difference but I think it promotes different ways of thinking and can generate new ideas.
Hey ... it may not happen but we can talk about it can't we. ;)
- Melv.
11/13/2003 (4:33 am)
Devon,I really like the idea of Stage. Without getting too dug-in with semantics; you can be on the stage but not necessarily visibly so. Things that can go on the stage are SceneObjects. During download, you get the stage objects e.g. datablocks & ghosts etc and finally the stage is lit rather than referring to the terrain.
To be honest, thinking about it, something like 'Scene' would probably fit with the existing code. The server does a 'LoadScene' and places them into the simulation and clients, upon connecting, get a ghost-scene.
This may not make a physical difference but I think it promotes different ways of thinking and can generate new ideas.
Hey ... it may not happen but we can talk about it can't we. ;)
- Melv.
#23
For instance, I'm working on an RPG. It does not need the mission area concept. I design the level the way I want the player to see it and they can go anywhere within that level. The mission area, along with its timers, etc. just don't apply.
Bot code is another area that I'd love to get out of there. Vehicles may not be useful for other people, etc. There are any number of things that may or may not be useful to someone, but they are a pain to remove.
I would like to see a project where people modularized these elements and made a base Torque engine, with all these elements still in and functioning, but easily removable by the user if they choose not to have them in their game. I think there was such a project at one time, but I'm not sure what happened to it.
11/13/2003 (12:06 pm)
All of this is nice and all, and I think it would be a good addition to the engine, but I would like a way to get a stripped-down version of the engine first. From that a user could more easily build all of these frameworks you mention.For instance, I'm working on an RPG. It does not need the mission area concept. I design the level the way I want the player to see it and they can go anywhere within that level. The mission area, along with its timers, etc. just don't apply.
Bot code is another area that I'd love to get out of there. Vehicles may not be useful for other people, etc. There are any number of things that may or may not be useful to someone, but they are a pain to remove.
I would like to see a project where people modularized these elements and made a base Torque engine, with all these elements still in and functioning, but easily removable by the user if they choose not to have them in their game. I think there was such a project at one time, but I'm not sure what happened to it.
#24
By a stripped-down version, I presume you're talking about the scripts only. The problem is how far is stripped-down? It would take me literally two minutes to produce a script that created a canvas and was to show a gui-screen with a single button. The extra code that's in the base-scripts is for framework callbacks, gui-profiles, datablocks, maintaining a server, server-side mission-loading, client-side mission-loading, chat, the editors, the show tool and then onto mission specifics such as the player, vehicle etc.
So how far is stripped-down to be useful to everyone? Is something like I mention really useful? Maybe as a learning tool on what is absolutely necessary to do ABC? If so, then I could post it up and you could add the extra bits yourself as a learning exercise.
- Melv.
11/13/2003 (1:23 pm)
Rodney,By a stripped-down version, I presume you're talking about the scripts only. The problem is how far is stripped-down? It would take me literally two minutes to produce a script that created a canvas and was to show a gui-screen with a single button. The extra code that's in the base-scripts is for framework callbacks, gui-profiles, datablocks, maintaining a server, server-side mission-loading, client-side mission-loading, chat, the editors, the show tool and then onto mission specifics such as the player, vehicle etc.
So how far is stripped-down to be useful to everyone? Is something like I mention really useful? Maybe as a learning tool on what is absolutely necessary to do ABC? If so, then I could post it up and you could add the extra bits yourself as a learning exercise.
- Melv.
#25
Rodney if you saw what I am currently working as a replacement for the current Torque editor you'd be busting a gut.
and the idea is ALOT more advanced than frameworks.
Its actually a project I plan to sell to the community so has to be hush hush for about a year ;)
11/13/2003 (11:28 pm)
Awww no fair, grrr not allowed to tell about my project. That sux!Rodney if you saw what I am currently working as a replacement for the current Torque editor you'd be busting a gut.
and the idea is ALOT more advanced than frameworks.
Its actually a project I plan to sell to the community so has to be hush hush for about a year ;)
#26
I think this would help tremendously for people who are overwhelmed after the awe subsides. It's amazing what the engine can do, what with all the features that are built in. But it can soon become a big problem when you realize you'll never have a hover vehicle in game but when you remove it you find it breakes terrain (not sure if it does, but it's an example of the intricate locks between some objects in the engine)
- Brett
11/23/2003 (9:18 am)
I tend to stick with Rodney (in a sense I guess.) I'm thinking that people would benefit if they could easily remove parts of the engine that aren't needed. Such as vehicles.. If you never plan on using vehicles, don't include them and it doesn't impact obscure parts of the engine.I think this would help tremendously for people who are overwhelmed after the awe subsides. It's amazing what the engine can do, what with all the features that are built in. But it can soon become a big problem when you realize you'll never have a hover vehicle in game but when you remove it you find it breakes terrain (not sure if it does, but it's an example of the intricate locks between some objects in the engine)
- Brett
#27
Removing terrain would break things. Though it's easily repaired (did it in an afternoon once).
Most of the stuff in the engine, you can just ignore if you're not using... then at the end, you can trim stuff down, based on the needs of your game. (Or remove stuff piecewise as you develop, if it gets in the way.)
Perhaps you're still in awe over the complexity of the engine? ;)
11/23/2003 (10:34 am)
Well... it doesn't. :)Removing terrain would break things. Though it's easily repaired (did it in an afternoon once).
Most of the stuff in the engine, you can just ignore if you're not using... then at the end, you can trim stuff down, based on the needs of your game. (Or remove stuff piecewise as you develop, if it gets in the way.)
Perhaps you're still in awe over the complexity of the engine? ;)
Torque Owner Devon Ly
now loading ............... "Stage"
now loading ............... "Props"
....now loading............ "Actors"
turning on ................ "Lights"
turning on ................. "Effects"
turning on ................. "Camera"
............................ "ACTION"
As for frameworks >:) The spanner is in the workz. That's all I can say at the moment.