I am a competent C programmer and I know OpenGL ES 2.0 fairly well. I'm not so much a newbie, I am just confused on where to start. Do I design everything before getting started programming, or vice versa?
2
8 replies to this topic
Sponsor:
#2 Members - Reputation: 2766
Posted 07 October 2012 - 07:31 AM
Waterfall? Agile? There is an entire field of study investigating the answer to this question. Many people have the correct answer in exchange for your money, or are willing to convert you to their one true religion. The correct answer depends on the beliefs of the person controlling the capital for your project.
Stephen M. Webb
Professional Free Software Developer
Professional Free Software Developer
#3 Members - Reputation: 1052
Posted 07 October 2012 - 08:20 AM
Design as much is practical for your experience and the task at hand. Its all to easy to let your inexperience overwhelm you by getting caught up in the never ending rabbit hole of trying to anticipate and over-engineer each and every need down to the last detail but without actually getting anything done (analysis paralysis). Don't fall into this trap, there is a lot of merit to just getting things done and to hell with best practices when you're taking your first steps. It's good to get things wrong to truly understand why people do things the "right" way rather than blindly implementing what you've read are best practices without ever really understanding why.
Once you've seen your project through you can reflect on what you did right and wrong and what areas to research and design decisions you'll make for the next project. Follow some pong making tutorials, game from scratch tutorials, follow some GL tutorials to make some tech demos and so on. Keep incrementing the challenge of your projects to keep you out of your ccomfort zone whilst keeping things realistic and attainable. Rome wasn't built in a day, as they say
Once you've seen your project through you can reflect on what you did right and wrong and what areas to research and design decisions you'll make for the next project. Follow some pong making tutorials, game from scratch tutorials, follow some GL tutorials to make some tech demos and so on. Keep incrementing the challenge of your projects to keep you out of your ccomfort zone whilst keeping things realistic and attainable. Rome wasn't built in a day, as they say
#4 Crossbones+ - Reputation: 5159
Posted 07 October 2012 - 09:15 AM
No need to complicate things; just start programming.
If you are not sure what to program, think about it and then program. Either way, just program.
L. Spiro
If you are not sure what to program, think about it and then program. Either way, just program.
L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
#5 Members - Reputation: 1413
Posted 07 October 2012 - 10:39 AM
Well, yeah, I agree with L. Spiro in her advice in this case.
You have a head start with C, so get a general direction and get to work on simple game programming now. Game design is an important part which will evolve in your mind as you progress later.
Both GeneralQuery, Spiro, and me are encouraging you to use your strength which is programming and not get overwhelmed with the art aspects in early stages of growth. When and where the time comes to design, you will know it based on need and naturally fill that need. Much can be done in programming until design is needed. Get an understanding of how games are fundamentally structured, then you will be ready for the design aspects.
Clinton
You have a head start with C, so get a general direction and get to work on simple game programming now. Game design is an important part which will evolve in your mind as you progress later.
Both GeneralQuery, Spiro, and me are encouraging you to use your strength which is programming and not get overwhelmed with the art aspects in early stages of growth. When and where the time comes to design, you will know it based on need and naturally fill that need. Much can be done in programming until design is needed. Get an understanding of how games are fundamentally structured, then you will be ready for the design aspects.
Clinton
#6 GDNet+ - Reputation: 1105
Posted 07 October 2012 - 01:46 PM
100% agree with Spiro. If you dont know where to start, just think about a simple aspect that you can easily describe and get started on it.
A.
Lotus RPG Engine - My Journal: http://www.gamedev.n...die-rpg-engine/ |
Action RPG In development using XNA 4.0. | Blog in English: en.lotusrpg.com.br |
Personal blog In Portuguese: lotuzgames.wordpress.com |
#7 Members - Reputation: 423
Posted 07 October 2012 - 03:23 PM
As far as beginner development goes, set your sights on a vision that's rather simple. Include a few simple key features in the initial 'design' and then improvise with what you already know and/or can find with a quick google search for clues and hints on general approaches to the implementation of various aspects of a project.
My early days consisted of simply producing something interesting, regardless of code quality. Just get it to work! After that you'll see how and why you made certain decisions, which reveals what you can do differently in terms of streamlining your development process and technique and improve the overall quality of future projects and their performance.
I start with my project's main function, and the core initialize/loop stuff, then slowly bleed into platform-specific stuff (whether its native win32 or utilizing a platform abstraction library like SDL/SFML) and user-input.. venturing into rendering and entity systems, then networking.. That's a very rough sketch of how I used to do things. Once you're there, it's the same as when you start, you'll always be seeing what you can do different/better. Each project I create is essentially a refactored version of a previous project, refining my overall scheme with each iteration.
Tutorials are all very good starting places, just do your best to put together gained knowledge into something concise, and focus on more advanced program design as you become more aware. I've been doing this as a hobby for 15 years and still don't know *everything*, if there is such a thing.
My early days consisted of simply producing something interesting, regardless of code quality. Just get it to work! After that you'll see how and why you made certain decisions, which reveals what you can do differently in terms of streamlining your development process and technique and improve the overall quality of future projects and their performance.
I start with my project's main function, and the core initialize/loop stuff, then slowly bleed into platform-specific stuff (whether its native win32 or utilizing a platform abstraction library like SDL/SFML) and user-input.. venturing into rendering and entity systems, then networking.. That's a very rough sketch of how I used to do things. Once you're there, it's the same as when you start, you'll always be seeing what you can do different/better. Each project I create is essentially a refactored version of a previous project, refining my overall scheme with each iteration.
Tutorials are all very good starting places, just do your best to put together gained knowledge into something concise, and focus on more advanced program design as you become more aware. I've been doing this as a hobby for 15 years and still don't know *everything*, if there is such a thing.
#8 Members - Reputation: 638
Posted 09 October 2012 - 06:42 AM
When I was young I was always starting by what you see first when you launch a game : the menu.
when you don't know how to start, start where it starts
then the menu becomes a bother because it takes you click/enter steps to go to where you want to test, so you can put a command line switch to disable it.
when you don't know how to start, start where it starts
then the menu becomes a bother because it takes you click/enter steps to go to where you want to test, so you can put a command line switch to disable it.
#9 Members - Reputation: 3283
Posted 09 October 2012 - 08:48 AM
Yeah, chime me in on the just start programming school of thought.
I am a big advocate of design, a proper design can save thousands of hours of work and be the difference between success and failure.
That said, you need to know what the hell you are doing before you can create a proper design.
Generally when I am approaching a new subject or API, I create a pie in the sky project, where I just start coding and try to figure things out. I generally don't even bother reading the manual/instructions, unless I run into a problem, and I just code. Think of this like an artists rough sketch before beginning their masterpiece. It's through this learning process I learn the ins and outs and various problems that I need a solid design for in the first place.
However, this code is *ALWAYS* throw away. Even if I end up re-using 90% of it, I always start from scratch on an actual process. Sure, I will cut and paste from my "sketch", but that's about it.
I am a big advocate of design, a proper design can save thousands of hours of work and be the difference between success and failure.
That said, you need to know what the hell you are doing before you can create a proper design.
Generally when I am approaching a new subject or API, I create a pie in the sky project, where I just start coding and try to figure things out. I generally don't even bother reading the manual/instructions, unless I run into a problem, and I just code. Think of this like an artists rough sketch before beginning their masterpiece. It's through this learning process I learn the ins and outs and various problems that I need a solid design for in the first place.
However, this code is *ALWAYS* throw away. Even if I end up re-using 90% of it, I always start from scratch on an actual process. Sure, I will cut and paste from my "sketch", but that's about it.
