Project leader looking for general advice...
by Chad Freseman · in General Discussion · 07/09/2006 (7:10 pm) · 14 replies
As brief as I can make it here...
I have spent 8 years designing an RTS game. I finally completed the design, and began forming a demo team in May 2006.
We are using
Torque 1.4
The RTS Starter Kit converted for 1.4
Studio Max with the DTS exporter
I am not a programmer by any means but I was able to do the conversion and add my interface graphics/buttons, but anything since then we have been stuck.
We have 4 programmers (three are college graduates), one modeler and a few 2D artists (and looking for more, but that's not what this post is about). No one has experience with Torque so the programmers have been working towards becoming familiar with it.
It's a strange dynamic, having an engine (which obviously is a huge leap forward), but yet not being able to produce anything to keep up the morale of the team.
My questions...
Is it typical that when using Torque that there is like this initial hump of understanding, that once past, things proceed more smoothly?
How does a team typically organize the code work done? Like, should all work done be sent to one member who updates their working folder, then distributes that folder to the rest of the team? How have you organized these issues?
What can I do in the future to attract programmers to the team that are familiar with Torque?
Any advice some of you have from your experiences with Torque would be great. Feel free to ramble on about your experiences with Torque; anything would be helpful. If you feel that you have the time and could chat on msn msg or aim, that would be awesome too.
www.glhfgg.com info about me can be found on the contact page along with two demo songs.
Take care ya'll,
Chad
chad (at) glhfgg.com
I have spent 8 years designing an RTS game. I finally completed the design, and began forming a demo team in May 2006.
We are using
Torque 1.4
The RTS Starter Kit converted for 1.4
Studio Max with the DTS exporter
I am not a programmer by any means but I was able to do the conversion and add my interface graphics/buttons, but anything since then we have been stuck.
We have 4 programmers (three are college graduates), one modeler and a few 2D artists (and looking for more, but that's not what this post is about). No one has experience with Torque so the programmers have been working towards becoming familiar with it.
It's a strange dynamic, having an engine (which obviously is a huge leap forward), but yet not being able to produce anything to keep up the morale of the team.
My questions...
Is it typical that when using Torque that there is like this initial hump of understanding, that once past, things proceed more smoothly?
How does a team typically organize the code work done? Like, should all work done be sent to one member who updates their working folder, then distributes that folder to the rest of the team? How have you organized these issues?
What can I do in the future to attract programmers to the team that are familiar with Torque?
Any advice some of you have from your experiences with Torque would be great. Feel free to ramble on about your experiences with Torque; anything would be helpful. If you feel that you have the time and could chat on msn msg or aim, that would be awesome too.
www.glhfgg.com info about me can be found on the contact page along with two demo songs.
Take care ya'll,
Chad
chad (at) glhfgg.com
#2
Thx
Chad
07/09/2006 (9:26 pm)
Ya, I should have mentioned that I bought that, I have had it a week now. I have offered to the rest of the team if they feel they need it I will purchase it for them.Thx
Chad
#3
But yes, once you get over that daunting obstacle of starting out, you should be smooth sailing with small bumps along the way.
---
As for code, really it's up to you what you feel will work best.
Your coders will likely know the best way to go about things.
Focus on one section of coding first, "OK I want this character to fly in the air and explode when he dies, so let's get the coder to get this working ingame."
Then once that's all good, focus on something else "Ok now let's code how this gun works on a certain enemy." Just organize all the aspects of your game.
In a sense, code the game as if you were playing through it, only developer style... Over time things will become a flow, and you'll get everything working.
I highly suggest planning the entire game out on paper first. Level designs, ideas, mission briefings, EVERYTHING. Write your game on paper before you get into the coding stuff. It will be a hell of alot easier on you when you know what you are trying to accomplish.
---
Not only will promotional videos and screenshots attract customers, it will raise the attention of some potential team members.
Most people here want to be part of a dead-serious project, and if they see how far your game has come and know you are a serious person, they will want to jump on the wagon and go for the ride as well.
07/09/2006 (10:36 pm)
A good start is half the challenge, getting it done is the other half.But yes, once you get over that daunting obstacle of starting out, you should be smooth sailing with small bumps along the way.
---
As for code, really it's up to you what you feel will work best.
Your coders will likely know the best way to go about things.
Focus on one section of coding first, "OK I want this character to fly in the air and explode when he dies, so let's get the coder to get this working ingame."
Then once that's all good, focus on something else "Ok now let's code how this gun works on a certain enemy." Just organize all the aspects of your game.
In a sense, code the game as if you were playing through it, only developer style... Over time things will become a flow, and you'll get everything working.
I highly suggest planning the entire game out on paper first. Level designs, ideas, mission briefings, EVERYTHING. Write your game on paper before you get into the coding stuff. It will be a hell of alot easier on you when you know what you are trying to accomplish.
---
Not only will promotional videos and screenshots attract customers, it will raise the attention of some potential team members.
Most people here want to be part of a dead-serious project, and if they see how far your game has come and know you are a serious person, they will want to jump on the wagon and go for the ride as well.
#4
I suggest you and your staff employ some source code control if you havnt done so (id go for subversion as a free solution).
Implement some kind of notifaction with your SCC system and myabe knock up a little bug/task tool so everybody knows everybody elses goals and activitiy.
Good Luck!
07/09/2006 (11:15 pm)
Chad, absolutely. That hump is definatly normal and can be quite tough to get through.I suggest you and your staff employ some source code control if you havnt done so (id go for subversion as a free solution).
Implement some kind of notifaction with your SCC system and myabe knock up a little bug/task tool so everybody knows everybody elses goals and activitiy.
Good Luck!
#5
There's a significant learning-curve to Torque, and i don't know of many shortcuts around it.
Basically it just takes a while to wrap one's head around the notion of having clients and a server, and on top of that of having the clients and the server executing the same code but on different simulations !
If your game is networked, i advise making it S.O.P. for the developers to run the client and server as actual separate instances. That will tend to clarify things sooner rather than later. I blah-blah about it here.
Again echoing Westy, definitely set up a Revision Control system such as subversion. Even for solo projects it's an invaluable tool and makes life easier for programmers and artists alike. Subversion specifically seems quite good; we've got a team of twenty or so programmers & artists using it heavily with very few problems. The value of having a central repository with definitive versions of assets & code is huge, and for certain bugs which inevitably come up, having the entire revision history of the project is basically critical. For example suppose an obscure bug was introduced a month ago, but for whatever reason was only discovered today. Hopefully you can debug it directly, but every now and then the direct-debugging approach will mean days of work. Enter revision control, which allows you to divide-and-conquer back thru the history of the project and find exactly which change is the culprit. Hours of work instead of days. Invaluable.
anyhow.
good luck,
use the forums,
buy the team root-beer.
07/10/2006 (12:42 am)
As Westy said, absolutely.There's a significant learning-curve to Torque, and i don't know of many shortcuts around it.
Basically it just takes a while to wrap one's head around the notion of having clients and a server, and on top of that of having the clients and the server executing the same code but on different simulations !
If your game is networked, i advise making it S.O.P. for the developers to run the client and server as actual separate instances. That will tend to clarify things sooner rather than later. I blah-blah about it here.
Again echoing Westy, definitely set up a Revision Control system such as subversion. Even for solo projects it's an invaluable tool and makes life easier for programmers and artists alike. Subversion specifically seems quite good; we've got a team of twenty or so programmers & artists using it heavily with very few problems. The value of having a central repository with definitive versions of assets & code is huge, and for certain bugs which inevitably come up, having the entire revision history of the project is basically critical. For example suppose an obscure bug was introduced a month ago, but for whatever reason was only discovered today. Hopefully you can debug it directly, but every now and then the direct-debugging approach will mean days of work. Enter revision control, which allows you to divide-and-conquer back thru the history of the project and find exactly which change is the culprit. Hours of work instead of days. Invaluable.
anyhow.
good luck,
use the forums,
buy the team root-beer.
#6
Just make sure no-one checks in any work that doesn't compile, or isn't tested.
07/10/2006 (1:34 am)
Quote:Like, should all work done be sent to one member who updates their working folder, then distributes that folder to the rest of the team? How have you organized these issues?Use CVS, or SVN.... together with Tortoise that's really easy to use. I'm using Tortoise SVN btw.
Just make sure no-one checks in any work that doesn't compile, or isn't tested.
#7
but another option here is to use something like cruise control to automatically do a build whenever stuff is checked in, and email the team the results of the build.
it takes a while to set up tho, and for a smallish team is probably not worth the effort.
07/10/2006 (8:30 am)
It's probably more than you need at this time,but another option here is to use something like cruise control to automatically do a build whenever stuff is checked in, and email the team the results of the build.
it takes a while to set up tho, and for a smallish team is probably not worth the effort.
#8
Anton, I greatly appreciate the time you took last night for our conversation.
I have been looking at "Subversion" and "Cruise Control" thanks for pointing me towards these applications.
I am directing my team to read this thread so they can get some perspective on how things go with Torque.
Thanks again everyone!
Chad
07/10/2006 (11:53 am)
Thanks everyone for the feedbackAnton, I greatly appreciate the time you took last night for our conversation.
I have been looking at "Subversion" and "Cruise Control" thanks for pointing me towards these applications.
I am directing my team to read this thread so they can get some perspective on how things go with Torque.
Thanks again everyone!
Chad
#9
I am pretty much in the same boat you are, with one extra advantage I am an experienced programmer (not games though, this is kind of the black arts of coding :), I like it here).
For our project we have the added difficulty of no central office to work from, so I have setup an SFTP and SSH solution to basically have a secured FTP server with a checkout system, so if I am working on a file I can lock it, that way if someone else tries to play with it they are notified that it is being edited by me, and to try to get that file later, then just a subfolder system everday creates a new folder and copies the previous day, a basic version control system and version history.
I would be happy to help in anyway I can, feel free to msg or email me.
The Trusted One
07/10/2006 (10:37 pm)
Chad,I am pretty much in the same boat you are, with one extra advantage I am an experienced programmer (not games though, this is kind of the black arts of coding :), I like it here).
For our project we have the added difficulty of no central office to work from, so I have setup an SFTP and SSH solution to basically have a secured FTP server with a checkout system, so if I am working on a file I can lock it, that way if someone else tries to play with it they are notified that it is being edited by me, and to try to get that file later, then just a subfolder system everday creates a new folder and copies the previous day, a basic version control system and version history.
I would be happy to help in anyway I can, feel free to msg or email me.
The Trusted One
#10
07/10/2006 (10:41 pm)
Why not set up a VPN and use an off-the-shelf source control system ?
#11
Short answer I am a coder, I like doing it myself, also VPN is overkill when all I needed was simple file sharing.
besides my Cisco router does some funky shit with VPNs.
The Trusted One
07/10/2006 (10:45 pm)
@Orion,Short answer I am a coder, I like doing it myself, also VPN is overkill when all I needed was simple file sharing.
besides my Cisco router does some funky shit with VPNs.
The Trusted One
#12
i'm a coder too, and if there's one thing i appreciate as a coding tool it's robust revision history.
being able to easily roll back to last week's or last month's version of the codebase, or easily see the changes made between say last thursday and today, or review the changes made by maybe an as-yet-unproven member of the team, those are invaluable.
actually you don't need a VPN to set up a revision control system such as SVN,
so i guess i should take back my whole VPN thing.
but still, free, off-the-shelf, rigourously tested, etc, it's hard to go wrong.
07/10/2006 (10:56 pm)
Hiya -i'm a coder too, and if there's one thing i appreciate as a coding tool it's robust revision history.
being able to easily roll back to last week's or last month's version of the codebase, or easily see the changes made between say last thursday and today, or review the changes made by maybe an as-yet-unproven member of the team, those are invaluable.
actually you don't need a VPN to set up a revision control system such as SVN,
so i guess i should take back my whole VPN thing.
but still, free, off-the-shelf, rigourously tested, etc, it's hard to go wrong.
#13
Thanks for your help guys :)
The Trusted One
07/10/2006 (11:04 pm)
I will take a look at the source control meathods listed here.Thanks for your help guys :)
The Trusted One
#14
Thanks guys for the advice.
I have created a subversion repository with tortoise shell.
The ability of a revision history to point out modified files came in very handy today while tracking down some confusion over .cs and .cs.dso
lates,
Chad
www.glhfgg.com
08/14/2006 (6:05 am)
*update*Thanks guys for the advice.
I have created a subversion repository with tortoise shell.
The ability of a revision history to point out modified files came in very handy today while tracking down some confusion over .cs and .cs.dso
lates,
Chad
www.glhfgg.com
Torque Owner Anton Bursch
The Game Programmer's Guide to Torque
This should be the first and will be the most important step you will take learning to develop with the Torque Game Engine. It's fast, it's up to date, it's easy to understand. It's $55 and it's more than worth the year you'll save yourself trying to learn this on your own.