Hi,

Let's say I would like to create a pong game or other game (using c++ with OpenGL). When I make the classes for buffers, textures etc...I have to write them while I'm thinking at the game's design.
So my question is: is there a program or something like this, that can help me design the game and after to implement it ?I don't know...maybe something like an UML ?

Thank you!

You can use an existing engine like Unity or Unreal. If you want to strictly create that game in C++ and OpenGL, then you can use those engines to create a prototype and then port it later on to C++/OpenGL.

Hi,

Thank you for your reply. I tried to use Unity and UE4, but I simply don't understand them. I find it more interesting and fun writing my own games from scratch. :)

So if somebody can answer my question, do not hesitate. :D

When I make the classes for buffers, textures etc...I have to write them while I'm thinking at the game's design.

Why?

Textures (and in general rendering) do not care about the game's logic. All the render system needs to know is how to render what it's told to render. If it's being told what to render by a Pong game, or by a radio signal from the Bermuda triangle, all it needs to do is do its job, which is rendering.

If you make Pong, do you think you'll need to rewrite how textures work if you create a Poker game?

Likewise, the game logic doesn't need to know about how textures are implemented. Does your Pong game care about whether or not your rendering back-end is deferred or not, for example?

Think of systems as being independent of each other. To a very large extent, one system can safely be ignorant of how another system works. It's ok for the input system to not know how the audio is played, etc.

When I make the classes for buffers, textures etc...I have to write them while I'm thinking at the game's design.

Why?

Textures (and in general rendering) do not care about the game's logic. All the render system needs to know is how to render what it's told to render. If it's being told what to render by a Pong game, or by a radio signal from the Bermuda triangle, all it needs to do is do its job, which is rendering.

If you make Pong, do you think you'll need to rewrite how textures work if you create a Poker game?

Likewise, the game logic doesn't need to know about how textures are implemented. Does your Pong game care about whether or not your rendering back-end is deferred or not, for example?

Think of systems as being independent of each other. To a very large extent, one system can safely be ignorant of how another system works. It's ok for the input system to not know how the audio is played, etc.

I agree with this and would also like to know what specifically you found hard to understand about Unity and Unreal. Is there a reason you want to write your own games from scratch? Unity/Unreal take care of a lot of the work with rendering and what not, allowing you to focus on the game logic/art aspect of the game.

There are a lot of people here who definitely do prefer to write their own rendering engines instead of using a prebuilt one like Unity/Unreal, for a variety of reasons, so there's nothing wrong with it, just that you will spend more time on things that you may or may not care about depending on what your end goal is. So what's your goal? What do you hope to achieve? That's another question worth answering.

First, I would suggest ditching trying to do it with OOP. For such a simple game you're really asking for way more trouble than its worth, unless this is a class assignment specifically to use OOP, as opposed to just having to use C++.

A game like pong is simple to implement in C, or C++ (or even assembly) but sticking to C features. Once you have your game loop, just check each tick for a change in the paddle locations, update the balls position, and check for collision with either paddle. Then draw both padles and the ball on screen using whatever method (OpenGL, GDI, DirectX).

First, I would suggest ditching trying to do it with OOP.

I disagree here, OOP is quite useful in general, so if you know it, use it. Just keep things simple, don't build big inheritance hierarchies etc.

OOP is very powerful, it's easy to overgeneralize things. Avoiding that trap is also something you have to learn.

@Lactose: Ok, maybe you're right with the textures. But what I mean is in general, for other classes, let's say for buffers, or for example, for the paddles and ball from Pong game. Is there another way to create the architecture for my game ? Maybe I should use a word document or paint and start to thing at the game (make the scheme) and after to create it. :D

@deltaKshatriya: I started one day to learn Unity and I tried to create a script to move an object (which is very very simple I bet) but I couldn't succeed even when I searched on the documentation. I just found difficult this and other things like components or whatever was there.I tried with UE4...I hate blueprints. I tried OpenGL 3.3, I understood it for a beginner and I created Snake with it. :D. You asked what is my goal ? Learning to code in c++, to make a game by myself, not with the help of an engine. And maybe in the future to make applications that create something ( for example an application that creates a skybox or something like this).

@Cwhizard: Like I said to deltaKshatriya, I want to use OOP to get used with it.

But what I mean is in general, for other classes, let's say for buffers, or for example, for the paddles and ball from Pong game. Is there another way to create the architecture for my game ? Maybe I should use a word document or paint and start to thing at the game (make the scheme) and after to create it.

I am not aware of others tools than game-engines that are aimed at general C++ coding, specific for games. Maybe libraries like SFML count, but there are not many.

However, a game is just a piece of software. The only 'weird' thing about it is that its an interactive movie, but you don't see much of that at software design level. As such, just about any general purpose (C++) support tool for writing or designing software works. All that stuff is very much personal, which means nothing is very universally used.

If paint or Word works for you, then by all means, use it. Personally, I just write class definitions, and make some global sketches of the big picture at paper. Just do or try what works.

let's say for buffers, or for example, for the paddles and ball from Pong game

I'm no longer sure what you're asking. Your initial statement was that you needed to think about the game design when making classes for render stuff (textures, meshes, etc.). You seem to agree, now, that this is not the case -- that the game logic and the render setup are separate. (I'm also not sure what kind of buffers you're talking about. If you're talking about e.g. vertex buffers used for rendering, then they do not need to know about paddles, balls, the concept of a Pong game, or anything like that -- for the same reason as my previous post.)

Now, however, you're talking about "in general ... for example, for the paddles and ball from the Pong game". This sounds more like a question on how to structure your game logic and its dependencies. You said you've created Snake -- how did you do things there? What worked and what didn't? Use that as a guide for how to do your Pong game.

If that means creating a UML document, typing something in Word/Notepad, or just drawing boxes on a piece of paper or sticky notes attached to the fridge or whatever else, just go for it. Pong is a very simple game, and you should be able to try a couple of different plans for the logic/structure fairly quickly.

If you're still unsure after you've tried a few different things, post what you've tried and ask for feedback on it. You'll learn a lot more if you try to do things on your own, and the complexity here isn't too horrible.