Loading Datablocks and Script from databases!!!
by Vince Gee · 02/01/2006 (7:48 pm) · 6 comments
Well,
I know I've been gone a long time, got tied up on a project that went no where really... but enough of that...
I've been rather busy for the last week working on something that I feel is very important to game builders.
The problem I've found w/ team development is that someone wants to modify something in a script file but the script file is checked out by someone else. Fustration sets in and pep's get angry. So, after getting the ODBC plugin working for TGE I built this nifty app :)
I call my lil creation GOM for the Game Organization Manager. This is just the first step of gom, right now I am in the process of taking all the scripts from the server/scripts folder and putting them into the database. Once I get the game to start up correctly and work the bugs out, I'm going to put together a resource for using GOM to persist game states etc, prolly a small mmo will come first.
One other nifty function of GOM will be the ability for it to generate the script files directly as well as parse existing scripts and load them into the database.
Think about it, a member of the team wants to modify a particle effect, they fire up the GOM app (will be webbased as soon as I get time) and edit the config, fire off a remote restart of the server and it loads the new data up.
Mainly I'm doing this because I get tired of searching through the torque script looking for functions, w/ this tool I can just navigate the tree to the function I want and edit it :)
The only current downside is that I'm building this for Microsoft only atm, I'm trying to use straight SQL where I can so that it should work w/ mysql w/ minor changes.
But hey it works! I'm able to spin up the game and the crossbow loads up and the scripts work!
Vince
I know I've been gone a long time, got tied up on a project that went no where really... but enough of that...
I've been rather busy for the last week working on something that I feel is very important to game builders.
The problem I've found w/ team development is that someone wants to modify something in a script file but the script file is checked out by someone else. Fustration sets in and pep's get angry. So, after getting the ODBC plugin working for TGE I built this nifty app :)
I call my lil creation GOM for the Game Organization Manager. This is just the first step of gom, right now I am in the process of taking all the scripts from the server/scripts folder and putting them into the database. Once I get the game to start up correctly and work the bugs out, I'm going to put together a resource for using GOM to persist game states etc, prolly a small mmo will come first.
One other nifty function of GOM will be the ability for it to generate the script files directly as well as parse existing scripts and load them into the database.
Think about it, a member of the team wants to modify a particle effect, they fire up the GOM app (will be webbased as soon as I get time) and edit the config, fire off a remote restart of the server and it loads the new data up.
Mainly I'm doing this because I get tired of searching through the torque script looking for functions, w/ this tool I can just navigate the tree to the function I want and edit it :)
The only current downside is that I'm building this for Microsoft only atm, I'm trying to use straight SQL where I can so that it should work w/ mysql w/ minor changes.
But hey it works! I'm able to spin up the game and the crossbow loads up and the scripts work!
Vince
About the author
www.winterleafentertainment.com
#2
02/02/2006 (5:00 am)
Really nice work mate!
#4
02/02/2006 (10:09 am)
Nice. I will definatley look at this in development. Keep up the good work! 
#5
if changes are really major programmers should probably be working in a sandbox or different branch.
advantages is they wont break each other and you can have versioning, downside you have to merge
the files.
with the DB unless you have different instances, someone could change something that breaks everyone in the project. hard to do versioning, hard to sync to a different version of the datablocks if your only storing
the latest version in the DB tables.
interesting resource though and could be very handy but im not sure its a solution for the source code control "problem", probably good for small projects with few people on it though. nice job either way!
02/02/2006 (11:59 am)
hmm curious why someone having a script file checked out would cause a problem. If using perforce for example unless they have it in exclusive lock mode you too can check it out and modify it.if changes are really major programmers should probably be working in a sandbox or different branch.
advantages is they wont break each other and you can have versioning, downside you have to merge
the files.
with the DB unless you have different instances, someone could change something that breaks everyone in the project. hard to do versioning, hard to sync to a different version of the datablocks if your only storing
the latest version in the DB tables.
interesting resource though and could be very handy but im not sure its a solution for the source code control "problem", probably good for small projects with few people on it though. nice job either way!
#6
Vince
02/02/2006 (5:00 pm)
Well, like that guy at the other link said, even though it's doable it isn't practical... I'm gonna scrap the project and move onto greener pastures..Vince
Torque Owner Vince Gee
WinterLeaf Entertainment