• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
TheGh0st

Game programming - Where to start?

8 posts in this topic

First of all, let me say that I found this site very helpful and that I read the article on beginning game programming.

 

OK, so let me begin. Me and my friends have decided to learn C++ in detail (we know other programming langauges, but since we want to create a game in C++, we wanted to learn C++ in detail). We told ourselves to first watch thenewboston's C++ tutorials on Youtube, then read Beginning C++ Through Game Programming and after that study SFML in detail (since our game is going to be created in SFML). We also found some SFML tutorials on Youtube.

 

Altough I read almost every article on Beginning Game Programming, the thing that bugs me is that no one tells you how to actually start creating a game.

 

To clarify myself, when we do all of the stuff above and learn C++ and SFML, so we can write games, we don't know what to do first. Will it be creating a menu, or putting a background image, or importing characters (2D), I don't know.

 

So, that's my question. Can someone write something like :

 

'OK, this is how it should go :

 

1. Create a window for the game

2. Create a background image

3. Create a menu

...'

 

So when we start coding, we don't waste a lot of time figuring out what to do first (menu, background, window, importing characters, collision detection etc.), but we know what to do and use that time to code.

 

Thanks in advance!

0

Share this post


Link to post
Share on other sites
You probably have a grand idea for a game. Don't start with that. Take as much of the functionality you want in your game, but dumb it down. Put that into a simplified version of your game. This will do 2 things: First, you will actually be able to finish it, and second, you will gain the needed experience to write the game you want. I've never used SFML, but I have used DarkGDK. SFML has a forum-- use it. If you need to, study some C++ tutorials/examples and write some of your own. The best advice I can give is "just start programming"!
1

Share this post


Link to post
Share on other sites

I recently submitted an article outlining the steps most common to beginning this process.  Currently it is under review and hopefully will be published on this site soon.  It will be a series of articles, following the steps I follow, that allows me to generate good, clean code and that I can "See" progress, which keeps me motivated.

 

  The First thing you want to do is create a map that outlines the goals of your game.  This will be a small map at first. Then you may want the AH HA effect or "YES" effect.

Create your first image and get it displayed on the screen.  This will be your motivation factor.  A small goal with a big acheivment effect. 

 

  While you think about what to do next, keep on creating your graphic images.  If this is your first game, make it 2D.  It will make concetrating on your game mechanics easier.

Try placing objects on the screen,  Click/Drag and drop these objects.

 

My articles will contain the complete code for a simple 2D game.  Which I hope can become the building blocks for everyone with you question.

1

Share this post


Link to post
Share on other sites

I recently submitted an article outlining the steps most common to beginning this process.  Currently it is under review and hopefully will be published on this site soon.  It will be a series of articles, following the steps I follow, that allows me to generate good, clean code and that I can "See" progress, which keeps me motivated.

 

  The First thing you want to do is create a map that outlines the goals of your game.  This will be a small map at first. Then you may want the AH HA effect or "YES" effect.

Create your first image and get it displayed on the screen.  This will be your motivation factor.  A small goal with a big acheivment effect. 

 

  While you think about what to do next, keep on creating your graphic images.  If this is your first game, make it 2D.  It will make concetrating on your game mechanics easier.

Try placing objects on the screen,  Click/Drag and drop these objects.

 

My articles will contain the complete code for a simple 2D game.  Which I hope can become the building blocks for everyone with you question.

Looking forward to reading that article! You will really be helping us a lot, because even tough we will know a lot about C++ and SFML, we get kinda lost on that question, which is 'Where to start?'.

 

Anyway, I hope your article is going to solve our questions and we were actually planning to make a 2D game, so this is a bullseye!

 

EDIT : Please post a link to your article in this topic, so I can see it right away. Thanks!

 

Thanks again!

Edited by TheGh0st
0

Share this post


Link to post
Share on other sites

I've had the same issue and I'm still unexperienced, so I'm figuring as I go, but I think I can show how I think it's supposed to be... I don't use SFML, so you'll have to know what you're supposed to switch in/out from these notes:

 

- Learn the basic of Win32 programming if you're programming on windows (and even if you aren't, just so you can set up your prototype engine and test it), and OpenGL (or another graphic library)

This is how to create and show a window, menus if it'll be a window game, how to get user messages and such. Most of this is pretty basic and you don't need to know much, since you can create your own menu ingame, etc

Also, the graphic library requirements, like "what do you need to show something on screen?"

Coordinates are the obvious attribute, but there's usually some more stuff you need... if it's OpenGL for example you'll need a VBO's objectID, and a texture's textureID, etc...

 

- Create the Engine Layout: Separate and define where you'll have the Input, Graphics, Resources, etc (classes and functions you know you'll need)

Since I haven't seen many engine sources before, I did sorta like the XNA game engine, my Engine class has an Initialize() that starts up all the stuff required to run, Draw() for the drawing the scene, Update() is where the main game code will be, and Clear() when it's closing down.

There's a bunch more others, but these are the main functions.

Then set up the Engine with the basic Win32 window you have. Set up the basic user commands, such as when the user clicks the mouse or press a keyboard key, you'll send it to your GameEngine to handle.

 

- Create the objects layout

Your game will have objects, and what do they require to run? A position (x, y obligatory, z only if it's 3D), a direction, etc... you'll be growing this as you discover more and more stuff you need.

Stuff like which texture it has, which ID it is, etc.

 

- Create the layout of the Input, Resource, Graphics codes.

Your game engine will handle all win32 incoming messages, and from there you'll send to the appropriate classes, such as "did the user press a keyboard key? what's the code and other info I require? Send it to the InputEngine then", and your InputEngine takes care of saving the states of keys, such as if they're being pressed, released, etc...

Your Resource class should be responsible for loading resources from a file (such as .BMP, .OBJ, .FBX) into your Object class.
Your Graphics class should be responsible for drawing it on the system you've choose, using the info avaliable from the Object classes.

 

- Create the SceneGraph

This is one of the parts I'm currently studying, so it's sorta complicated for me for now... but thinking in a simplistic manner, it's a list of objects you have currently loaded in memory and that will be draw on screen.

 

With this you have the base of your engine ready... now you'll need to figure if your game requires a map editor or not.

A Map Editor is a program that will create resource files for your game.

 

For example, say you have a room (2D or 3D) with a bunch of interactive objects (means the player can interact with them somehow), each has it's own position, values, and states (if it's been interacted already or not for example). They're also images from files such as .BMP, and you won't leave the .BMP files in your game folder so anyone can easily delete/replace them and cause unexpected behavior in your game...

So you need all the data from the original resource files (.BMP, .OBJ, etc) in a format of your own, which will also contain the information your engine requires to build the scene you're building.

In a binary file, it would be something like this:

[objectID 1][name "myDoor"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 2][name "myTable"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 3][name "myBackground"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]

//etc
//actual scene data now
[object 3][background][x, y, z] //background at x, y, z
[object 2][object][x1, y1, z1][actions, events, states, etc] //myTable.bmp at position x1, y1, z1
[object 2][object][x2, y2, z2][actions, events, states, etc] //another table at x2, y2, z2
[object 1][object][x3, y3, z3][actions, events, states, etc] //a door at x3, y3, z3
//"actions", "events", "states" are informations your engine will know what to do with it

And then you'll have your maps ready... you also need to add collision boxes, which are objects that the player/other objects will have collision checks, etc

Your MapEditor is a program that will let you build these informations easier than typing it yourself, unless it's a really simple game, it's inviable to type it yourself... it's basically a program that will put resources on screen, let the user drag and position it themselves, and have some sort of "events/actions/flags" properties, and save this information in a binary file for your engine to read.

 

Then you go back to your game's ResourceEngine, and make it properly load the data from the file and properly display it, filling your Object classes with all information you require.

And finally, in your gameEngine's Update() function, you add your game logic... like checking for collisions (or separate it in another Physics class or function), doing an certain action if the player's close to an interactive object, changing the states of your game such as "Boss 1 killed" (so this will affect something else in your code, such as a door being accessible now, etc).

 

Since you're using SFML, there's plenty of things that you won't have to do, so you'll figure what do you still require and adjust it from there.

 

There might be missing a bunch of things (I haven't mentioned audio for example, or scripts), but I think that's the general idea...

 

 

And I was so happy when I managed to display my first "teapot".fbx on screen, thinking "just a bit more and I can start to build up my game logic!"

...sigh

2

Share this post


Link to post
Share on other sites

I've had the same issue and I'm still unexperienced, so I'm figuring as I go, but I think I can show how I think it's supposed to be... I don't use SFML, so you'll have to know what you're supposed to switch in/out from these notes:

 

- Learn the basic of Win32 programming if you're programming on windows (and even if you aren't, just so you can set up your prototype engine and test it), and OpenGL (or another graphic library)

This is how to create and show a window, menus if it'll be a window game, how to get user messages and such. Most of this is pretty basic and you don't need to know much, since you can create your own menu ingame, etc

Also, the graphic library requirements, like "what do you need to show something on screen?"

Coordinates are the obvious attribute, but there's usually some more stuff you need... if it's OpenGL for example you'll need a VBO's objectID, and a texture's textureID, etc...

 

- Create the Engine Layout: Separate and define where you'll have the Input, Graphics, Resources, etc (classes and functions you know you'll need)

Since I haven't seen many engine sources before, I did sorta like the XNA game engine, my Engine class has an Initialize() that starts up all the stuff required to run, Draw() for the drawing the scene, Update() is where the main game code will be, and Clear() when it's closing down.

There's a bunch more others, but these are the main functions.

Then set up the Engine with the basic Win32 window you have. Set up the basic user commands, such as when the user clicks the mouse or press a keyboard key, you'll send it to your GameEngine to handle.

 

- Create the objects layout

Your game will have objects, and what do they require to run? A position (x, y obligatory, z only if it's 3D), a direction, etc... you'll be growing this as you discover more and more stuff you need.

Stuff like which texture it has, which ID it is, etc.

 

- Create the layout of the Input, Resource, Graphics codes.

Your game engine will handle all win32 incoming messages, and from there you'll send to the appropriate classes, such as "did the user press a keyboard key? what's the code and other info I require? Send it to the InputEngine then", and your InputEngine takes care of saving the states of keys, such as if they're being pressed, released, etc...

Your Resource class should be responsible for loading resources from a file (such as .BMP, .OBJ, .FBX) into your Object class.
Your Graphics class should be responsible for drawing it on the system you've choose, using the info avaliable from the Object classes.

 

- Create the SceneGraph

This is one of the parts I'm currently studying, so it's sorta complicated for me for now... but thinking in a simplistic manner, it's a list of objects you have currently loaded in memory and that will be draw on screen.

 

With this you have the base of your engine ready... now you'll need to figure if your game requires a map editor or not.

A Map Editor is a program that will create resource files for your game.

 

For example, say you have a room (2D or 3D) with a bunch of interactive objects (means the player can interact with them somehow), each has it's own position, values, and states (if it's been interacted already or not for example). They're also images from files such as .BMP, and you won't leave the .BMP files in your game folder so anyone can easily delete/replace them and cause unexpected behavior in your game...

So you need all the data from the original resource files (.BMP, .OBJ, etc) in a format of your own, which will also contain the information your engine requires to build the scene you're building.

In a binary file, it would be something like this:

[objectID 1][name "myDoor"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 2][name "myTable"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 3][name "myBackground"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]

//etc
//actual scene data now
[object 3][background][x, y, z] //background at x, y, z
[object 2][object][x1, y1, z1][actions, events, states, etc] //myTable.bmp at position x1, y1, z1
[object 2][object][x2, y2, z2][actions, events, states, etc] //another table at x2, y2, z2
[object 1][object][x3, y3, z3][actions, events, states, etc] //a door at x3, y3, z3
//"actions", "events", "states" are informations your engine will know what to do with it

And then you'll have your maps ready... you also need to add collision boxes, which are objects that the player/other objects will have collision checks, etc

Your MapEditor is a program that will let you build these informations easier than typing it yourself, unless it's a really simple game, it's inviable to type it yourself... it's basically a program that will put resources on screen, let the user drag and position it themselves, and have some sort of "events/actions/flags" properties, and save this information in a binary file for your engine to read.

 

Then you go back to your game's ResourceEngine, and make it properly load the data from the file and properly display it, filling your Object classes with all information you require.

And finally, in your gameEngine's Update() function, you add your game logic... like checking for collisions (or separate it in another Physics class or function), doing an certain action if the player's close to an interactive object, changing the states of your game such as "Boss 1 killed" (so this will affect something else in your code, such as a door being accessible now, etc).

 

Since you're using SFML, there's plenty of things that you won't have to do, so you'll figure what do you still require and adjust it from there.

 

There might be missing a bunch of things (I haven't mentioned audio for example, or scripts), but I think that's the general idea...

 

 

And I was so happy when I managed to display my first "teapot".fbx on screen, thinking "just a bit more and I can start to build up my game logic!"

...sigh

Thank you for this detailed description. I am surely going to read it.

0

Share this post


Link to post
Share on other sites

Here's the thing: you can read all you want, watch all you want and study all you want about programming. But you're missing one thing: you're not actually doing the coding yourself. How can you really think and understand until you actually confront programming face to face?

 

Programming is a game and a puzzle. It is also about ideas and how these ideas relate to each other and how you can combine the ideas to make something beautiful: a program.

 

For collision detection, you can bound a rectangle against your game character. Then bound a rectangle against your enemy monster. Test these rectangle for intersection. When these rectangles intersects happen, you know a character collided with a monster.  

 

Start applying the concepts you learn even the most basic fundamentals are crucial to making the most basic and simple game. Start writing games that you can actually write.

Edited by warnexus
2

Share this post


Link to post
Share on other sites

The short answer is this: If you learn C++, then learn SFML, then what you start on first will be up to you.

 

The long answer is this: Once you become experienced enough with C++ (if you are learning through video tutorials or books, you'll get good amount of experience), you'll start learning SFML. SFML website has tutorials on how to create windows, graphics, inputs, and sound. Learning and understanding those tutorials will solve your most core question, "Where do I start?" ie. "What do I program first?". Start with what you know and work out the rest. For your first games, doing things like making a menu is not really important. The core game is what is important. And again if you follow the tutorials for SFML, you should be able to get a window, graphics (paddle and ball), and sound (effects and/or music) already up and running. The more challenging parts: physics, collision detection, scoring are what you are going to figure out as you develop your game.

 

I hope this helped.

0

Share this post


Link to post
Share on other sites

Once you have a decent grasp of C++, start on the SFML. Learn it as you go, and just make parts of your game so you can see some visual results to give you encouragement to keep going. The tutorials on the SFML site show you some basics of how to use each piece, so you can build off of that.

 

I hope serapth doesn't get bothered by me going back to this: http://www.gamefromscratch.com/page/Game-From-Scratch-CPP-Edition.aspx

 

His C++ tutorial with some SFML mixed in.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0