What you do is build a very basic broad base in each area of game struct and support coding. With each iteration, you are supposed to extend the coding. Early iterations may use place holder art in some situations. In my opinion "waterfall" is a recipe for chaos and confusion in a team. In both iteration and waterfall, you need to build on a software architecture, designed and finalized by the development head. No plan is also a recipe for chaos and confusion, increasing probability of coding that is not reusable in the future as teammates are lost and added.

There is not enough information in O.P. to make recommendations on game coding structure and software to aid you in designing a plan.

Git and Perforce are long term recommendations and the sooner your team starts using one or both of them than the sooner you will reach project completion with a reasonable level of quality for newbies.

Often "waterfall" results in whirlpool! Keep the early design and team structure simple, but it must have a spine or you will be slithering around the coding like an ameba. By the way, Wikipedia has good articles and links for issues in the game development and software development topics and subtopics, which helps noobers a lot.

In both iteration and waterfall, you need to build on a software architecture, designed and finalized by the development head.

how can i make a good software architecture for may game?

Since it is going to be a very simple and humble beginning, look at making charts for the game coding modules. Sometimes people start with a so called "spider chart" or "wheel chart" which has a hub in the middle and legs or spokes in all directions.

Wheel or Spider Chart

A game dev with fairly simple beginning like you have here should put the main menu and background interfaces connected to it which only the game dev team will be using and seeing in the middle of the chart. At first this can be done with a pen or pencil and a sheet of paper. Put the Main Menu in a box in the middle of the chart. Next place interfaces which only the team will use (invisible or non-existent in the end-user game) around the main menu: Import/Export (mainly art assets), configuration, compiler/decompiler, debugger, and so forth. On the outside perimeter of the chart, put the basic game coding structure: dlls (or jar files in the case of Java), each class file (for example, good guys, bad guys, AI, vehicles, map / level, objects, powers, weapons, etc.), main menu [coding] module, physics, executable file, etc. Just put a label in each box with no description in this chart. This chart will be revised several times as you learn more!

Flow Charts

Module Module

Class Files DLLs or Jar Files

Flowchart Flowchart

Main Menu ....(Hub or Body of the Wheel or Spider Chart)

Flowchart Flowchart

Module Module

Executable File Configuration File

The flowcharts are made next to list the coding libraries and the coding issues involved in each particular FLOW of functions. You can see from the end-user perspective that the flow is from center main menu to the coding modules and returns with each response. Also there will be flowcharts made to connect the modules in the third stage of software architectural planning. Forth stage is the actual design (in detail) of the specific tools used, coding libraries, and issues anticipated.

A) Software Architecture Stage

1) Spider or Wheel Chart

2) Flowcharts (Legs) from hub to modules (Feet)

3) Flowcharts between modules

B) Design Stage

1) Select IDEs, SDKs, and game engine to be used

2) Choose coding libraries to be used ( "template" coding libraries like compilers, deguggers, graphic user interfaces, plug-ins, importers, physics library, and editors, etc. )

3) Decide on art assets to be used

4) Make a flowchart which lists all of these in concise labels

5) Draw art which shows visually each area of the game, such as characters, vehicles, level (map), Main Menu, Splash Screen, Score Board, etc. You may also make scene by scene design art for stages of gameplay. This may be as simple or professional as you feel is necessary. This is a good place to assess the art skill of your teammates and their enthusiasm for the project.

C) Development Stage

1) Chose roles and tasks of the team

2) Start with creating largest art asset or most important one in the game, often the "map" or "level" and the most important coding library for beginning, often the game engine setup. Early art assets can be all placeholders as your team learns to use the development system that you have assembled while at the same time working on the real art assets.

3) Team learns how to use the IDEs, SDKs, and/or game engine by the following sequence:

a) Import the level or map and the main user operated asset (could be the main character, vehicle, weapon, etc.)

b) Make the end-user operated entity moveable, create the input method to manipulate it, and make the Main Menu buttons to start, play, and end this simple game stage.

c) Add more art assets and functions by class files in the coding modules, vetting the game play and background functionality with flowcharts

d) Test each iteration with as many players as needed. Several people should test each iteration because often differences in people will discover any bugs or improvement to be made. Be thorough in testing and have fun with it!

Obviously, there will be times when steps will be skipped or swapped in order, but this will give you a basic outline.

Be sure to keep copies of all your charts in case you need to revisit an issue and also to promote the reality that your team is organized for investors, publishers, and future reference for new teammates.

Procedure is designed by the game development leader with input by the team. There is no method which is "one size fits all", but you must learn how to create the process of game development as you work, since you are beginners. There have been many articles submitted to this website, game dev here, about all the questions that you asked. Every developer will be somewhat different in habits with also many similarities, so don't worry about details at this point. See the webpages on articles here at game dev and use the search box.

Alpha - inhouse iteration development and testing

All basic game functionality should be in place after the first iteration. Once you have a basic functioning game, then that is your first Alpha version, such as Alpha 0.01 or many people use whole numbers right away like Alpha 1.0 followed by Alpha 1.01, 1.02, 1.03, 1.04, 1.05, 1.06, 1.07, 1.08, 1.09, 1.10, 1.11, 1.12, etc..... Alpha 2.0 and decimal fractions again... Alpha 3.0 and decimal fractions. Each Alpha version is tested by Alpha testers, usually in your team, while you begin work on the next Alpha version - over lapping fashion. (Note: The "Proof of Concept" version used to show investors and publishers can often be one of these iterations of Alpha, since investor want a very early indication that your team can complete a game before the investor commits to more money for you.)

Demo version

This is made in the Alpha or Beta stage, but it is best to do it in the Beta stage for a more reliable indicator of how your development is actually progressing. Some publishers or sponsors will want it this way for that reason. Demo is just a taste or hint of the full featured version. If you constructed your game coding properly, then you should be able to use hidden interfaces in the coding to turn modules ON or OFF to make this Demo. For example, your game might have 7 levels (or maps) in total, 5 characters, and 20 rankings, but you ship the Demo with only 1 of each category to demonstrate gameplay.

(Note: Demo is not to be confused with "Proof of Concept" which is even less functional just to show that you are competent enough to receive more investment to sponsor your game development into further iterations. Demo is for hooking new interest in your game, whether end-users or potential investors or a publisher. "Proof of Concept" is for an already vested sponsor who wants proof that your team has the ability to make the game.)

Beta - partly published iteration development with inhouse and outsource testing

In the professional video game industry, the publishers and other sponsors need to have you test versions of the game inhouse and by people outside your game development organization (which can include general video gamers who are Beta testers and/or members of the actual Publishing company or investors who have their own Beta testers). Beta versions are seldom full featured until you advance in Beta iterations to the Beta RC stage (Beta Release Candidate)for example: Beta 6.1 RC (Release Candidate)

Prototype version is a version before the full functional one. "Proto" means and implies a more primitive version. Prototype is a term less used than Demo or Proof of Concept. Some indie developers combine the purposes of a Demo with the Proof of Concept version and call it the "Prototype" but I have never heard "Prototype" used as a term in advanced development circles.

Wheel or Spider Chart

thank you 3ddreamer for your comeplete answer but i cant find something relevant to spider charts and in google i search "spider chart for videogames" but it just shows me "spider man game on charts" Just Search "Spider Chart" or "Wheel Chart". Adding more words only confuses the search engines. What you will find are only general examples, but it is for you to design your own charts when you are handling things as complex as software development (video games). Be creative instead of searching hard for that perfect template chart.

i tried to find more specefic to make game procedure and i wanted to explain procedure simpler and i found it like below can you tell me is this the right way?:

first i have to prototype my core gameplay. and there will be no need of high quality objects, just simple models to see if just they work. and for impelemnting gameplay its better to impelement first player behavior like moving and jumping and shooting.

and after that make elements that interact most with player. like weapons to pick and enemies with their ai and animations.

after doing that impelenting game rules. for example when player wins or when player looses and after that what happens or how player respawns and like that or in multiplayer impelment deathmatch or capture the flag scenerios. and in this process all elements will be tested beside each other in every (i think agile scrum teams call it)

sprints and gameplay will be compeleted through these sprints.

after doing this modelers can start making their models and their models will be replaced with those basic models and they start building levels step by step.

after doing that we start adding story to aour game for example which part of level have certain dialog or animation or cutsecence.

after doing that we start doing beta testing and solving bugs and giving it to diffrent people to test and give opinions for.

Concept Stage - Decide on game concept and make Software Architectural planning

Design Stage - Assemble your workflow pipeline of software and applications, fill coding flow charts on game and background functionality, make illustrative art and charts to plan your game functionality and art assets

Use a place holder Character, Object, or Vehicle

Make a placeholder Level, Map, or Backgroud

(Import the most important stationary art and import the most import end-user operated entity from these above two.)

These two objects should appear onscreen inside of the viewport of your game engine, IDE, SDK, a window made for the game, or directly to screen.

If you assembled your workflow pipeline correctly, then you should be able to use an IDE, SDK, or game engine to add the library for device input [INPUT] that makes your user operated object move. With whatever number of lines of coding made by you, when you move your input device then the object on the screen will move. Another library could be added for physics. With the required coding to connect the physics library to your object, then your object will be subject to physics that you have tied it. After the collision library is added to your coding and you make coding to associate it with your moveable object, then your object will respond in the ways that you have specified in coding when it encounters a collision.

As you added different libraries of coding (often already made by others, such as Open Source physics libraries) and follow the instructions for those libraries, then your coding will add more functionality to your game.

We are just beating around the bush with general concepts until you decide on the coding libraries to use (for example, Torque 3D). "Simpler" that you mentioned means more general until you "get down to the nitty gritty" in deciding on specific things and doing actual work. Until then, there is little more that I can offer in the way of advice on

"procedures".

What you may think is "simpler" in procedures often results in spaghetti coding that is difficult or impossible to debug. The process that is well organized may seem complex at first but actually makes game development progress better in the long term. Organization allows communication of ideas and the prevention of many problems. "Simpler" means fly by the seat of your pants.