Which is the hardest part of making a game?
For larger games, i would say how you organise your code. So many times have i written code and had to rewrite it because some other function/class required the data but could not access it because i did not plan my classes well.
<< It''s taken me about 2 weeks (evenings) just to get a block moving down the screen (never mind key control or collision detection). Mind you, I started with zero knowledge of Win32 so maybe that''s not too bad. >>
Well, my Breakout took a couple days, but that was after 2 or 3 months learning Win32, the basic game loop, and how to draw pixels, rects, and ellipse in GDI....couple of weeks for Tetris is about right, not counting learning Win32.
<< Game programming is bloody hard. I have utmost respect for anyone who can finish a working game! >>
Yeah, its hard if you are just starting out.... Tetris was a little after my time, but Breakout was an easy game I always enjoyed so I started with that....
I''ve been programming for over 20 years, but just learned Win32 this year. I''ve always finished games, even my first ones in Basic for the old Apple II. My goal (and your goal) should always be the finished game.....you learn the most that way.
VazGames.com
Phil P
Well, my Breakout took a couple days, but that was after 2 or 3 months learning Win32, the basic game loop, and how to draw pixels, rects, and ellipse in GDI....couple of weeks for Tetris is about right, not counting learning Win32.
<< Game programming is bloody hard. I have utmost respect for anyone who can finish a working game! >>
Yeah, its hard if you are just starting out.... Tetris was a little after my time, but Breakout was an easy game I always enjoyed so I started with that....
I''ve been programming for over 20 years, but just learned Win32 this year. I''ve always finished games, even my first ones in Basic for the old Apple II. My goal (and your goal) should always be the finished game.....you learn the most that way.
VazGames.com
Phil P
For me, the most hard part is choosing which type of game to make. Kindof like the VERY early design...
1: Choose a really simple game, say missile command, then rush to get it finished, just to get it done, because I am now bored with the whole idea.
http://www.davesprogramming.com/section_games/MissileCommand.exe
Or...
2: Choosing to make a game that's too complex for me and getting about 15-25% through it, realizing that I've bitten off more than I can chew (Realtime, empire space management, for example)
http://www.davesprogramming.com/section_codebin/StarSupremacy.zip
(Just thought I'd add the links in so you can see how bad my stuff is... IE "Got bored" or "Too complex"
[edited by - TerraX on November 28, 2003 4:59:23 AM]
1: Choose a really simple game, say missile command, then rush to get it finished, just to get it done, because I am now bored with the whole idea.
http://www.davesprogramming.com/section_games/MissileCommand.exe
Or...
2: Choosing to make a game that's too complex for me and getting about 15-25% through it, realizing that I've bitten off more than I can chew (Realtime, empire space management, for example)
http://www.davesprogramming.com/section_codebin/StarSupremacy.zip
(Just thought I'd add the links in so you can see how bad my stuff is... IE "Got bored" or "Too complex"
[edited by - TerraX on November 28, 2003 4:59:23 AM]
The hardest part for me is making the design and technical documents. But definately the most boring part is debugging (you know, those really annoying bugs that take you 2 days to figure out it was just that you didn''t initialise your image class before you passed it to a constructor *shifty eyes*).
quote:Original post by GamerSg
For larger games, i would say how you organise your code. So many times have i written code and had to rewrite it because some other function/class required the data but could not access it because i did not plan my classes well.
Definitely code organization. Rewriting and refactoring your code is the most difficult and time consuming activity in any programming project, regardless if it''s game programming, or not.
I haven''t generally made a game in a team project before. Usually just by myself, which it seems happens to a lot of new developers.
That said, I find the actual design kind of tough, especially as my current finished projects have been simple and spaghetti code (before I learned about programming formally, I hacked on the Apple II C+ with Applesoft BASIC).
I have little to no experience in designing software. It is one thing to design the game rules on paper, but to design the software itself is a bit daunting. You want to make sure you do it right and all. Of course, getting it done is always more important. B-)
I am sure in a team situation that communicating what you want others to do is hard. As you increase the number of people on a team, the number of lines of communication increases by a factorial. N team members means N! lines of communication. 3 members = 3*2*1 = 6 lines, while 4 members = 4*3*2*1 = 24 lines.
Naturally it is possible to produce teams so that only managers need to communicate, but those manager still need to communicate to their teams, each member of which has to be sure of what is needed. My idea of what the physics code should do in a specific situation is not the same as what your idea might be. We have to make sure we can communicate without ambiguity.
So, design and communication are hard. Design if you''re by yourself, communication if on a team...of course, communicating to yourself what you want is a good way to determine what problems you''re having.
Has anyone had the experience of going to someone to ask about your code, explaining to the person what your problem is so well that you discover a solution before the other person has a chance to respond? Happens to me all the time. B-)
That said, I find the actual design kind of tough, especially as my current finished projects have been simple and spaghetti code (before I learned about programming formally, I hacked on the Apple II C+ with Applesoft BASIC).
I have little to no experience in designing software. It is one thing to design the game rules on paper, but to design the software itself is a bit daunting. You want to make sure you do it right and all. Of course, getting it done is always more important. B-)
I am sure in a team situation that communicating what you want others to do is hard. As you increase the number of people on a team, the number of lines of communication increases by a factorial. N team members means N! lines of communication. 3 members = 3*2*1 = 6 lines, while 4 members = 4*3*2*1 = 24 lines.
Naturally it is possible to produce teams so that only managers need to communicate, but those manager still need to communicate to their teams, each member of which has to be sure of what is needed. My idea of what the physics code should do in a specific situation is not the same as what your idea might be. We have to make sure we can communicate without ambiguity.
So, design and communication are hard. Design if you''re by yourself, communication if on a team...of course, communicating to yourself what you want is a good way to determine what problems you''re having.
Has anyone had the experience of going to someone to ask about your code, explaining to the person what your problem is so well that you discover a solution before the other person has a chance to respond? Happens to me all the time. B-)
To make the game fun...
So true!!!!
Get too into the technical side, forget about the fun part!
The fun part, is err, the fun part afterall!
Actually making a game!
That's the part I find hard!
"Making the game"
Programming is tuff in places (Well most actually, lol)
But making the game! I forget to do it, too busy programming!
Have to switch mindsets, I've learnt a lesson, thank you MickePicke!!!
(Perhaps I don't PLAN/DESIGN enuff?)
[edited by - TerraX on November 28, 2003 4:58:24 AM]
So true!!!!
Get too into the technical side, forget about the fun part!
The fun part, is err, the fun part afterall!
Actually making a game!
That's the part I find hard!
"Making the game"
Programming is tuff in places (Well most actually, lol)
But making the game! I forget to do it, too busy programming!
Have to switch mindsets, I've learnt a lesson, thank you MickePicke!!!
(Perhaps I don't PLAN/DESIGN enuff?)
[edited by - TerraX on November 28, 2003 4:58:24 AM]
As a hobby game maker, the hardest part of making a game is the part where you run into several surprising problems and you dont find solutions easily thus breaking flow of development or you just get tired. Soon you start loosing interest in the project. Thats why many of my projects are unfinished.
My advice: dont make games alone.
My advice: dont make games alone.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
