So I have to lead a team of beginners, myself included, in making a simple loz style game prototype with 3 enemies. Keeping it simple for our first week or so. I have 3 programmers and 2 artist for right now. We're using C++ and SFML. First I'd like to ask if there are any other libraries that might prove to be useful. Second I'm not sure how to split up the beginning task.

Afaik we need a main game class, a window class, rendering class, input handling. That's just before we even start the actual game prototype. Am I forgetting anything? Besides the input handling I don't know how to split these classes up amongst the team. I'm not sure how well they can program. We're just college students in a club. I'm not sure they can quite understand programming without seeing the whole thing, if that makes sense. We've always been told to work on a whole project and not just a single part.

Any tips would be great. Also, I'm pretty sure I'm forgetting some classes.

I guess I would ask yourself these questions:

1) How am I handling input/music/sound?

2) How am I handling scene management?

3) How am I passing data from one class to another?

4) What data structures should I use?

5) Since it's a team project, what coding style will the team adhere to?

6) Do we want to use tortoise svn, github, or some other code repository?

I feel as if before you start programming you should at least know what classes are going to be required for your game and their relationships to other classes. Granted, you may cut a few out or add a few new ones during the development process but you need at least a basic idea, and if you don't have that, then you should go back to the drawing board and figure out what will be in your game.

If you don't know what level they're at in terms of programming, then list off what needs to be done (this goes back to the whole design thing) and ask what people feel comfortable doing. If one guy can only do input (for example) then you could easily task him out to make the best damn input API ever.

I guess I would ask yourself these questions:

1) How am I handling input/music/sound?

2) How am I handling scene management?

3) How am I passing data from one class to another?

4) What data structures should I use?

5) Since it's a team project, what coding style will the team adhere to?

6) Do we want to use tortoise svn, github, or some other code repository?

I feel as if before you start programming you should at least know what classes are going to be required for your game and their relationships to other classes. Granted, you may cut a few out or add a few new ones during the development process but you need at least a basic idea, and if you don't have that, then you should go back to the drawing board and figure out what will be in your game.

If you don't know what level they're at in terms of programming, then list off what needs to be done (this goes back to the whole design thing) and ask what people feel comfortable doing. If one guy can only do input (for example) then you could easily task him out to make the best damn input API ever.

1)I think we were just going to use what libraries sfml has for sound/music/input. Unless there is something that is more efficient. But I was kind of asking if there were any other useful libraries to use. We are beginners so we don't know what to look for really.

2)Could you explain scene management? I'm not quite sure I understand what you're referring to.

4)Would records or arrays be fine?

When you say we should at least know what classes we need I was kind of asking if I was missing anything listed from the like pre game coding classes. I think we basically have a general idea of what we need for classes when it comes to the game but not setting up the windows, rendering, and all the stuff that gets the program started before it becomes an actual game. Like we know we'll need at least a player class, 3 enemy classes, weapon class, player controller class, 3 AI controller classes. Also, some classes to represent everything in the world, so like walls and stuff. Item drops. Inventory handling class. I'm not listing all the stuff we thought we might need. But I want to make sure we know what we need to get it running first.

Did I forget anything in the whole pregame classes? Main game loop class, window class, render class, input handling class, sound/music class(maybe separate if we want).

What about Phil123's part 6: your code repository?

How you split things up into classes is somewhat arbitrary, and you can decide on those things as a team. If you forget about some class now, it doesn't really matter. You'll add it when you think you need it. Before structuring your game, it is important to decide how you will manage to work as a team. Splitting the project into classes, dividing classes among teammates, and trying sometime later to build a game out of out of a bunch of parts developed in isolation by beginners is unlikely to succeed. I hope that's not what you are planning.

I'm just trying to make sure I understand what we need in general to get it running I guess. I understand what he's saying for the teamwork and splitting the tasks is basically up to us and how we want to split our classes up. But I'm wondering what specific things, if any, I forgot to think of to start off. Just getting started.

I'm just trying to make sure I understand what we need in general to get it running I guess. I understand what he's saying for the teamwork and splitting the tasks is basically up to us and how we want to split our classes up. But I'm wondering what specific things, if any, I forgot to think of to start off. Just getting started.

Well, it sounds like you haven't thought about source control. That's what I'm getting at. That's a specific thing you haven't mentioned yet. I know my phrasing is maybe a bit harsh, but I'm trying to help. I wouldn't want to do any sort of collaborative software, or any large solo project, without source control.

Sure, you could split up the classes among the three programmers, but I think work is more naturally split by features, and it's easier, especially as beginners, to have small, short assignments with noticeable progress. Unfortunately, it's really hard to work on features instead of APIs, without sometimes having more than one person edit the same class at the same time. That's what source control helps you do.

Also, with a source control tool in place, everyone can see and edit the whole thing. You don't need to worry about only seeing one part. If I was in a programming club in college, I wouldn't really want to be stuck with just one part, anyway. I'd track progress on, if not actively edit, the entire game.

(If you didn't need a mini-lecture on source control, you should have told us which tool you chose.)

Trello is probably the best (free) tool around for keeping things organized. Use whichever version control your team feels comfortable with but make sure everybody knows how to use it properly.

1)I think we were just going to use what libraries sfml has for sound/music/input. Unless there is something that is more efficient. But I was kind of asking if there were any other useful libraries to use. We are beginners so we don't know what to look for really.

Well, that's what I mean. Yes, there's more than likely a basic API for sound/music/input but MAYBE you'll want something a little higher-level that's easier to use and more specific to the project. Take for example XNA's input system. Each Update(), you can get the state of a key (is it down / is it up). With this information, you can construct an API that allows you to ask the class if a key was pushed this frame, or is currently being held down, or was released. In this case, you'd only have to code the logic once for KeyDown, KeyHeld, and KeyUp once as opposed to making sure your logic is correct each and every time you need that information in various classes all over the place. This is obviously a simple example but you can make it more robust depending on your needs.

2)Could you explain scene management? I'm not quite sure I understand what you're referring to.

What I'm getting at that is how will you transition from scene to scene, pass any necessary data, what states your scenes will have, etc.

4)Would records or arrays be fine?

Arrays are great, but look in to vectors as well. Those two things should suffice.

I know you're just getting set up, but planning these things is extremely important as it'll make the development process much smoother.