Deployment

#1 Just use your favorite installer app. I prefer Inno Setup (www.jrsoftware.org/) myself.

#2 Thanks Tom. You kinda missed my point because it is such a simple question. I meant, what lies on your filesystem when you have finished your game? I have the torque stuff installed on my HD right now but there is a bunch of stuff in there i wouldn't want to distribute (like the demo). I heard that the script gets compiled to bytecode. So how does it all fit together?

Cheers :)

#3 Notice there is a .dso for almost every torque script file. The .dso is the compiled version of the script. In theory (because i haven't done this) you can ship only the .dso files and the game should run.

#4 There are also some scripts in your /install directory that can be modified to handle a variety of tasks. My lead developer (Greg McLean) did some magical stuff in just a day or so using those scripts as a basis.

To summarize what he did, you need to know that we actually have broken the TGE "package" down into several repositories: client-environment, server-environment, engine, art, audio, docs, etc. When we are ready to package up a release (internal to team right now only) we use our repository's capabilities to "tag" a specific set of matching revisions across all the repositories, such as "milestone_1".

The install script was enhanced to:
1) checkout the correct tagged repositories as local working copies in a staging area.
2) Configure and build the dedicated server executable.
3) Configure and build the linux client executable.
4) Configure and build the windows client executable (cross platform compilation via mingw libs)
5) use bitrock (mentioned in the install scripts in TGE) to package the client environment, art environment, audio environment, and recently compiled executable for the two target client platforms.

At this point, we can simply start up the dedicated server, and send the self-extracting executable bitrock put together to our team and we're good to go.

I don't want to trivialize the tasks above--it took us several months simply getting the repositories set up, and Greg is a linux (and scripting) guru, but I did want to point out that the /install dir in your TGE has some pretty good starting points in it.

#5 Thanks guys. This is helping a lot.
So what would you have on your filesystem for a game that was about to be deployed? The engine, .dso files and others? What about artwork? Are they in a directory for all to see? What about the mission editor? Is that removeable?

Sorry if these are lame beginners questions but there doesn't seem to be anything written about this sort of thing!

Cheers.

PS: Stephen, your environment sounds ideal!

#6 It's kind of sad that message boards in general are getting so bad that people feel they need to apologize for a question.

You really don't need to do that here. As long as your polite and specific, people are always willing to answer.

It helps if your grammar is ok and you don't go gangbusters on your questions.

There's good people here Lea. I hope you enjoy your stay!

#7 @Lea: thanks, and thank the heavens for a linux guru on the team, hehe.

One of the reasons that this isn't a topic easily searchable (or even discussed) is because you are in some ways going about things a little backwards, as it were. Putting together a distro package relies on a ton of knowledge that you gain simply by general experience working with the engine.

If you haven't found it already, the book 3D Game Programming All In One by Ken Finney is without a doubt the best place to start learning about TGE. It is available here on Garage Games (order from Amazon) although the link escapes me right now!

#8 @Stephen: I have it already, but it's geared more towards windows. It also talks about injecting scripts into the engine from the command line. Surely a distributed game doesn't do this?

#9 Ye ask the questions how stupid they ever are.
Im not a englishspeaking guy and sometimes its really hard to translate exactly what you want to ask.
But i ask anyway ,and hope there are some nice guys to answer my stupid questions.

Cheers.

-Billy

#10 Correct, the book is a "Learning Torque" tool, not a "release a game made with TGE" tool :)

I would suggest that you learn more about how TGE works in and of itself, and table the "package a distro" task until you've gained a bigger working knowledge of TGE. It will come, just sometimes more slowly than you might wish (TGE is a lot of stuff to learn!).

There are also some threads floating about (some recently active) regarding the task as well. At the top of the web page here, there is a small search bar--you may try some intuitive keywords and select the "forums" category and see where that leads you. I tried it with just "packaging" and got about 8 pages of message threads, some useful, some not.

#11 Thanks for all the tips guys. I'm slowly coming through that "er....." stage :)

#12 Charlie M, I don't think this board is that bad, is it??

#13 I fully believe in the motto:

The only "stupid" questions are those that aren't researched first, and after researched, not asked.

Researching TGE topics on the forums (especially complex ones that you can't search with a keyword or two) can be very difficult. Sometimes I've spent 2+ hours searching through 25 pages of forum messages, and then another 2+ hours searching for appropriate keywords within the source code itself ("Search In Files" is a must have IMO!), only to come to the boards and then have it answered simply and concisely.

The thing is, if you don't do the research first, not only may you not understand the answer, but you may tend to be categorized as a "Boy who cried Wolf" type of poster, and tend to have the experienced forum members (and therefore the ones that probably have very little time to research answers) tend to not spend the time to answer your question well.

#14 @Stephen: How are your linux/windows cross compile experiences?

#15 Using linux as the build/compile enviroment, pretty seamless. It took some interesting makeFile changes to use the correct libraries, and possibly some other things that I don't know about (Greg did it!), but once it was compiling, it worked like a champ--never did have any (detected) issues with using a Windows client that was compiled on the linux platform.

We've not gone the other direction, and actually don't use the cross compilation for normal development, only for release, but it was basically transparent to the user.

Not sure I would attempt it without pretty strong understanding of POSIX compliant makefiles, as well as good understanding of compilation and linking. I know that I personally would have been very frustrated setting it up, and Greg ran into some issues for a while that he was able to overcome.

#16 @Lea> Very good question! As a 14-day-Torque user myself, I too was wondering what the options for deployment were. I haven't found any Info about that yet.

I think this is a very important question (not only) to newbies, because you don't want to spend all the hours learning a SDK that - in the end - wouldn't live up to your expectations.

Maybe I should state, that in general I don't have that feeling with Torque. Learning Torque is very exciting and so far it seems very powerful and complete! I just hope this goes sound and deployment, too!

I have to say, I am a little nervous about it's sound engine. My testing wasn't so successfull, and I am missing a few options! But I am still waiting for the All-in-One book to arrive, maybe this is going to solve all my problems, just like Dr. Pepper's promise ;)

#17 Deployment issues:

1) Yes, you can delete all your .cs scripts and just leave the .dso files. If you want your game closed source this is a must. Very easy.

2) Taking out the mission editor. Yes this can be done, but is a bit more complicated. As it ships the mission editor pops up when you hit a certain key. Changing the key binding is something you can do with script alone. Going a bit deeper, you could remove the mission editor from the c++ code also. I'm not sure how secure this is. I have a feeling that another Torque SDK owner who tried hard enough could find a way to edit the missions by moving some files into another copy of Torque.

3) You artwork is easily available to any player. It is very easy to go into the right folder and copy it out. I don't know any way to change this. It's easy to protect your source code. Not so easy to protect art.

#18 Why no just do a simple encrypt/decrypt on all the files (dso, artwork, etc) in C++, hook this into the main engine for file reads? Probably the hardest bit will be to remove the editors directly from the code, but if there is no binding to them then they wont work directly anyway.

Has anyone tried this?

#19 Just as an FYI, the specific question of "protecting" your files has been addressed many many times throughout the years here at the GG community, and there are a lot of posts that go over specific reasons why/why not, and techniques.