• Advertisement

Archived

This topic is now archived and is closed to further replies.

Best way of coding a huge game.

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

Hi I am working on a huge game (well the biggest I have ever done) and was wondering, what is the best way to do it. should I write the entire code then compile, run it and test it or should I write a block or code say to produce the menu system and then compile, run it and test it and debug to make sure everything works as I code. The latter method is the one I use but I was not sure if that is wrong in this sense that it may slow me down. Does anyone know how the big game companies do it? do they write the entire source code for their game and run it at the nd to find mistakes or do they split it in to blocks and test as they program to reduce having to do all that at the end. What are the advantages and disadvantages of theses methods and which ones do you guys use. Thanks in advance Dark Star

Share this post


Link to post
Share on other sites
Advertisement
I would test each block of code.

say you have a 7000 line of code game.

then youy run it for the first time and it crashes. you have to go back through all that code and find the problem. With each block you would have much less

+-----------------------------
Come, help me program my 3d game, i just picked up a new copy of Learn C++ in 21 days!
--Unknown Newbie
+-----------------------------

Share this post


Link to post
Share on other sites
I AM NOT REALLY GOOD WITH 3D GRAPHICS, I HAVE CODED AN ENGINE BUT WAS JUST WIRE FRAME. STILL LEARNING THOUGH. AT THE MOMENT I AM WORKING ON REMAKE OF SNAKE WHICH IS 2D. THANKS FOR THE OFFER. MAY BE I CAN WORK ON SOME BACKGROUND STUFF LIKE 2D GRAPHICS IMAGE PROGRAMMING OR WHAT EVER BUT NOT REALLY 3D BECAUSE I AM STILL TRYING TO LEARN 3D CODING.

Dark Star

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
hehe

Share this post


Link to post
Share on other sites
HAHAHAHAHAHAHAHAHAHHAHAHAAAA !!!!!!!
That is the funniest thing I have seen posted on here......
Dark Star sure is good for a laugh.......
That is his quote man........it is something a newbie put down and was pretty funny by itslef until you came along.......now it is a little bit funnier........



"Now go away or I shall taunt you a second time"
- Monty Python and the Holy Grail
themGames Productions

Share this post


Link to post
Share on other sites
Uh, I don''t think I should say anything about that second post there.

For your original question, though, I personally program it in stages. So my first goal might just be to get a landscape engine, then I add water, then trees, etc.

In other words, set milestones for yourself. It helps you when your trying to think of what you need to work on next.

--TheGoop

Share this post


Link to post
Share on other sites
Dark Star - when somebody has a seperator at the bottom of their msg like that, it generally means a signature follows, and that signature happened to be a funny qoute.... I wonder if he''ll add that response to it

Share this post


Link to post
Share on other sites
lol^^

Everyone debugs little bits of code at a time.
Writting a program, and then starting the debugging would take more time than testing each component.

I usually compile after every few lines (like saving in word after every line or two) to check for mistakes.

Now, obviously, this isnt the way to debug a final product - but while you''re working a small piece of it.

Also note that bad design is usually a bigger headache than poor implementation- god i hate maintaining old code...

Anyone have some keen insight on good code design - particular to gaming?

Share this post


Link to post
Share on other sites
Well, first of all, I''d better say that I haven''t the foggiest idea how commercial games are developed, and I''m still working on my "huge game". So if I sound dumb, just ignore me.

Now...despite that, I think I can say this: If you write the whole thing, then test it, you''ll likely have a nervous breakdown if you make any mistakes--which I''m sure you will (not to say you''re a bad programmer, of course; *everybody* makes mistakes).

So, my advice is to construct your game *very* incrementally. If you write any slightly large amount of code, test it, and get whacked by a bug, you might have trouble finding the bug. But if you just add a few lines, you''ll have an idea of where the problem is, right? It could still take a lot of work, but less than if you were digging through the whole mess of code.

Also, I''d say it''s important to review your code often. I''ve discovered that I tend to find more bugs by code review than by compilation and execution. You don''t want to have that God-I-hope-it-works attitude; it''s better to take your time, and *know* for *certain* that it works. I know, you can''t *always* know if something is going to work--but believe me, making an effort to know what you''re doing goes a long way.

So this is my development cycle:

1. Determine the most important thing to be done.
2. Decide how to do that thing.
3. Write a bit of code.
4. Double-check your code.
5. Compile.
6. Execute.
7. Debug if necessary.

Share this post


Link to post
Share on other sites
10,000 lines of code should not take long to compile on a newer system. It have about 7000 lines now and it takes my comp about 1 min to compile the whole thing. But I also have a 650Athlon w/ 256 meg ram, but I just got the comp and last week was using my pathetic P200MHz w/ only 32megs ram, it only took about 3 to 5 min to compile, or just 20 seconds to compile a single file, and thats not a long wait at all.

Possibility

Share this post


Link to post
Share on other sites
What compiler are you using? My game is about 3000 lines so far and it only takes like 5-10 seconds to compile at the most. Isn''t Borland a slower compiler? I remember downloading the demo and wondering why it compiled so slow. I''m running a p800 128 Mg Ram.

JoeMont001@aol.com

Share this post


Link to post
Share on other sites
Oh, yeah, keep bragging about your computers. You don''t know what it''s like to code on a p233MMX with a Voodoo Banshee all the time and try to make cutting-edge, fun games. It makes me optimize, optimize, optimize.

But what really gets ugly is when this computer is busy and I have to program on the p120 accross from me here - 2 MB 2d card, no 3d. But I seriously get more done there. Often I am coding and compiling every few lines just ''cause I can. On the other computer, I would code about 100-150 lines of code at once, then compile it when I got the chance. Saves a lot of time, with no really huge increase in debugging time. Just a thought. Try writing an entire procedure or two before compiling.

Share this post


Link to post
Share on other sites
I always get a basic skeleton of my engine up and running first. add all of the functions but just shove a "return 0" or whatever in the code. Once this works fine, then I fill out a small part of the code (I usually start on the drawing routines). After coding one or two functions PROPERLY, compile and see what happens. The obvious ones to code are drawtriangle, drawline, drawbitmap. Once these are working, implement some more "advanced" features, like backface culling, texturing, and so on. Check to see if this works. Finish off the graphics engine and then move on to input (very simple). compile. sound engine. compile. fancy stuff like particle engines. compile

when doing a new section, always implement the basics before doing something too advanced (i wanted a complex particle system routine in my engine and then i realised i couldn''t draw a polygon yet ). once the basics are up and running, THEN it''s time to have some fun .

MENTAL

Share this post


Link to post
Share on other sites
Possibility: 7,000 lines of code in 1 min is hell to wait. My games about 3,000 and it take about 15 seconds. Its a K7(letter C), 750, at 3/5 clock(HAHAHA), 128mb 133, @105mhz bus. Still thats not much faster than yours, and it should take that long. Yet the only tasks I run are the shell(explorer) and systray. Maybe thats why?,
PS: What compiler?

Share this post


Link to post
Share on other sites
My guess on the compile speed thing is a lack of a "Just say No to MFC'' philosophy - he may have 10,000 lines of his own code, hehe but there''s 100,000 lines of Afx & MFC code in there too

Share this post


Link to post
Share on other sites
my goodness!!!!!!!! The ONLY way to write ANY program is to write it in small pieces. i know this from experience. i had to write a real program for my final in computer science, and i chose, like you have, to do a SNAKE game, in dos. not hard you say, right? WRONG. of course, i have all the skills necessary to accomplish such a thing. so don''t think it was a difficult task because i didn''t know what i was doing. but here''s the deal. i started out, and the first thing i did was write the whole program. to support 2 players, have a scoring system, to draw the graphics, to do the sound (just simple beeps), input system, collision, the little fruit thing you have to eat, etc...
and guess what? it didn''t work. and i couldn''t get it to work. i spent about a month working on that project. and i am talking virtually nonstop. but i got nowhere, because of my approach. however, when it got to be about 2 days before i had to turn it in, and all it did was crash the computer, i decided to get down to business... so what i did was this: i kept it SIMPLE! all i did was one snake, on the screen, and it moved and accepted input. no sound, no fancy graphics, just squares, no bounds checking, etc... and it only took 5 minutes. i am NOT exaggerating. 5 minutes. then i added everything else over the course of the next two days, and i got full credit. AND, i was very satisfied with what i had created. i would swear by the fact (or idea) (or whatever), that the ONLY way i would ever have finished that project would be for me to do it in small chunks. i did it a function at a time, and it came out wonderful in comparison to what i had had before. anyway, thats just my two cents. btw, if you want some more good advice, there was an article on a certain programming strategy just a while back, that talked about coding so you don''t have errors, WHILE you code, instead of debugging later. i don''t remember what it was called, but you should probably be able to find it if you just look around gamedev a bit. ttyl.
farmersckn

Sometimes even chickens need to eat... Don't bang your head against a wall just to enjoy the good feeling when you stop.

Share this post


Link to post
Share on other sites
OK, this string of replys is halarious. It''s filled with little actual information and a LOT of useless crap. (I wont point out which one is which, so i wont offend anyone!) (cough -- WHO CARES HOW LONG IT TAKES YOU TO COMPILE X amount of CODE on your NEW SYSTEM!!?!) That *WASNT* in the question!

Anyways, I believe that what your original question was asking was whether or not to program little ''mini'' programs (ie. Menu, Main, ending) Rather than just writing it like a book. From start to end. My advice would be to keep everything in one application and starting to work on the basics. I really like that ''mildstone'' mentality mentioned earlier. Working on one little part of the game at a time and making sure it works makes a lot of sense for a few reasons.

- You''re more focused at what''s at hand. ie. you still remember what your train of thought was at that particular line of code.
- It''s a lot easier to hack out bugs if you know that it''s somewhere between line 2000 and 2013.
- You''ll inondate yourself with too much to work on and think about if you just try and code everything at once.!

Here''s a way to keep yourself on track and working on little things to get your program done.

At the top of the code, write out a ''to-do'' list. (cough hopefully written in some way in a design doc).

The way *I* personally like to do it is to have a ''longterm'' and ''shortterm'' List. And keep things in Order and Categories

A quick example:

Short term

- Graphics Engine

- DDraw Init Func
- DDraw Clean Up
- DDraw Functions
- Blit funct
- Text blit Funct ...
- Rendering Engine
- Textures
- Etc.

- Input Engine

- Keyboard init
- Mouse Functions


- Etc


Long term

- SOUND ENGINE

- Dxsound stuff
- Make songs in fav editor..
- Find samples.
- etc

- GFX engine
- Cool lighting
- Special FX

- Menus

- Credits

Anyways, you get the point. Then as you complete the different functions, make sure they all work, one by one. Start with the absolute basics! Then, as you finish off more ''short-termed'' things, Make the long term ones more descriptive and specific and move them to the Short-term list!

If you get a new idea, throw it onto the list so you wont forget it.

Anyways, that''s *MY* way of programming bigger applications. Pace yourself and keep the Milestones small! (ie. Write a text blitter. vs. Make a cutting edge 3d engine). You''ll feel good about yourself if you finish a lot of small steps, rather than being half done a huge one.

And plus, it feels good to check off stuff on a to-do list!

have fun

-gxd

PS. REMEMBER: *NEVER* End a programming session with Errors or Warnings! Make sure that it''s all compiled and ready to go when you turn in for the night!

----------------
"If at first you dont succeed, Skydiving is NOT for YOU!"
----------------

Share this post


Link to post
Share on other sites
quote:

PS. REMEMBER: *NEVER* End a programming session with Errors or Warnings! Make sure that it's all compiled and ready to go when you turn in for the night!



Was that a joke?

Sleep on it, look at the code the next day - your error will be apparent to you.

Edited by - Magmai Kai Holmlor on June 25, 2000 2:01:18 AM

Edited by - Magmai Kai Holmlor on June 25, 2000 2:01:41 AM

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor

(quote)
PS. REMEMBER: *NEVER* End a programming session with Errors or Warnings! Make sure that it's all compiled and ready to go when you turn in for the night!
(end quote)

Was that a joke?

Sleep on it, look at the code the next day - your error will be apparent to you.




Actually, I agree with that. Whenever I finish a session, I try to make sure I can at least build the game without compile-time errors.. Sleeping on runtime problems is a good idea, but most compile-time errors are easy to figure out and fix.

Oh, and in regards to Julio's post: "Isn't borland a slower compiler"
Everything I've ever read has suggested that Borland's compilers have always been some of the fastest.

Edited by - Qoy on June 25, 2000 2:44:45 AM

Share this post


Link to post
Share on other sites
Well, I know this has been answered already a couple of times, but it now seems like a ''How do you program/test?'' thread so I''ll give my approach and my idea of the ideal approach.


Ideal approach:
Write down all features you want. Be cynical.
Determine what interfaces you will need for the simplest,
smallest feature set that would be needed and would run.
do
spec out next class interface.
write all-inclusive tests for the current system once the
next class has been integrated.
write all-inclusive tests for the next class you will write
(to test it by itself, without the system).
do
write the simplest class that will work for the
current feature.
review source code by hand before compiling it.
fix any mistakes found.
run tests.
until all current tests pass.
integrate class into current system.
test system.
if system fails test, fix class, test class seperately, test
class integrated, and repeat until it works.
until smallest feature set version is done.
Then for each subsequent feature, repeat the above.

Of course, for this to work it would require dedication and patience. I haven''t actually done this myself, but one day I probably will. This is based off the idea of XP, so if you know XP the above should look somewhat familiar.


What I actually do:
Spec out a feature, dividing it into small components.
Write each component, refactoring the system if necessary.
Test the component within the system until it works.
Until the project is done.

The biggest reason that I keep such disparity between the two is the amount of effort it takes me to make small, quick test cases. If I had a tool to automate the testing, I probably would switch to the ideal method.

The most important thing, which a lot of people have previously emphasized, is that you should always be testing. The only testing that you can even consider to defer to the end of the project is ''game balancing.'' This is because the numbers your designer writes down in the beginning need to be tweaked once they are all implemented, and unless the designer(s) are very good at guessing, they won''t know how well it actually works.

Dark Lord Pi

Share this post


Link to post
Share on other sites
I use lots of classes, seperate different stuff into different source files, and do a lot of technical design. For instance, I''m making a game this summer that I started designing around January. Now THAT''s a long design time.

- DarkMage139
"Real game developers don't change the rules. Real game developers don't break the rules. Real game developers make the rules!"
"Originality (in games) is the spice of life!"

Share this post


Link to post
Share on other sites
Dark Star, definately test each module seperately and then once you integrate them test them again. ( Clear box testing )
Then if you can write up a list of test you want performed, and hand over your code to someone. They shouldn''t know how your block/module works internally though. ( Black box testing )

Share this post


Link to post
Share on other sites
GXD: What the hells your problem, is it ok to learn about the speed of different compilers, and why someones code might compile longer, didnt look like anyone else had a problem with it, Or maybe your just jealous cause your on a peice of crap.

PS: My other post wasnt meant to hurt feeling GXD(hehe), just to give background on a question, so I dont think you needed to say anything.(also, that wasnt much of a quick example, more like a novel)

Share this post


Link to post
Share on other sites

  • Advertisement