Jump to content
  • Advertisement
Sign in to follow this  
Abbacabba

Help outline my first 3d game/app

This topic is 4901 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

I'm about to start writing up my first 3d game. I've written a number of 2d games, and a few 3d programs using MDX in C++ and C#, but I have never really made anything very large. In the past I usually built a very slim graphics/output engine, then worked in some input(keyboard/mouse) then some physics, then sound... Then kept working on them in cycles. Add new "objects"(Graphics) implement ways to interact with them(input), made sure they interacted with existing objects(physics) and made the approprate noise(sound). wash-rinse-repeat I was wondering what order most of you built to, that is what order are the following done: AI Graphics Physics Sound Input Level Editor Networking (if any) *Anything I missed* Is it common to totally flesh out the Graphics before moving into Physics? Do most of you wait for Graphics & Physics to be complete before adding in sound? Do you get a framework for each and build from there?

Share this post


Link to post
Share on other sites
Advertisement
I guess in a true OOP program, it wouldn't matter which order you do things in, since they are completly independent. However, realistically, I think graphics and input are ussually the first to be developed, as it can be pretty tough to test some of the other stuff without giving input are seeing a response on screen.

The only things I can thing of for your development list is maybe a menu system, and the actual engine design (how everything fits together). But in the end, it should really be about what makes sense to you. You'll never get it perfect, so get it working!

Matt Hughson

Share this post


Link to post
Share on other sites
I used to be in the habit of always focusing on graphics first. It always got me stuck when trying to integrate with something else. My current project is following this order:

Level Editor (starting here makes sure I don't have any integration problems and firmly sets out how the code structure will look)
Networking (this is another one tricky to implement halfway through the project...I don't have the networking actually working, but there are blank functions that return dummy values so I can still work with it)
AI/Physics
Input (before graphics because bad input code can lead to some ugly hacks)
Graphics
Sound

So far it is working better than any other project I've had before. The code for the level editor is essentially done. It simply calls a bunch of dummy objects that don't actually do anything yet. I can now go in and add content to them without worrying about how to tie things together.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raloth
I used to be in the habit of always focusing on graphics first. It always got me stuck when trying to integrate with something else. My current project is following this order:

Level Editor (starting here makes sure I don't have any integration problems and firmly sets out how the code structure will look)
Networking (this is another one tricky to implement halfway through the project...I don't have the networking actually working, but there are blank functions that return dummy values so I can still work with it)
AI/Physics
Input (before graphics because bad input code can lead to some ugly hacks)
Graphics
Sound

So far it is working better than any other project I've had before. The code for the level editor is essentially done. It simply calls a bunch of dummy objects that don't actually do anything yet. I can now go in and add content to them without worrying about how to tie things together.


How are you going to test your Physics/AI without the graphics?

Share this post


Link to post
Share on other sites
Well I am currently working on a game ,and here is the project steps:

1. Create map class ( with possibility to save it modify it and so on (map editor in one bottle) ) and also rendering it

2. Physical system ( It took me about 1 month to finish it it is still not the ideal , but it is not bad)

3. Trigger / Event system (Currently working on it)

4. Ai

5. Sound

6. Additional graphical eye candies

7. Network code ? Maybe If I live to that :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Raloth
I used to be in the habit of always focusing on graphics first. It always got me stuck when trying to integrate with something else. My current project is following this order:

Level Editor (starting here makes sure I don't have any integration problems and firmly sets out how the code structure will look)
Networking (this is another one tricky to implement halfway through the project...I don't have the networking actually working, but there are blank functions that return dummy values so I can still work with it)
AI/Physics
Input (before graphics because bad input code can lead to some ugly hacks)
Graphics
Sound

So far it is working better than any other project I've had before. The code for the level editor is essentially done. It simply calls a bunch of dummy objects that don't actually do anything yet. I can now go in and add content to them without worrying about how to tie things together.


I've personally found that making any sort of editor first is really bad news. I try to get a demo level up and running (just with hard coded values) and then when I make the level editor I just look at what is hard coded and make them editable in the editor. The problems ussually stem from the fact that you can never be positive about what a 'level' should contain, untill you've actually gone and made one.

Just my own experiences though,
Matt Hughson

Share this post


Link to post
Share on other sites
First get the graphics, sound and input functioning, that way you can tweak the hell out of it. Then implement physics and game logic.

Once you have in a playable state you might as well set up network. A good way to get feedback from other people while actually having fun.

Leave AI until after you have played a few multiplayer games, by this time you will have played many a game and have a better understanding of what people will actually do.

Once you have made a few levels, then its time to actually make an editor.

Get your game in a playable state as quickly as possible, then once its 'up and at em', go back and enhance the areas that were lacking. Which is similar to your method. Once you have completed your first game and know how everything is done, you can then take a more structured approach.

[Edited by - Aiursrage2k on March 17, 2005 9:16:51 AM]

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!