me and my friend have decided to make an XNA game for the 360. now i have a good year of use with the 3d application blender and he is able to make a good sidescroller. we have 3 beginners wanting to join in as well. now i would like to ask 1: is there any sort of pipeline we should follow since i have only made short animations i have no idea were we need to start or were we need to be in a week. 2: is there any suggestions on equipment or engines or software? any more tips would be useful as well. i have done a lot of searching and googling but i still find the best way to get answers is to ask people who know about this stuff. thank you for your time and replys. =)

I dont want to come off sounding mean but your post may not get that many replies because it sounds like your trying to make a game with no experience. Heres why:

You said you have a year of using blender. Do you know how to program?

You said your friend can make a good side scroller, does he program or did he make it in a game maker?

Also you said you have some animations, but did you guys create a design doc or anything? Do you have a full game laid out on paper before you start to create in the computer?

Fill in these blanks and I bet youll get some more responses :)

well i have almost no programing experience ( really basic c++ and a basic knowledge of blenders internal game engine).

but im not going to be programing my friend is a programmer and did make a side scroller out of code so i assume that means he knows his stuff

im not quite shure what you mean by a design doc but if you mean pre plan well yea sort of i guess, i mean i usually just do them for fun. and we have some pre production floating around (ideas, concept, ect.)

i know this is kinda outa our league but we know this is going to be hard. but its a learning experience and we just want some idea of what we need to do and some tips on how to do it. any tips would help

Well, it’s kinda hard to answer something this broad. The only advice I can give you right now is invite someone who knows what to do into your team.

For answering you first question, I can give a small and fast guide-line for what to do now. It’s not prefect and not completely correct but it’s a start:

1- Make a Game Design: write every detail that you will need for the whole game. I’m talking about everything from menu textures to character’s and enemy’s locations and attributes. Google for a game design document that has a format that you can work with and fill it in. You don’t have to write all the details all at once. But at least write enough details to start making the game.

2- Assign Positions: depending on your design you will need members to handle specific jobs and tasks. A general format for positions is designer(s) [game designer, gameplay designer, characters and NPC designer, level designer, etc…], artist(s) [concept artist, 2D artist, 3D artist, writer(s), composer(s), etc…], and programmer(s) [Game programmer, graphic programmer, AI programmer, physics programmer, script programmer, network programmer, etc…]. it’s not a problem is member takes more than one position.

Designers and artists can work hand to hand with their tasks. For example, artists can draw concept art for the game, scenery, and characters that can help the designers to visualize their ideas instead of just having them on text.

You should always have a project leader to assign jobs and tasks, and to make sure that everyone is doing ok. If you have more than one member assigned to a position, then you one of them should be assigned to be lead. Example: a lead-programmer, lead-artist, lead-writer, etc…

3- Make dead-lines: I know that nobody likes to be pressured with dead-lines, but it may be necessary if you don’t want the project to take 10 years to finish :P. At least select a reasonable date to finish an alpha, beta and a demo.

4- Depend on each other: Everyone in the team can handle his job and know what they are doing. Don’t be shy to ask for idea and how things work. You don’t have to carry all the burdens on your shoulders. Work as a team. COMMUNICATE. SHARE KNOWLEDGE.

---

Well, this is what I have. Just put in mind that this will probably take a long time to finish. So hang in there.

As for your second question, any member can use whatever tool and program he likes. Just make sure that each member selects a tool that the rest of the team can work with. For example, there is no point if the modeler makes meshes in a format that the programmer can’t load in his engine.

Anyway, it’s not going to be easy, but it can be really fun if you wanted it to be.

A small advice for managing your team: show off your work. If you finish a picture, show it to the team. If you finish a level, show it to the team. If you make an effect, show it to the team. It’s easier to keep the team members interested if they see that there is progress.

Hope this helps, and good luck.

wow that was great thanks a lot =) !!!! ummmm just a few questions because oviosly my and my group need to get a lot of the kinks worked out before any real production

Ogre, weve been looking at it and as far as capability's and difficulty how is it to work with it if anyone has had experience with it?

now with compatibility and transferring models how does that work exactly? i mean if i have a character model that is fully rigged and has a walking and jumping animation and a basic world (flat plane or what have you). now would that be compatible with ogre and c++ (like i said im not a programmer so if this sound like a stupid question hang in there with me plz) and if so do i just import then leave the rest to the programmer? plz give me a basic rundown of the steps just so i know what to work with

and again thanks so much Farraj and Chrono1081

I see this thread, and recalled some old memories of a failed project...here’s what you don’t want to do.

Quote:we have some pre production floating around (ideas, concept, ect.)

Don’t walk around with some ambitions floating ideas. You need to have a firmly defined goal in the end. Enough to differentiate your game from generic game XYZ. If you have a side scroller, then you need to have enough details for someone to have a generic idea of how it’s different from the Mario games or whatever. You don’t need every detail fleshed out. But you need to a constant, fixed idea of exactly what your game achieves.

Now, I’m going to bash Farraj’s post. I think his advice is a bit inappropriate for your group. Sorry Farraj.

Quote: Make a Game Design: write every detail that you will need for the whole game.

Don’t even bother with this. You’ll spend countless hours waxing about the various details of your game, that won’t truly help in actual programming. You have a far off goal, now make a small milestone that helps towards the goal. A side scroller? Well, your first goal might be, create a part of the gameworld. Literally, all you might have is a sky and ground. And view this absolutely monotonous and bland scene. But that’s a milestone, because to get there, you need to have established so many things. Then your next milestone might be to have various objects in the gameworld. And then a player. Then control the player. Somewhere along the way, you have to be able to save and load the game. These are milestones for your group.

Small milestones forces you to start thinking about details that really matter. EDIT: What I mean is that large game designs that encompass every aspect of the game is going to fail. Small milestones mean small manageable and incremental designs. You still need to flesh out the details eventually.

Quote: Assign Positions: depending on your design you will need members to handle specific jobs and tasks.

Don’t even waste your time on this. I can tell you precisely what’s going to happen. The more skilled programmer on the team is going to be frustrated in trying to get all the code out. The less skilled programmer is going to be frustrated not doing any real artwork, and instead figuring out how the code works. And so on. It’s a two person team. You’re not going to be having specific positions. Something needs to be done, you’ll figure it out.

Quote: You should always have a project leader to assign jobs and tasks

Again, don’t waste time on this nonsense. In a starting project of two people, this is going to end up being very silly.

Quote: Make dead-lines:

Oh, the hilarity will ensue here. As rookie programmers, you’re estimations are going to be more like ridiculously unbridled optimism. Your deadlines will mean absolutely nothing. Just focus on making very small iterations. Small changes, debug test. Deadlines don’t matter. If you’re not doing the work, you’re not doing it. You and your friend will know. If you’re doing it, your project will progress. Deadlines aren’t going to mean a thing here.

Quote: Ogre, weve been looking at it and as far as capability’s and difficulty how is it to work with it if anyone has had experience with it?

I thought you were using XNA? If you’re mixing up XNA, C++, C#, Ogre, and what not, well...let’s just say you better sort those things out now.

Quote: now with compatibility and transferring models how does that work exactly? i mean if i have a character model that is fully rigged and has a walking and jumping animation and a basic world (flat plane or what have you). now would that be compatible with ogre and c++

From the programmer’s perspective, he has a graphics engine, or he has made an engine to handle a specific graphics format internally. You’re going to have to work with him to determine how you would deal with third party formats (essentially what your creating with a 3D modeling tool). Maybe there is a prebuilt exporter you can use (true for Blender for Ogre). It might need some extra processing, and the programmer has to write code for that. Maybe you need to save files in a different format. Whatever.

Wow, made me want to kill my self after reading that :P

Anyways, about Ogre3D, its is a great graphic engine. The rendering is of a provisional look. It uses the CEGUI witch incredible in making menus and GUIs. It has many wrappers for many physics, scripting and other libraries. It also has a large community, documentation and tools to work with.

The only set back (if you can call it a set back) is that it uses its own format for loading 3D models. Which is not a problem because they already have a converter tool that takes care of that.

Now for your part, all you have to do is make the levels and model, load them into a converter (which acts like a mesh viewer also) then import it to ogre’s format for the programmer to use.

Ogre is a good choice. It will give you great result as soon as you know how to use it.

I would suggest starting out with something little at first, complete it. Then start with something bigger, then complete it, and keep going on that route.