Jump to content
  • Advertisement
Sign in to follow this  
Spencer Burd

Beginner Programmer, understands C++ but doesn't know where to start.

This topic is 2115 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 only need a basic walkthrough of how i should go about making a 2D platformer. I would rather go to hell then try and make my first game as 3D. I am not looking to publish. I just want to know i can do it. I just need someone to give me a vague(sort of) (i'll figure out how to) tutorial. Example:


1. Get idea

2. write code

3. implement files

4. music

5. images

6. bugs

7. beta



Preferably going more in depth during 2-5




Share this post

Link to post
Share on other sites

This happened to me aswell! It is a bit frustrating to finish learning C++ and to not no where to go next.


If you are into game development, you need to get into graphic programming. SFML is easy and helpful, it will teach let you create windows, manage sprites, movements, audio, networking..... It's increadibly broad and you can use it with C++ and your compiler. You would have to implement physics on your own though, unless you would want to use a simple game engine such as BOX2D, but definitely get into SFML:




And look up CodingMadeEasy on youtube. He has some good tutorials on iy

Share this post

Link to post
Share on other sites

I believe that the most important thing to do in order to get started on designing a game of any sort is to write out a complete game design document.  Something that explains the mechanics, story boards (if applicable), level progression, character progressions and general flow of events.  This in itself will then give you the questions to ask and provide a guideline of the solutions you will require to achieve your goal.  Your game design document should be fairly large (spanning at least a few pages even for the simplest of ideas.)  You want to focus on defining what the game is completely, imagine that your game design document is being given to someone that know's what a video game is but has never played a platformer, side scroller or 2.5D game.


The key notes you want to address in the game design document are "what platform am I targeting " "what is the game about?" "how does one play the game?" "how does the game start?" "what can the player do?" "what does the player do throughout the middle of the game?"  "how does the game end?"  "why does the character do what he does in the game?" "how do controls work?".  Expand on these with as much detail as possible.  The point behind all of this is that it will start letting you address individual aspects of the design in such a way that you kind of set up a road map all on your own as it relates to you'r project.


Some examples, "What platform am I targeting?" this in itself now gives you the question of "What engine or libraries do I use?  What hardware API is available (Direct X or Open GL) and what should I learn next?"  "How does one play the game?" Will get you to start thinking about how to build your framework to support aspects of your game.  In the idea of a 2.5D sidescroller / platformer you already know that you will be looking at basic collision, basic dual axis (2d) movement systems, running and jumping support.  If it turns out that there will be some beat em' up aspects of the game you know you will need to add in support for combat / attack animations, health, strength and defenses and so on.  As you continue down this road you will start getting to more and more specific questions, questions that later can be answered using a Technical Design Document.  As you go through the process of writing a technical design document you will further narrow down exactly what it is you need and what order you will work on these things for.


In short there is no standard work flow or road map to game development, each game requires it's own unique technologies and functionality.  Granted most games follow a similar path where you start at the bottom building framework that could support the methods and properties you would need to get the game up and running but how you get those going and where you put them is very dependent on what you are doing.  Your game design document and technical design document turn in to your guide on where to go.

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!