Web Deployment...is it working yet?
by Hallsofvallhalla · in Torque 3D Professional · 03/25/2010 (7:09 am) · 126 replies
Weird my first post disappeared.
When I deploy a web game it creates a exe(110 meg for a simple terrain and two vehicles) and that exe must be downloaded by players and played from their local machine. That is not web deployment. Am I doing something wrong? There is no way having to install a large file is web deployment. It is suppose to be streamed from the host.
The main reason for my purchasing T3D is for the web deployment so I hope I have just done something wrong.
When I deploy a web game it creates a exe(110 meg for a simple terrain and two vehicles) and that exe must be downloaded by players and played from their local machine. That is not web deployment. Am I doing something wrong? There is no way having to install a large file is web deployment. It is suppose to be streamed from the host.
The main reason for my purchasing T3D is for the web deployment so I hope I have just done something wrong.
About the author
Been in game design for about 4 years now. Some of my titles are Forsaken sanctum 3d mmo and a web browser mmorpg. Urban Realms - WB mmo. Planetary Wars - WB mmo. Quests Of Crocania WB mmo. also teach tutorials on Web Development.
#122
One approach I was thinking in this regard is to have everything be database driven even on a client. So the level for each mission will be constructed at runtime. If it is database driven then it would be plausible for the assets to be known beforehand. The trick would be taking an edited level and distilling it down to database entries and references to art assets. Once that is determined the art assets could be packaged automatically into a zip file and used from the file at runtime. There may be issues with avatars and the like, but some of that could be streamed.
12/31/2011 (4:13 pm)
This is an interesting topic! One approach I was thinking in this regard is to have everything be database driven even on a client. So the level for each mission will be constructed at runtime. If it is database driven then it would be plausible for the assets to be known beforehand. The trick would be taking an edited level and distilling it down to database entries and references to art assets. Once that is determined the art assets could be packaged automatically into a zip file and used from the file at runtime. There may be issues with avatars and the like, but some of that could be streamed.
#123
01/01/2012 (5:41 pm)
Driving everything through a database makes it very hard to work with a source control system.
#124
The script does not have to be in the database. I was thinking that the assets would be managed this way. Not the script source.
What were you thinking in this regard? Yes, I did say everything, but I meant art assets.
01/01/2012 (6:32 pm)
@Matt,The script does not have to be in the database. I was thinking that the assets would be managed this way. Not the script source.
What were you thinking in this regard? Yes, I did say everything, but I meant art assets.
#125
Generally, the type of info that you see stored in a database for a game is going to be stats and saved data that a designer might want to be able to quickly tweak in a "spreadsheet" style layout (like balancing enemy stats or player level progression).
However, if you are using a local database with a binary format, it is really easy for more than one person to "stomp" the changes of another. Or, if you are using an online database, you can have trouble preserving historical information about who changed what and when and what the previous value is.
There are ways around these issues but they do add an additional layer of complexity and discipline to your processes.
01/01/2012 (7:53 pm)
With Constructor we stored all of our "data" in a local database and ended up having severe conflict issues with Subversion (since the database data is binary) if one person went to change the order of the items in the menu the same time the other developer added a new one (for example).Generally, the type of info that you see stored in a database for a game is going to be stats and saved data that a designer might want to be able to quickly tweak in a "spreadsheet" style layout (like balancing enemy stats or player level progression).
However, if you are using a local database with a binary format, it is really easy for more than one person to "stomp" the changes of another. Or, if you are using an online database, you can have trouble preserving historical information about who changed what and when and what the previous value is.
There are ways around these issues but they do add an additional layer of complexity and discipline to your processes.
#126
Thanks for the explanation.
I was not really thinking about storing information for development. I was thinking more of a packaging tool for assets for web deployment. Everything can stay in the regular directories for development, testing, etc. Then when a package is needed for deployment or testing of the web interface a script would parse the assets for a particular level and generate a level asset: with a database, art files, and possibly additional scripts. The database would just show how to assemble the assets. On second thought, you could just do that with the mission file, so maybe the database is not needed. Maybe I am not understanding the problem in the first place.
01/02/2012 (7:57 am)
@Matt,Thanks for the explanation.
I was not really thinking about storing information for development. I was thinking more of a packaging tool for assets for web deployment. Everything can stay in the regular directories for development, testing, etc. Then when a package is needed for deployment or testing of the web interface a script would parse the assets for a particular level and generate a level asset: with a database, art files, and possibly additional scripts. The database would just show how to assemble the assets. On second thought, you could just do that with the mission file, so maybe the database is not needed. Maybe I am not understanding the problem in the first place.
Torque Owner Gerald Fishel
Development Ninja