Plan for Gonzo T. Clown
by Gonzo T. Clown · 11/18/2004 (8:56 am) · 29 comments
Ok, things are close enough now that I can finally start talking about this to the GG community to make sure my direction is sound and all considerations are being covered.
For quite a while now I have been developing what is at this time titled the "Super Starter Pack" os SSP for short. This "Pack" however is much different than the others in lots of ways and similar in some. The best way to describe it is to say that it is a complete replacement for the Example scripts that you get with the SDK and the Demo scripts that are publicly available. In other words, if you wanted to make a game you could either start with the example scripts and go from there, or you could use this pack to get you started. So what are the differences? Well, honestly, it would take me quite a few plans to fully explain in detail, so I'm going to try and give a feel for what it is and what it's value to you will be.
With all respects to GG and the fantastic products they supply IMO the example scripting more resembles a flea market packed with a bunch of neat stuff than it does a full fledged gaming starter. So I decided it was time to bring the scripts into the modern day with a complete overhaul and redesign that will do more justice to what TGE really is and what it can do for you. With that said, lets examine some of what it will feature.
First off, EVERY .cs file has been formatted neatly to make it uniform and easy to read. They are commented line by line to make them easy to follow and manipulate. An example of what I'm talking about can be seen in the files I supplied for the Complete Voting System . IMO this will help tremendously with new people who are trying to learn how to script, and even experienced coders can use the examples from areas they are not so experienced with. It will also help you to understand what effects your code changes will have on other parts of the function or even other functions that are involved with that particular process.
Next we have cleanup. Every file from the Common, Demo, Starter Racing, Starter FPS, has been combined into a simplified directory structure that allows all of them to exist at once in the same place. No more duplicated scripts and pathway problems to deal with, nor -mod parameters to pass to the executable. The server determines which game you are playing based on the map you load and adjusts itself accordingly. More about this feature will be discussed later. Suffice it to say the uniform directory structure will make it much easier to navigate your way around the files and make changes.
NO MORE EXEC!!! how many of you are familiar with this?
Well in the SSP it looks like this....
No, that's not a typo, it's the truth. The server and client system execs have been precisely redesigned so that ONLY the exact scripts you need will be exec'ed at startup and then depending on if you are a Client, Client-Server, or dedicated server it will then load the appropriate scripts needed to perform those duties. Any new files you add will also be loaded without you having to add any "exec("./pathTo/myScript.cs");" lines to your game to get it into the game. It is completely plug and play now so you can drop a gui into the guis folder or a new script into the proper server or client script folder and it will be exec'ed when needed. It just cant get any easier than that. This also cures the problems with scripts being exec'ed out of order and causing datablock definition errors.
More Cleanup: While formatting and commenting the code it was also greatly debugged, simplified, and vastly improved for efficiency and operational features. Each feature makes maximum use of it's capabilities instead of just getting them into the game for you. And anywhere there was waste, bad logic, or code that just didn't make sense it was rewritten to maximize it's potential and minimize it's use of CPU cycles. This feature alone will save you an incredible amount of development time in making things work or researching how to make them work. Combined with the code commenting you should have no troubles making things work or even modifying them to work differently. And for TorqueScript newbies (and even experienced coders) it will be a great learning tool for proper TS syntax and usage as well as smooth code flow design.
Modular expansion(plugins): Thanks to the new design, extra features like the Complete Voting System can be dropped into the proper folders and they will work automatically. Likewise, if you decided you didn't want to allow votes you would simply remove those scripts and it would be gone. You won't have to worry about what you just broke or what you need to change to make it work right. Also, A lot of the new features that will come with the SSP can just as easily be removed if they are not needed without worrying about breaking stuff.
Self Management: Parts of the game may or may not be needed depending on your game or situation, so most of them self manage to make life easy for you. The AiManager for example. Not only has the AiManager recieved a whole new lease on life, it completely takes care of itself and your AI. Whenever a map is loaded, a new AiManager is created, the AiManager then checks to see if it is even needed. If not it will delete itself, and if needed it will begin it's duty of initializing and managing your AI. Since the AiManager is completely enabled to care for itself and your AI all you will need to do is add your AI choices to your maps and the AiManager will take it from there. At this time there are 4 bot types that are supported, and more in planning that can be "plugged in" when they are done. The "Director"(new feature) manages camera systems in much the same fashion. If you intend on using pathed cameras, or the included "SequenceCams"(new feature), that are included with the SSP, you will only need to place them in your mission and the "Director" will initialize and manage those cameras. The director will also
be responsible for controlling the camera views for an upcoming addition that will enable matches(multi-player games) to be viewed without being entered (Spectators).
Better content control: An incredible amount of effort has been and is being put into making it easier to manage and develop your content. A special content editor has been built in to allow you to create Lights, Particles, emitters, explosions, and audio datablocks. You can then alter those datablocks directly in real time to get them to look or do exactly what you want, and then finally you will simply click on the save button to have the content editor export the datablock to the proper server directory for usage in your game. Unlike the stock TGE which currently only saves in this format....
which would then require you to manually change the "new" to "datablock" the SSP has been upgraded to allow the content editor(or yourself) the option to save into this format...
which will work automatically for you with no intervention at all. Also TGE was upgraded to automatically save the object name in quotes(not currently done) so that you can use spaces in names without syntax errors. Just another in a HUGE list of time saving improvements and features. The content editor can save you a tremendous amount of time developing or tweaking your content because it eliminates a lot of waste while enabling a ton of new abilities to the end user.
I could go on for days about what all you will get with the pack, but you can rest assured that the value of it in time saved, content provided, new features enabled, and even it's learning value will be second to none.
Short FAQ:
Does it have AI that works?
Yes: Although it's not a full blown AI system using the latest A* algorithms and pathfinding techniques like you would find in a AI pack that was being designed solely for AI, it does have a very comprehensive AI system that allows you to simply drop AiSpawners into your maps with a few parameters filled in and the AiManager will take it from there. The included AI are ready to perfrom their tasks and to defend themselves by kicking your butt should you decide to assault one of them. They fight intelligently and deceptively as well as defensively when need be.
Who can use this pack?
Anyone. There will be both a public and licensed versions available. The public version will be a tremendous learning tool for people that are not TorqueScript familiar as well as a great help in prototyping a game because it will make development faster and easier in every way that really matters. The public version WILL be under the same publishing restrictions and limitations as the GG demo is but the licensed version will allow TGE owners to produce their game and content with full rights and no further obligations. If you are new to TGE then it would be a great way to get yourself started in a game, and even if your in full blown development already it can be a fantastic reference for example code to show you how to do something, or even to borrow from parts of the code to expand your own systems. The provided content can be used in your game as well so prototyping for TGE owners will be accelerated just as if you had purchased any of the other currently available content packs.
What kind of content are you talking about?
In addition to the new editors, new guis, new systems, pre-formed datablocks, and new features, you'll also get (among other things)boxes, barrels, guns, chairs, desks, flags, vehicles(flying and wheeled), player models, more artwork and textures, and more code base to start with. You'll also get several pre-coded game types such as Capture The flag, racing, Hunters, Objective, and DeathMatch, which will all manage themselves in a similar fashion to how the AiManager self manages. Overall you'll have a more complete package to start with than has ever been available before. TGE owners will also recieve a patch file and documentation for the engine upgrades neccesary to run the SSP. (Note: Most of the engine mods are simple drop in additions or small minor changes to accomidate extra functionality)
What about documentation?
As stated before, there is line by line documentation to help you follow the flow and functionality and there will be adaquate documentation to demonstrate how to use any of the systems and their parameters properly.
Will it be TSE compatible?
Yes, eventually. When the development is finished and finalized on TGE it will be ported to TSE. The SSP is currently being developed on version 1.3 and will be supported as well as recoded to incude any changes in future TGE releases that break the functionality. The greater portion of the SSP is script based and will not likely be severly impacted by general engine changes. However it will be maintained, upgraded, and fixed if need be to keep it up to date with any future TGE development.
Will I have to buy a TSE license also?
No, one purchase will cover both engines but there is NO GUARANTEE on a release date for a TSE version at this time.
What kind of pricing are we talking here?
At this time the planned release pricing will be $40 for the public version, and $50 for the Licensed version. The Licensed version includes the additional engine upgrades and the right to sell your game using any of the provided content. You will not be able to purchase a licensed version without a TGE license, and you will not be able to run the public version on the current TGE, so don't get any bright ideas, lol. Considering that almost a years worth of cleaning, rewritting and development have been involved in this, it is a tremendous value in respect to time versus dollars.
When is the release?
Unfortunately, all I can say definatively at this time is "Soon". It's under nearly 24/7 development at this time and will be ready when it's ready. It will not be forced out the door to make a deadline.
What about the future?
The SSP is about to complete it's first stage of development. It will be released for sale at that time. The second stage is still in development and at this time is slated to offer full support to a third party 3D moddeling program(currently being written) similar to Quark or Hammer. The goal is to allow you to develop your 3D content using SSP support to assist in script generation and then export it directly into your server directories with scripts intact. In simple terms, the plan is for you to be able to completely generate a game from start to finish in the SSP environment. More about this will be talked about when the details are final and the 3D editor is further along.
More details about the SSP will be released in the future, and all non-sensitive details can be discussed.
Gonzo
For quite a while now I have been developing what is at this time titled the "Super Starter Pack" os SSP for short. This "Pack" however is much different than the others in lots of ways and similar in some. The best way to describe it is to say that it is a complete replacement for the Example scripts that you get with the SDK and the Demo scripts that are publicly available. In other words, if you wanted to make a game you could either start with the example scripts and go from there, or you could use this pack to get you started. So what are the differences? Well, honestly, it would take me quite a few plans to fully explain in detail, so I'm going to try and give a feel for what it is and what it's value to you will be.
With all respects to GG and the fantastic products they supply IMO the example scripting more resembles a flea market packed with a bunch of neat stuff than it does a full fledged gaming starter. So I decided it was time to bring the scripts into the modern day with a complete overhaul and redesign that will do more justice to what TGE really is and what it can do for you. With that said, lets examine some of what it will feature.
First off, EVERY .cs file has been formatted neatly to make it uniform and easy to read. They are commented line by line to make them easy to follow and manipulate. An example of what I'm talking about can be seen in the files I supplied for the Complete Voting System . IMO this will help tremendously with new people who are trying to learn how to script, and even experienced coders can use the examples from areas they are not so experienced with. It will also help you to understand what effects your code changes will have on other parts of the function or even other functions that are involved with that particular process.
Next we have cleanup. Every file from the Common, Demo, Starter Racing, Starter FPS, has been combined into a simplified directory structure that allows all of them to exist at once in the same place. No more duplicated scripts and pathway problems to deal with, nor -mod parameters to pass to the executable. The server determines which game you are playing based on the map you load and adjusts itself accordingly. More about this feature will be discussed later. Suffice it to say the uniform directory structure will make it much easier to navigate your way around the files and make changes.
NO MORE EXEC!!! how many of you are familiar with this?
exec("./scripts/audioProfiles.cs");
// Load up the Game GUIs
exec("./ui/defaultGameProfiles.cs");
exec("./ui/PlayGui.gui");
exec("./ui/ChatHud.gui");
exec("./ui/playerList.gui");
// Load up the shell GUIs
exec("./ui/mainMenuGui.gui");
exec("./ui/QuitGui.gui");
exec("./ui/aboutDlg.gui");
exec("./ui/startMissionGui.gui");
exec("./ui/joinServerGui.gui");
exec("./ui/loadingGui.gui");
exec("./ui/endGameGui.gui");
exec("./ui/optionsDlg.gui");
exec("./ui/remapDlg.gui");
exec("./ui/StartupGui.gui");
exec("./ui/ClientVote.cs");
exec("./DemoLoadTwo.cs");
// Client scripts
exec("./scripts/client.cs");
exec("./scripts/game.cs");
exec("./scripts/missionDownload.cs");
exec("./scripts/serverConnection.cs");
exec("./scripts/playerList.cs");
exec("./scripts/loadingGui.cs");
exec("./scripts/optionsDlg.cs");
exec("./scripts/chatHud.cs");
exec("./scripts/messageHud.cs");
exec("./scripts/playGui.cs");
exec("./scripts/centerPrint.cs");
// Default player key bindings
exec("./scripts/default.bind.cs");
exec("./config.cs");Well in the SSP it looks like this....
No, that's not a typo, it's the truth. The server and client system execs have been precisely redesigned so that ONLY the exact scripts you need will be exec'ed at startup and then depending on if you are a Client, Client-Server, or dedicated server it will then load the appropriate scripts needed to perform those duties. Any new files you add will also be loaded without you having to add any "exec("./pathTo/myScript.cs");" lines to your game to get it into the game. It is completely plug and play now so you can drop a gui into the guis folder or a new script into the proper server or client script folder and it will be exec'ed when needed. It just cant get any easier than that. This also cures the problems with scripts being exec'ed out of order and causing datablock definition errors.
More Cleanup: While formatting and commenting the code it was also greatly debugged, simplified, and vastly improved for efficiency and operational features. Each feature makes maximum use of it's capabilities instead of just getting them into the game for you. And anywhere there was waste, bad logic, or code that just didn't make sense it was rewritten to maximize it's potential and minimize it's use of CPU cycles. This feature alone will save you an incredible amount of development time in making things work or researching how to make them work. Combined with the code commenting you should have no troubles making things work or even modifying them to work differently. And for TorqueScript newbies (and even experienced coders) it will be a great learning tool for proper TS syntax and usage as well as smooth code flow design.
Modular expansion(plugins): Thanks to the new design, extra features like the Complete Voting System can be dropped into the proper folders and they will work automatically. Likewise, if you decided you didn't want to allow votes you would simply remove those scripts and it would be gone. You won't have to worry about what you just broke or what you need to change to make it work right. Also, A lot of the new features that will come with the SSP can just as easily be removed if they are not needed without worrying about breaking stuff.
Self Management: Parts of the game may or may not be needed depending on your game or situation, so most of them self manage to make life easy for you. The AiManager for example. Not only has the AiManager recieved a whole new lease on life, it completely takes care of itself and your AI. Whenever a map is loaded, a new AiManager is created, the AiManager then checks to see if it is even needed. If not it will delete itself, and if needed it will begin it's duty of initializing and managing your AI. Since the AiManager is completely enabled to care for itself and your AI all you will need to do is add your AI choices to your maps and the AiManager will take it from there. At this time there are 4 bot types that are supported, and more in planning that can be "plugged in" when they are done. The "Director"(new feature) manages camera systems in much the same fashion. If you intend on using pathed cameras, or the included "SequenceCams"(new feature), that are included with the SSP, you will only need to place them in your mission and the "Director" will initialize and manage those cameras. The director will also
be responsible for controlling the camera views for an upcoming addition that will enable matches(multi-player games) to be viewed without being entered (Spectators).
Better content control: An incredible amount of effort has been and is being put into making it easier to manage and develop your content. A special content editor has been built in to allow you to create Lights, Particles, emitters, explosions, and audio datablocks. You can then alter those datablocks directly in real time to get them to look or do exactly what you want, and then finally you will simply click on the save button to have the content editor export the datablock to the proper server directory for usage in your game. Unlike the stock TGE which currently only saves in this format....
new fxLightData("PurpleHalo")
{
};which would then require you to manually change the "new" to "datablock" the SSP has been upgraded to allow the content editor(or yourself) the option to save into this format...
datablock fxLightData("PurpleHalo")
{
};which will work automatically for you with no intervention at all. Also TGE was upgraded to automatically save the object name in quotes(not currently done) so that you can use spaces in names without syntax errors. Just another in a HUGE list of time saving improvements and features. The content editor can save you a tremendous amount of time developing or tweaking your content because it eliminates a lot of waste while enabling a ton of new abilities to the end user.
I could go on for days about what all you will get with the pack, but you can rest assured that the value of it in time saved, content provided, new features enabled, and even it's learning value will be second to none.
Short FAQ:
Does it have AI that works?
Yes: Although it's not a full blown AI system using the latest A* algorithms and pathfinding techniques like you would find in a AI pack that was being designed solely for AI, it does have a very comprehensive AI system that allows you to simply drop AiSpawners into your maps with a few parameters filled in and the AiManager will take it from there. The included AI are ready to perfrom their tasks and to defend themselves by kicking your butt should you decide to assault one of them. They fight intelligently and deceptively as well as defensively when need be.
Who can use this pack?
Anyone. There will be both a public and licensed versions available. The public version will be a tremendous learning tool for people that are not TorqueScript familiar as well as a great help in prototyping a game because it will make development faster and easier in every way that really matters. The public version WILL be under the same publishing restrictions and limitations as the GG demo is but the licensed version will allow TGE owners to produce their game and content with full rights and no further obligations. If you are new to TGE then it would be a great way to get yourself started in a game, and even if your in full blown development already it can be a fantastic reference for example code to show you how to do something, or even to borrow from parts of the code to expand your own systems. The provided content can be used in your game as well so prototyping for TGE owners will be accelerated just as if you had purchased any of the other currently available content packs.
What kind of content are you talking about?
In addition to the new editors, new guis, new systems, pre-formed datablocks, and new features, you'll also get (among other things)boxes, barrels, guns, chairs, desks, flags, vehicles(flying and wheeled), player models, more artwork and textures, and more code base to start with. You'll also get several pre-coded game types such as Capture The flag, racing, Hunters, Objective, and DeathMatch, which will all manage themselves in a similar fashion to how the AiManager self manages. Overall you'll have a more complete package to start with than has ever been available before. TGE owners will also recieve a patch file and documentation for the engine upgrades neccesary to run the SSP. (Note: Most of the engine mods are simple drop in additions or small minor changes to accomidate extra functionality)
What about documentation?
As stated before, there is line by line documentation to help you follow the flow and functionality and there will be adaquate documentation to demonstrate how to use any of the systems and their parameters properly.
Will it be TSE compatible?
Yes, eventually. When the development is finished and finalized on TGE it will be ported to TSE. The SSP is currently being developed on version 1.3 and will be supported as well as recoded to incude any changes in future TGE releases that break the functionality. The greater portion of the SSP is script based and will not likely be severly impacted by general engine changes. However it will be maintained, upgraded, and fixed if need be to keep it up to date with any future TGE development.
Will I have to buy a TSE license also?
No, one purchase will cover both engines but there is NO GUARANTEE on a release date for a TSE version at this time.
What kind of pricing are we talking here?
At this time the planned release pricing will be $40 for the public version, and $50 for the Licensed version. The Licensed version includes the additional engine upgrades and the right to sell your game using any of the provided content. You will not be able to purchase a licensed version without a TGE license, and you will not be able to run the public version on the current TGE, so don't get any bright ideas, lol. Considering that almost a years worth of cleaning, rewritting and development have been involved in this, it is a tremendous value in respect to time versus dollars.
When is the release?
Unfortunately, all I can say definatively at this time is "Soon". It's under nearly 24/7 development at this time and will be ready when it's ready. It will not be forced out the door to make a deadline.
What about the future?
The SSP is about to complete it's first stage of development. It will be released for sale at that time. The second stage is still in development and at this time is slated to offer full support to a third party 3D moddeling program(currently being written) similar to Quark or Hammer. The goal is to allow you to develop your 3D content using SSP support to assist in script generation and then export it directly into your server directories with scripts intact. In simple terms, the plan is for you to be able to completely generate a game from start to finish in the SSP environment. More about this will be talked about when the details are final and the 3D editor is further along.
More details about the SSP will be released in the future, and all non-sensitive details can be discussed.
Gonzo
About the author
#2
11/18/2004 (9:16 am)
SOUNDS awesome! This is exactly what I have been trying to do myself. I would be very interested in Beta - testing or helping out.
#4
I have been following your coding examples and i must say they are the best ones around.
Dont stop because of the pack only :)
I buy this even if i dont use it , i think its gonna be lots of work to convert all things,but it could still be useful to look at and learn from..
11/18/2004 (9:19 am)
Gonzo this sounds great.I have been following your coding examples and i must say they are the best ones around.
Dont stop because of the pack only :)
I buy this even if i dont use it , i think its gonna be lots of work to convert all things,but it could still be useful to look at and learn from..
#5
11/18/2004 (9:51 am)
Sounds interesting.
#7
11/18/2004 (12:05 pm)
I can't wait to see this one for some strange reason.
#8
11/18/2004 (12:28 pm)
Will all features of the editing environment be cross platform?
#9
Please tell me it is a cross platform development !
11/18/2004 (12:44 pm)
Where is the "Buy Now" link ? Please tell me it is a cross platform development !
#10
1- If I use ssp with my TGE 1.3 can I integrate other pack with it, like lighting pack or RTS pack or whatever pack?
2- Colud you talk a lettel more about your AI?
11/18/2004 (1:16 pm)
Gonzo Greate work man, I have lettel question:1- If I use ssp with my TGE 1.3 can I integrate other pack with it, like lighting pack or RTS pack or whatever pack?
2- Colud you talk a lettel more about your AI?
#11
11/18/2004 (1:29 pm)
sounds great Gonzo so this is the AI pack. well its got a lot more than AI material in it. the ai still sounds great though. one question if I buy non licensed for 40$ and then get a game could I drop another 10$ to license? to phil: this hasn't come out yet but will be out shortly (I hope) so we'll have to wait.
#12
11/18/2004 (1:35 pm)
I tell you what, if this does even half what you're advertising (and I have no reason to doubt it will do all of it) it really is a pretty amazing product. We've spent a very long time dealing with so many of the issues you bring up...would love to see it!
#13
I just have question, if this AI pack will be 100% compatible with the pack/s that I bought and planning to buy or it will require great efforts of re-writing the other packs to conform to your AI Pack? I already bought a pack from BT and planning to get the enviroment pack.
11/18/2004 (5:21 pm)
Gonzo, this is heaven-sent to small team like mine. It will save time, I'm just starting to to program in C++ and OOP and having such pack will be great help in shortening our development time. I just have question, if this AI pack will be 100% compatible with the pack/s that I bought and planning to buy or it will require great efforts of re-writing the other packs to conform to your AI Pack? I already bought a pack from BT and planning to get the enviroment pack.
#14
Now, before I address some of the specifics here, I would like to clarify a few things to eliminate confusion before it gets started.
1. This is not some attempt to lock people into a product line I'm designing, or a means of forcing a proprietary format on anyone. Nor is it an attempt to bump other packs to the side. While I have rewritten a great deal of the code as well as fine tuned it, formatted it, and commented it to make it easier to follow, the original goal was to make it as stock TGE compatible as possible. Were it not for a few Ai Adjustments that I had to have, and some of the content creation stuff like the datablock export that really makes the pack a much better product it would pretty much be drop in compatible with the head version of the SDK. Since I knew I wasn't going to get away with zero SDK adjustments I just decided to leave what I could alone, and fix, or adjust what I really needed an no more. The reason for this was because I felt that a whole new script base could be designed and implemented without alienating anyone who had already started development, or being so far out of whack with the doc's that no one would ever understand it. It really is designed to be as freindly as possible to newbies as well as TGE vets by taking a lot of the common problems that had been surfacing for months and just eliminating them completely. Trust me on this, merging all the example scripts into a more manage directory and execution structure wasn't easy for me by any means. So I can fully understand how just that first step can be a killer to someones drive to carry on. It really does take time, paitience, planning and commitment to get that done before you can even really get started on your own game. And if I were a new TGE user I probably would have blown my stack, lol. That's not the way it should be. My hope is that my efforts on this will enable MANY more people a better learning and development experience that will translate into a better overall community for all of us.
2. Although at this time my main focus is to release a 1.3 ready system that is rock solid, easy to use, and far more value than you are really paying for, I have every intent on keeping the SSP as TGE freindly as possible. This includes supporting other packs like the Synapse Gaming: Lighting Pack to the best of my abilities by including functionality that supports and enhances their features instead of conflicting with them. Stepping on toes or creating more confusion would go against everything this pack was designed for, which is to simplify and speed your development process and learning curve. Although I do own a Synapse License I have not examined integration of it yet because it is not yet 1.3 ready and I am focusing completely on 1.3 and future TGE and TSE releases. When John says the pack is 1.3 ready I will at that time begin to examine it's impact on this pack and vice versa. Keeping in mind that the greatest portion of my work is done in the scripting and that lighting pack is by far more of an engine upgrade, my initial assesment is that the SG:LP will have more impact on the SSP than the SSP will have on it. Regardless Light Pack owners will not be left out in the cold to fend for themselves as I will make every effort to smooth the integration if there are any areas where the packs don't see eye to eye.
3. The upcoming GG AI Pack : The AI in the SSP is in no way meant to compete on the same level as the AI that is being designed for the AI pack. Their system is highly specialized and has been months in the works. May be months more for all I know. I suspect their system is requiring some pretty hefty engine changes centered around the AI player class that will probably completely destroy the compatibility of the SSP's AI in future TGE releases(beyond 1.3). However, if you were going to use their pack, losing the AI from mine probably wouldn't be a hard decision to make. While the SSP's AI is not as sophisticated in design as theirs is, it is by no means just a gimick either. The bots are designed to be incredibly easy to get into missions and fight with, and to help you prototype single/multi player games faster by being able to just drop them in and go instead of figuring out the best way to implement them or even getting them to work at all. The SSP AI system is designed to be well rounded, incredibly easy to use, easy to learn from, self managing, and fun. Nothing more. Award winning AI performance was not the goal and it hasn't been achieved, lol. If you need or want serious AI then you'll either want their pack, or you'll want to combine their pack with mine in some fashion(assuming that's possible). Since I'm not a part of their project I have no way of knowing how much if any at all of my stuff could be integrated with thiers. But, I can tell you for sure that my AI system is modular as I described before and could just be taken out to make way for their pack by doing nothing more than removing all my AI scripts. You would not have any problems removing it and no special care would need to be taken because they are designed to be inserted or removed as the user see's fit. I can only assume that those guys have some kind of stratagy to help buyers who are already in development integrate the new pack into their games, and in that respect it very well could be easier to integrate it into the SSP than it would be for your very own project.
Ultimately we won't know until it's released. And when they do release it I will be examining it's impact on the SSP and what adjustments will need to be made(if any) to accomidate their new stuff for those that decide to purchase it as well as the SSP. It's in all our interests to have this stuff work together as well as possible and since I'm the outsider in this situation most of the burdon will most likely be mine to shoulder. No worries though, because I'm already mentally prepared to deal with these situations as soon as they appear and these considerations have been a part of the SSP design for quite a while now.
4. The RTS pack. Dont get your hopes up on this one. The RTS is probably the most specialized pack available for TGE. Although I have not used or examined it, my fundemental understanding of it's design and build lead me to believe that use of both the RTS and the SSP together is completely out of the question without at least some serious integration work. Nothing is impossible but my guess is that the RTS/SSP combonation will be a difficult one at best. But the same could be said about the AiPack/RTS Pack combo. They are not likely to be very buddy buddy out of the box either. However, the SSP will still have things to offer RTS users ranging from the art content that is included, to the learning assistance of the commented scripting and function design. It's not unreasonable to suggest that various parts of the SSP code could be integrated directly into the RTS packs functionality to expand it or improve it. There is still a tremendous amount of quality work in the SSP that can be exploited in various ways even if you cant just slap the two together and take off with them. So ultimately time will tell on these two, but I'm very hesitant to say anything other than I believe it will be difficult at best to merge these two.
Ok, if your still awake at this point lets touch on some questions real fast.....
The built in content editor(lighting, particles, audiio, etc...) is very much like the mission editor in most respects, it is just designed specifically for real time editing and creation of datablocks to assist you in getting a bunch of stuff into your game quickly instead of spending so much time starting and stopping TGE to adjust script and datablock values. The export features were also designed to basically get you out of the text editor and into your game. So AFAIK it should be completely cross platform ready when it ships. If you are reffering to the 3rd party 3D mapping editor that the SSP will support in it's second stage of development, I have been authorized to tell you...
"Not only will the 3D editor be cross platform compatible, it is a TOP priorty in the design and not just something that will be gotten around to. The goal has always been cross platform from the start of it's design." And for now, that's all I can realy say about that. The authors of that software will shed more light on the subject(as will I) when the release date for that product draws near.
I can say on my end that the reason this collaboration is being made is because the modular plug and play design of the SSP will enable me to lend full support to their interface in a fashion you might call a "middle man" without compromising the SSP's design or intent to do so. Although the 3D editor is going to heavily depend on the SSP to tie everything together, the SSP will have no dependancy on it to perform, nor will the addition of the support impact SSP users who do not wish to use the interface. This is being done in this fashion because the demand for a more complete 3D editing environment is high due to lack of full support from Quark and zero support from Hammer. Also we have to go with the assumption that future changes in TGE will break compatibility with the editor on a constant basis if it were directly integrated with the TGE environment. We have determined that fixing these types of changes will be much easier in the middle than on the end, so I'll be using the SSP as a medium thorugh which easy interfacing and upgrading can be made. When I was first approched with the offer I couldn't help but think it was a great idea myself, so I'm going to support them on this because I feel that having an editor designed from the ground up for TGE users is only fair since other engines have thier editors to brag about. TGE has needed a good editor for a long time and they want to deliver one and I believe it will be a great thing for the GG community down the line when it's done. I'm VERY excited about the whole thing and I'm hoping you guys are also.
I had given that question a huge amount of consideration in my head for a while now, and at this time my decision comes down to this.... There is no easy nor ideal solution for this matter that I believe everyone is going to think is fair, so untill I hear a better idea, this is how it's going to be....
If you cannot afford the $150 for TGE and the SSP, then you will most certainly be spending your $100 on TGE. This is fine with me becuse part of the reason I'm doing this is to give the community and all future community members a much better starting solution to deal with. And while I would wish that everyone could have it when they get the engine, I would still prefer that if you had a choice between SSP or TGE that you would start yourself with TGE and become a full community member and worry about the SSP later down the line, if at all. If you cannot afford TGE by itself, then maybe you'll consider the SSP to start yourself on to learn with and to keep you in the community untill such time as you can upgrade yourself to TGE. Or if you are just completely unsure and would rather risk 40 bucks than 100 or 150, then my hope is you'll find enough value in the product to make up your mind that TGE is worth the money and you'll get it and here again we'll have a new community member. Finally, it is my belief that if you do spend the 40, then come back later and spend the 100 on TGE, then chances are you've seen that both products are well worth their respective costs and that spending an additional $50 to upgrade your SSP is neither unreasonable nor will it break your development budget. And ultimately the REAL cost difference to you at that point is only $40. A small price to pay for the value you will have already extracted from the products. I used to make $40 bucks an hour installing Cable and for that $40 you spend on the SSP you'll be getting more than a years worth of some of my best work ever, PLUS the future support and features that comes with it as well.
While I am very happy with the AI that's in the pack and still have plans to improve it even more, the SSP is far more than just an AI pack. It's an everything pack. It's been designed to give you a quantum leap ahead on what you would be able to accomplish with the stock Example or Demo scripts. It's designed to make everything, much faster and easier to understand as well as far more functional and complete than the basic demo's. The premise is that you will spend more time actually learning, making, or modifying content in a less frustrating environment which I hope will result in more good things coming from more people than ever before. I have been in the trenches and I know exactly what it is like to be stumped and frustrated for hours, days, and even weeks on end because something wasn't working right. And in some cases, those things were not so long ago... Here's the proof Everybody get's stuck. Doesn't matter how good you are, or how long you've done this, something is going to put the breaks on your plans and make you wonder where you went wrong. It happens. But my main mission here is to make sure that anyone that purchases the SSP never gets stuck on something I had to overcome and that they'll never run into the problems that the stock scripts can sometimes present when ones ideas are larger than ones resources. In short, I'm trying to share more of my knowledge and abilities with everybody at once instead of doing it post by post day by day same problem after same problem, lol. I really don't mind helping people at all, but there comes a point where you begin to say "there has got to be a better way than this to get the job done". Dont get me wrong though. Even if I never sold a copy of SSP or sold a million of them, I'll still be here plugging away at people's problems as best I can, when I can. That's pretty much all I can do.
As for compatibility with the other content packs. Unless there is something special about them that I am oblivous to, content packs from BraveTree, Tim Aste, and anyone else that makes content should be every bit as compatible with SSP as they are with stock TGE. Although I will boldly step out and say I believe you will find them easier in the long run to integrate into and manage using the SSP environment.
HOLY COW!!! Did I type all that? That'll teach you guys to ask me any more questions, haha.
Gonzo
11/19/2004 (12:26 am)
First off I'd just like to say thanks to everyone for the kind words. I had really hoped that this was something that would benefit a lot of people both now and in the future. The inspiration for this came directly from the forums and my assistance helping others. After a while I started realizing that there were repeat patterns of questions regarding certain systems and there was way to much confusion about areas where there really should be none at all. Seeing people getting frustrated with these various problems repeatedly helped me to decide to drop my current developments and plow head first into a massive overhaul of the scripts line by line. I took a lot of notes on subjects that were popping up in the forums repeatedly to make sure that I could address those issues properly when I got to them and I'm still taking notes to some degree at this time. Since I had already addressed quite a bit of these issues already, it just made sense to try to tackle the rest of them in one giant stroke. I felt like this was the right thing to do but ultimately had no idea how anyone else might feel about this. I guess now I know.Now, before I address some of the specifics here, I would like to clarify a few things to eliminate confusion before it gets started.
1. This is not some attempt to lock people into a product line I'm designing, or a means of forcing a proprietary format on anyone. Nor is it an attempt to bump other packs to the side. While I have rewritten a great deal of the code as well as fine tuned it, formatted it, and commented it to make it easier to follow, the original goal was to make it as stock TGE compatible as possible. Were it not for a few Ai Adjustments that I had to have, and some of the content creation stuff like the datablock export that really makes the pack a much better product it would pretty much be drop in compatible with the head version of the SDK. Since I knew I wasn't going to get away with zero SDK adjustments I just decided to leave what I could alone, and fix, or adjust what I really needed an no more. The reason for this was because I felt that a whole new script base could be designed and implemented without alienating anyone who had already started development, or being so far out of whack with the doc's that no one would ever understand it. It really is designed to be as freindly as possible to newbies as well as TGE vets by taking a lot of the common problems that had been surfacing for months and just eliminating them completely. Trust me on this, merging all the example scripts into a more manage directory and execution structure wasn't easy for me by any means. So I can fully understand how just that first step can be a killer to someones drive to carry on. It really does take time, paitience, planning and commitment to get that done before you can even really get started on your own game. And if I were a new TGE user I probably would have blown my stack, lol. That's not the way it should be. My hope is that my efforts on this will enable MANY more people a better learning and development experience that will translate into a better overall community for all of us.
2. Although at this time my main focus is to release a 1.3 ready system that is rock solid, easy to use, and far more value than you are really paying for, I have every intent on keeping the SSP as TGE freindly as possible. This includes supporting other packs like the Synapse Gaming: Lighting Pack to the best of my abilities by including functionality that supports and enhances their features instead of conflicting with them. Stepping on toes or creating more confusion would go against everything this pack was designed for, which is to simplify and speed your development process and learning curve. Although I do own a Synapse License I have not examined integration of it yet because it is not yet 1.3 ready and I am focusing completely on 1.3 and future TGE and TSE releases. When John says the pack is 1.3 ready I will at that time begin to examine it's impact on this pack and vice versa. Keeping in mind that the greatest portion of my work is done in the scripting and that lighting pack is by far more of an engine upgrade, my initial assesment is that the SG:LP will have more impact on the SSP than the SSP will have on it. Regardless Light Pack owners will not be left out in the cold to fend for themselves as I will make every effort to smooth the integration if there are any areas where the packs don't see eye to eye.
3. The upcoming GG AI Pack : The AI in the SSP is in no way meant to compete on the same level as the AI that is being designed for the AI pack. Their system is highly specialized and has been months in the works. May be months more for all I know. I suspect their system is requiring some pretty hefty engine changes centered around the AI player class that will probably completely destroy the compatibility of the SSP's AI in future TGE releases(beyond 1.3). However, if you were going to use their pack, losing the AI from mine probably wouldn't be a hard decision to make. While the SSP's AI is not as sophisticated in design as theirs is, it is by no means just a gimick either. The bots are designed to be incredibly easy to get into missions and fight with, and to help you prototype single/multi player games faster by being able to just drop them in and go instead of figuring out the best way to implement them or even getting them to work at all. The SSP AI system is designed to be well rounded, incredibly easy to use, easy to learn from, self managing, and fun. Nothing more. Award winning AI performance was not the goal and it hasn't been achieved, lol. If you need or want serious AI then you'll either want their pack, or you'll want to combine their pack with mine in some fashion(assuming that's possible). Since I'm not a part of their project I have no way of knowing how much if any at all of my stuff could be integrated with thiers. But, I can tell you for sure that my AI system is modular as I described before and could just be taken out to make way for their pack by doing nothing more than removing all my AI scripts. You would not have any problems removing it and no special care would need to be taken because they are designed to be inserted or removed as the user see's fit. I can only assume that those guys have some kind of stratagy to help buyers who are already in development integrate the new pack into their games, and in that respect it very well could be easier to integrate it into the SSP than it would be for your very own project.
Ultimately we won't know until it's released. And when they do release it I will be examining it's impact on the SSP and what adjustments will need to be made(if any) to accomidate their new stuff for those that decide to purchase it as well as the SSP. It's in all our interests to have this stuff work together as well as possible and since I'm the outsider in this situation most of the burdon will most likely be mine to shoulder. No worries though, because I'm already mentally prepared to deal with these situations as soon as they appear and these considerations have been a part of the SSP design for quite a while now.
4. The RTS pack. Dont get your hopes up on this one. The RTS is probably the most specialized pack available for TGE. Although I have not used or examined it, my fundemental understanding of it's design and build lead me to believe that use of both the RTS and the SSP together is completely out of the question without at least some serious integration work. Nothing is impossible but my guess is that the RTS/SSP combonation will be a difficult one at best. But the same could be said about the AiPack/RTS Pack combo. They are not likely to be very buddy buddy out of the box either. However, the SSP will still have things to offer RTS users ranging from the art content that is included, to the learning assistance of the commented scripting and function design. It's not unreasonable to suggest that various parts of the SSP code could be integrated directly into the RTS packs functionality to expand it or improve it. There is still a tremendous amount of quality work in the SSP that can be exploited in various ways even if you cant just slap the two together and take off with them. So ultimately time will tell on these two, but I'm very hesitant to say anything other than I believe it will be difficult at best to merge these two.
Ok, if your still awake at this point lets touch on some questions real fast.....
Quote: Will all features of the editing environment be cross platform?
The built in content editor(lighting, particles, audiio, etc...) is very much like the mission editor in most respects, it is just designed specifically for real time editing and creation of datablocks to assist you in getting a bunch of stuff into your game quickly instead of spending so much time starting and stopping TGE to adjust script and datablock values. The export features were also designed to basically get you out of the text editor and into your game. So AFAIK it should be completely cross platform ready when it ships. If you are reffering to the 3rd party 3D mapping editor that the SSP will support in it's second stage of development, I have been authorized to tell you...
"Not only will the 3D editor be cross platform compatible, it is a TOP priorty in the design and not just something that will be gotten around to. The goal has always been cross platform from the start of it's design." And for now, that's all I can realy say about that. The authors of that software will shed more light on the subject(as will I) when the release date for that product draws near.
I can say on my end that the reason this collaboration is being made is because the modular plug and play design of the SSP will enable me to lend full support to their interface in a fashion you might call a "middle man" without compromising the SSP's design or intent to do so. Although the 3D editor is going to heavily depend on the SSP to tie everything together, the SSP will have no dependancy on it to perform, nor will the addition of the support impact SSP users who do not wish to use the interface. This is being done in this fashion because the demand for a more complete 3D editing environment is high due to lack of full support from Quark and zero support from Hammer. Also we have to go with the assumption that future changes in TGE will break compatibility with the editor on a constant basis if it were directly integrated with the TGE environment. We have determined that fixing these types of changes will be much easier in the middle than on the end, so I'll be using the SSP as a medium thorugh which easy interfacing and upgrading can be made. When I was first approched with the offer I couldn't help but think it was a great idea myself, so I'm going to support them on this because I feel that having an editor designed from the ground up for TGE users is only fair since other engines have thier editors to brag about. TGE has needed a good editor for a long time and they want to deliver one and I believe it will be a great thing for the GG community down the line when it's done. I'm VERY excited about the whole thing and I'm hoping you guys are also.
Quote:if I buy non licensed for 40$ and then get a game could I drop another 10$ to license?
I had given that question a huge amount of consideration in my head for a while now, and at this time my decision comes down to this.... There is no easy nor ideal solution for this matter that I believe everyone is going to think is fair, so untill I hear a better idea, this is how it's going to be....
If you cannot afford the $150 for TGE and the SSP, then you will most certainly be spending your $100 on TGE. This is fine with me becuse part of the reason I'm doing this is to give the community and all future community members a much better starting solution to deal with. And while I would wish that everyone could have it when they get the engine, I would still prefer that if you had a choice between SSP or TGE that you would start yourself with TGE and become a full community member and worry about the SSP later down the line, if at all. If you cannot afford TGE by itself, then maybe you'll consider the SSP to start yourself on to learn with and to keep you in the community untill such time as you can upgrade yourself to TGE. Or if you are just completely unsure and would rather risk 40 bucks than 100 or 150, then my hope is you'll find enough value in the product to make up your mind that TGE is worth the money and you'll get it and here again we'll have a new community member. Finally, it is my belief that if you do spend the 40, then come back later and spend the 100 on TGE, then chances are you've seen that both products are well worth their respective costs and that spending an additional $50 to upgrade your SSP is neither unreasonable nor will it break your development budget. And ultimately the REAL cost difference to you at that point is only $40. A small price to pay for the value you will have already extracted from the products. I used to make $40 bucks an hour installing Cable and for that $40 you spend on the SSP you'll be getting more than a years worth of some of my best work ever, PLUS the future support and features that comes with it as well.
Quote:if this AI pack will be 100% compatible with the pack/s that I bought and planning to buy or it will require great efforts of re-writing the other packs to conform to your AI Pack?
While I am very happy with the AI that's in the pack and still have plans to improve it even more, the SSP is far more than just an AI pack. It's an everything pack. It's been designed to give you a quantum leap ahead on what you would be able to accomplish with the stock Example or Demo scripts. It's designed to make everything, much faster and easier to understand as well as far more functional and complete than the basic demo's. The premise is that you will spend more time actually learning, making, or modifying content in a less frustrating environment which I hope will result in more good things coming from more people than ever before. I have been in the trenches and I know exactly what it is like to be stumped and frustrated for hours, days, and even weeks on end because something wasn't working right. And in some cases, those things were not so long ago... Here's the proof Everybody get's stuck. Doesn't matter how good you are, or how long you've done this, something is going to put the breaks on your plans and make you wonder where you went wrong. It happens. But my main mission here is to make sure that anyone that purchases the SSP never gets stuck on something I had to overcome and that they'll never run into the problems that the stock scripts can sometimes present when ones ideas are larger than ones resources. In short, I'm trying to share more of my knowledge and abilities with everybody at once instead of doing it post by post day by day same problem after same problem, lol. I really don't mind helping people at all, but there comes a point where you begin to say "there has got to be a better way than this to get the job done". Dont get me wrong though. Even if I never sold a copy of SSP or sold a million of them, I'll still be here plugging away at people's problems as best I can, when I can. That's pretty much all I can do.
As for compatibility with the other content packs. Unless there is something special about them that I am oblivous to, content packs from BraveTree, Tim Aste, and anyone else that makes content should be every bit as compatible with SSP as they are with stock TGE. Although I will boldly step out and say I believe you will find them easier in the long run to integrate into and manage using the SSP environment.
HOLY COW!!! Did I type all that? That'll teach you guys to ask me any more questions, haha.
Gonzo
#15
11/19/2004 (8:08 am)
OK. I'm in line with my sleeping bag and tent. This is the very same thing I have been trying to accomplish all year for my team. I think the BIGGEST and most attractive thing you are offering, is the dynamic datablock creation. WOOT!
#16
Also, have you even attempted to run this with TSE yet? I did read your full post, and I realize any issues it has will be fixed at another time. But how many/serious are the issues? SLP claims its not 1.3 ready, and yet I was able to get my copy working great with only minimal work. Can those in the know get SSP working with TSE fairly easily, without waiting on future releases?
11/19/2004 (10:43 am)
Are there any security issues in the method you're using to load scripts? Off the top of my head, the only other method I come up with, is an auto directory loading system. That method of course would allow clients to run their own code, which is a big no-no. Also, have you even attempted to run this with TSE yet? I did read your full post, and I realize any issues it has will be fixed at another time. But how many/serious are the issues? SLP claims its not 1.3 ready, and yet I was able to get my copy working great with only minimal work. Can those in the know get SSP working with TSE fairly easily, without waiting on future releases?
#17
11/19/2004 (10:55 am)
It would be nice if GG could move approval of something like this into the current Torque. Just a thought. Good stuff you got.
#19
Erik - yes, of course there are. But no more than you have with stock TGE. At least not the way I see it. If you locked up your game so tight that i couldn't even open the folders beyond the root, I could still drop this line....
exec("./myScript.cs"); into the bottom of the main.cs file and pretty well set myself up with a clean door right on in. There are resources for embedding the main.cs into your .exe which could defeat that tactic, but thats just one mode of attack of many that could be used. In a multiplayer game, you could give them complete access to everything and yet still leave them nothing to screw with as long as your servers are built securely. The topic of script security and cheat protection have been hashed to death looking for the perfect protection solution, and as far as I know, none have been found. If you sent me nothing but .dso's, no main.cs, no console, no editors, and really nothing at all to work with but a console log, I would take a single .dso out of the game and see exactly what function returned a console error like...
Unable to find function chatMessageClient
And guess who would have a new...
function chatMessageClient()
built and ready to start exporting info right out of the game at the next startup? And this is just basic stuff. There are 12 year old crackers out there that would run circles around me when it came to prying into your scripts. IMO the best you can do is to limit how much information is actually passing between the client and the server, keep the integrity of those communications secure, and leave them as little script assisted play potential as reasonably possible, and then move on knowing you've done about all that is reasonable to expect from anyone to protect yourself from the average joes ability to wreak havoc on your game servers. If companies that spend millions upon millions in development and purchasing punkbuster and everything else can't stop cheaters from cheating and cracking, how can any of us indies realistically hope to stop them? I'm not saying you shouldn't take standard precautions and do as much as you feel you can, but I am saying that IMO it's a fools errand to try and defeat an entire industry all by yourself. And yes, cheating is a multi-million dollar industry. Make no mistake about it. There are "Cheat-Co's" out there that are always looking for the next game they can make some $$$ off of by cheating at it. And they aren't about to let you or I stand between them and their money just because it's our game.
I am a firm believer though that you can greatly minimize their impact on your good customers and the credibility of your game at the server side, but trying to keep them out of the client just aint gonna happen. Although nothing would make me happier than for somebody to come make me eat those statements by showing us all the way.
But just to entertain your question(it is a good one BTW) I'm pretty sure that we can agree that putting a line by line, file by file exec INTO the SSP would be a task even a newbie coud handle. The most important aspect here is that the exec is already error free, so once they were ready to ship, they could simply take their console file and use it as your template in a manner such as this....
Change this(small example)...
to this...
Then comment out the directory loaders and your done. Pretty much back to normal. However, I do believe that having a directory loader is a better teaching tool in the long run, because it shows that you do not have to have every single script execing in the exact perfect order to prevent definition errors. All of us at one time or another had to deal with moving this line to this spot and exec'ing this before that, etc... So by getting into the habit of building code that is not so dependant on perfect execution, you build better code to start with and eliminate problems that really dont need or even have to exist.
There are of course always going to be those files that have to come first no matter what. Thats a given simply because you have to start somewhere. But IMO, at 4 to 6 files deep into your structure, you should be free of those limitations if you have a good solid design to begin with.
EDIT:
@ Jorgen - Gonzo also has a good eye for what battles he can win, and what battles he'll never win. ;-0
Any one man trying to fight a huge pack of predators is simply....pointless. Don't get me wrong though, I do think it is very important to do your best to lock things down. But once you start obsessing over every little detail, you've entered a self defeating mode because there just is no perfect security.
11/19/2004 (11:34 pm)
You guys are making me blush. To kind, to kind, lolErik - yes, of course there are. But no more than you have with stock TGE. At least not the way I see it. If you locked up your game so tight that i couldn't even open the folders beyond the root, I could still drop this line....
exec("./myScript.cs"); into the bottom of the main.cs file and pretty well set myself up with a clean door right on in. There are resources for embedding the main.cs into your .exe which could defeat that tactic, but thats just one mode of attack of many that could be used. In a multiplayer game, you could give them complete access to everything and yet still leave them nothing to screw with as long as your servers are built securely. The topic of script security and cheat protection have been hashed to death looking for the perfect protection solution, and as far as I know, none have been found. If you sent me nothing but .dso's, no main.cs, no console, no editors, and really nothing at all to work with but a console log, I would take a single .dso out of the game and see exactly what function returned a console error like...
Unable to find function chatMessageClient
And guess who would have a new...
function chatMessageClient()
built and ready to start exporting info right out of the game at the next startup? And this is just basic stuff. There are 12 year old crackers out there that would run circles around me when it came to prying into your scripts. IMO the best you can do is to limit how much information is actually passing between the client and the server, keep the integrity of those communications secure, and leave them as little script assisted play potential as reasonably possible, and then move on knowing you've done about all that is reasonable to expect from anyone to protect yourself from the average joes ability to wreak havoc on your game servers. If companies that spend millions upon millions in development and purchasing punkbuster and everything else can't stop cheaters from cheating and cracking, how can any of us indies realistically hope to stop them? I'm not saying you shouldn't take standard precautions and do as much as you feel you can, but I am saying that IMO it's a fools errand to try and defeat an entire industry all by yourself. And yes, cheating is a multi-million dollar industry. Make no mistake about it. There are "Cheat-Co's" out there that are always looking for the next game they can make some $$$ off of by cheating at it. And they aren't about to let you or I stand between them and their money just because it's our game.
I am a firm believer though that you can greatly minimize their impact on your good customers and the credibility of your game at the server side, but trying to keep them out of the client just aint gonna happen. Although nothing would make me happier than for somebody to come make me eat those statements by showing us all the way.
But just to entertain your question(it is a good one BTW) I'm pretty sure that we can agree that putting a line by line, file by file exec INTO the SSP would be a task even a newbie coud handle. The most important aspect here is that the exec is already error free, so once they were ready to ship, they could simply take their console file and use it as your template in a manner such as this....
Change this(small example)...
----------- Loading Client Scripts ------------ Loading compiled script Client/Scripts/StartupGui.cs. Loading compiled script Client/Scripts/StartMission.cs. Loading compiled script Client/Scripts/SpectatorGui.cs. Loading compiled script Client/Scripts/ServerConnection.cs. Loading compiled script Client/Scripts/ScriptDoc.cs. Loading compiled script Client/Scripts/ScreenShot.cs. Loading compiled script Client/Scripts/Recordings.cs. Loading compiled script Client/Scripts/PromoGui.cs. Loading compiled script Client/Scripts/PlayGui.cs. Loading compiled script Client/Scripts/PlayerList.cs. Loading compiled script Client/Scripts/OptionsDlg.cs. Loading compiled script Client/Scripts/MissionDownload.cs.
to this...
----------- Loading Client Scripts ------------
exec("Client/Scripts/StartupGui.cs");
exec("Client/Scripts/StartMission.cs");
exec("Client/Scripts/SpectatorGui.cs");
exec("Client/Scripts/ServerConnection.cs");
exec("Client/Scripts/ScriptDoc.cs");
exec("Client/Scripts/ScreenShot.cs");
exec("Client/Scripts/Recordings.cs");
exec("Client/Scripts/PromoGui.cs");
exec("Client/Scripts/PlayGui.cs.");
exec("Client/Scripts/PlayerList.cs");
exec("Client/Scripts/OptionsDlg.cs");
exec("Client/Scripts/MissionDownload.cs");Then comment out the directory loaders and your done. Pretty much back to normal. However, I do believe that having a directory loader is a better teaching tool in the long run, because it shows that you do not have to have every single script execing in the exact perfect order to prevent definition errors. All of us at one time or another had to deal with moving this line to this spot and exec'ing this before that, etc... So by getting into the habit of building code that is not so dependant on perfect execution, you build better code to start with and eliminate problems that really dont need or even have to exist.
There are of course always going to be those files that have to come first no matter what. Thats a given simply because you have to start somewhere. But IMO, at 4 to 6 files deep into your structure, you should be free of those limitations if you have a good solid design to begin with.
EDIT:
@ Jorgen - Gonzo also has a good eye for what battles he can win, and what battles he'll never win. ;-0
Any one man trying to fight a huge pack of predators is simply....pointless. Don't get me wrong though, I do think it is very important to do your best to lock things down. But once you start obsessing over every little detail, you've entered a self defeating mode because there just is no perfect security.
#20
If I want to make a game that I want to be moddable, will I be able to leave your AI manager in my game for the end user to mod with? (assuming commercial purchase of your pack)
This is the main area for me that I think makes it hard for a newbie to mod a game with. I want to provide a certain amount of pre-fab art they can drop in their game via the world editor creator (maybe modified slightly to be more newbie-friendly) - and having an AI editor to set paths and spawn points and behaviours would be ideal.
My game idea which I hope to get around to *starting* when I get back from America in feb/march is a cartoon type game that younger players could get into and may find fun to mod, thus I'd want to keep it as "easy" as possible.
11/20/2004 (1:10 pm)
ok, boring licence issue question here :)If I want to make a game that I want to be moddable, will I be able to leave your AI manager in my game for the end user to mod with? (assuming commercial purchase of your pack)
This is the main area for me that I think makes it hard for a newbie to mod a game with. I want to provide a certain amount of pre-fab art they can drop in their game via the world editor creator (maybe modified slightly to be more newbie-friendly) - and having an AI editor to set paths and spawn points and behaviours would be ideal.
My game idea which I hope to get around to *starting* when I get back from America in feb/march is a cartoon type game that younger players could get into and may find fun to mod, thus I'd want to keep it as "easy" as possible.
Torque Owner FruitBatInShades