Jump to content
  • Advertisement
Sign in to follow this  
Sixoul

New to working on a team

This topic is 2099 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites

The only way to do this is just by making people responsible for certain tasks, ask them what they would like to work on even for the beginning tasks.

 

All of the things you have proposed to create in the beginning are singular tasks, when you need something from someone else, eg the window handle for example for rendering, you need to specify an interface between those systems and both of them will have to stick to that interface.

 

When working in a team communication becomes important, you don't need to know the specifics of how something is implemented as long as you can get the data from that system/class/code to get your task done.

 

At work I jump through the codebase a lot and talk to a lot of people just to see what the best way to achieve a certain thing is when I have to rely on other peoples systems or need data from them. Otherwise I write my own things and trust my own judgement in where to place things, and yes that might sometimes not be the correct place but that doesn't matter, talk about issues like this when they arise as a team.

Share this post


Link to post
Share on other sites

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).

Edited by Sixoul

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Edited by Sixoul

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

Hi,

 

The best way for you to know how to structure any game is to look into the main registry folder of that genre of game from a successful game developer.  In this case, it would be best for your team to get permission, or perhaps under license of a popular Open Source SFML game, and look at what's in there.  An Open Source game developer would probably be glad to answer your questions in exchange for public acknowledgment in your credits once your game is released. Your team really needs to absorb it together and discuss it.  In a one hour meeting, your team will learn more than you all could working individually for many hours.  

 

Really analyze a few games and notice the similarities.  Don't just take for granted that everyone realizes what they are seeing but have an in depth discussion. 

 

A team leader, in the case of a club, must be voted into place to avoid any jealousy or rivalry.  Looking together at games "under the hood" and having focused discussion is a great way for everyone to learn the skillset of the team and eventually elect a team leader who will act as a scheduler, coordinator, mediator, and facilitator.

 

Next stage would be for the team leader to request volunteers to look more in depth into various areas of the game in their free time and make a written report to summarize what they learned.

 

Get used to organization and documentation from the start and you will be able to maintain quality control and information exchange in the way that all successful team game developers do in the long term.

 

I would lastly suggest a game development club charter to document all of this for current and future projects.   Every long term and great organization has some kind of organization charter established by the founders.

Edited by 3Ddreamer

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!