Recommended Design Streamlining Programs

Started by
11 comments, last by Triba 16 years, 2 months ago
So I've been really encouraged by these forums to pursue a game design career. I'm currently aiming to create a small, demo game (the progress you can track at enigmaticog.blogspot.com) as part of my portfolio by late 2010. So I've started rationalising many areas of the demo, restricting my aims to reality and going about the whole process as if I were designing a much larger game. I'm after a program that can help me streamline some of the process - excluding the crude use of millions of word documents. I saw a program a while back floating around that databased every area of a game. It was described as being the perfect GDD as every member of the team could access it, edit it and it would universally affect the document. Does anyone know of any equivalent software? I've been investigating SVNs but haven't found anything easily accessible. Thanks
Track my game design odyssey at "enigmaticog.blogspot.com"
Advertisement
At work we use SVN, but you could look into using a Wiki. It sounds like a Wiki would give you everything you're looking for.
laziness is the foundation of efficiency | www.AdrianWalker.info | Adventures in Game Production | @zer0wolf - Twitter
I've investigated a wiki and it seems that it won't be that friendly to my programming friend. He's recommending tortoiseSVN as it's a fairly entry level SVN that I'll be able to pick up quickly. Thoughts?
Track my game design odyssey at "enigmaticog.blogspot.com"
I use TortoiseSVN at work and yes, it is a pretty easy to easy to use Windows client. You'll just need some place to setup an SVN repository. Some friends of mine and I use Assembla.com for a project we're working on. Assembla provides you with an integrated wiki, chat, SVN, and Trac, all for free! I'd highly recommend you check it out.

Honestly though, I don't think SVN is the most efficient way to manage documentation between teammates, but SVN does work fantastic for art assets/code/etc, so we just kind of use it for our documentation as well.
laziness is the foundation of efficiency | www.AdrianWalker.info | Adventures in Game Production | @zer0wolf - Twitter
My friend has just set up SVN Tortoise and I now understand the commands (I can learn fast). I have a password, username etc and a full server. It looks like a fantastic app. I think for documentation to succeed I'll need to be incredibly frugal and organisationally sound. It's like having our own personal superhighway - I'm new to this so I'm easily impressed. He's informed me that there are far more complex available options but I'm pretty chuffed with this one and it appears to suit our purposes well. Thank you zer0wolf.
Track my game design odyssey at "enigmaticog.blogspot.com"
One thing, I don't understand how you organise such a large quanitity of data. What file structure/programs do you use to arrange it in a way thats easily navigable?
Track my game design odyssey at "enigmaticog.blogspot.com"
You'll need to be a little more specific on what you're referring to when you say data. I think you're just asking about a basic file hierarchy?

We do something like:
art
audio
code
design
tools
etc

Within design we do have something along the lines of:
archive
designdocuments
flowcharts
manual
spreadsheets
storyboards
etc

Is this what you're looking for?
laziness is the foundation of efficiency | www.AdrianWalker.info | Adventures in Game Production | @zer0wolf - Twitter
Quote:Original post by Triba
I've investigated a wiki and it seems that it won't be that friendly to my programming friend. He's recommending tortoiseSVN as it's a fairly entry level SVN that I'll be able to pick up quickly. Thoughts?


If you were originally talking about "millions of word documents", then a Wiki is a perfectly good replacement for that. What does your programmer have to do with it? If, on the other hand, you are looking for something to store source code or game assets in, then a Wiki is not the right tool, but that isn't really the decision that a game designer would typically make. So, as Zer0wolf said, you'll have to specify exactly what you're after here.

Also, if using a Wiki for game design, use it for the original design - don't use the ability to change a Wiki as an excuse to keep altering stuff as you go along, causing all kinds of trouble for your programmers.

And... a small, demo game shouldn't take you 3 years to complete. Either you have almost zero free time, or you are aiming too high despite saying 'small'.
zer0wolf: That's exactly what I was after - thank you.

Kylotan: I'm using the integrated assembla package and it appears to have everything we need. I should explain - my programming friend and I are both learning. We have a relationship where we both try and assist each other in whatever project we are working on. As this is fairly new territory for me, I like to be extra cautious that I'm not inhibiting him or, finding out at the end of the day that we need to convert something or re-do a lot of documentation because I've used the wrong system. As such, we're taking things fairly slowly. In terms of the 3 year goal, I set that not knowing how long the whole process takes. It is not an informed decision, but the best I can make without undercutting the whole project. I'm also giving us time as I am taking a gap year overseas, and won't have an enormous amount of time for the project between March and November this year. In terms of ambition, we would like to have a demo that resembles a World of Warcraft Alterac Valley battleground (if that's any help), complete with about 10-15 different animated models as well as a non-animated environment etc.

At the moment, the biggest worry for the whole thing is the 3d modeling and rigging. I have a very crude knowledge of 3dsmax and zbrush so I'll either need to brush up exponentially or convince other people. I would be really glad if you guys were able to give me pointers and so forth on the whole process. I've set up a blog at enigmaticog.blogspot.com which ill use to document the whole process.

Again, as it is a whole set of new experiences, I will inevitably make mistakes, but the more I learn the better.

EDIT: I'm approaching the wiki cautiously, writing pages that I believe are secure in do-ability, logic and function. If you would like to have a look I'll message you an account.

Additionally, do you have any links that would inform me regarding work order? I would like to know, as the "designer" the order in which tasks should be assigned and the game should be built.
Track my game design odyssey at "enigmaticog.blogspot.com"
Quote:Original post by Triba
Kylotan: I'm using the integrated assembla package and it appears to have everything we need.


Ok, that seems like a cross between a content management system and an issue tracking system. That's more for game production than game design, though obviously it all ties together in some form.

Quote:In terms of ambition, we would like to have a demo that resembles a World of Warcraft Alterac Valley battleground (if that's any help), complete with about 10-15 different animated models as well as a non-animated environment etc.


No, it doesn't mean anything to me, but a small section of a massive game is still a massive game. It's like thinking that creating a child in a laboratory is easier than creating an adult, just because it's smaller. Although you have less content to produce (anims, textures, models, etc), you have exactly the same amount of functionality to produce (networking, persistence, rendering, combat, skills, input, GUI, sound, physics, etc). My opinion is that you should be aiming for a simpler game.

Quote:Additionally, do you have any links that would inform me regarding work order? I would like to know, as the "designer" the order in which tasks should be assigned and the game should be built.


The book 'Game Architecture and Design' by Rollings and Morris has some good hints on this. But essentially I'd say that you need to identify the areas of gameplay, speak to your programmer about how that maps to technical requirements, decide how long each one will take and which ones are therefore considered high-risk, and do those first. Unfortunately making accurate estimates of these tasks is almost impossible without experience. This is another reason why people suggest you start with smaller games first.

This topic is closed to new replies.

Advertisement