testEngine

[paupav]

Can anyone give me review on this basic game engine, and tell me if I'm on the right path or should I abandon it and start writing new one.

https://github.com/paupav/testEngine

[FRex]

There is almost nothing in there...
Also - you shouldn't use sf::RenderWindow as a global, bad bugs tend to happen because globals get constructed and destructed in weird order and sf::RenderWindow is sensitive to that so it shouldn't be global.

[Hapax]

I was going to mention the empty files and the globals but FRex beat me to it 

Also, don't mix events and real-time keyboard states, as in windowFunctions::userRequested()

[paupav]

There is almost nothing in there...
Also - you shouldn't use sf::RenderWindow as a global, bad bugs tend to happen because globals get constructed and destructed in weird order and sf::RenderWindow is sensitive to that so it shouldn't be global.

can i make it global pointer?

[Nexus]

You should find a design that works without global variables.

And I don't see the purpose of the windowFunctions class. Shouldn't it be either a wrapper around sf::RenderWindow or a namespace with a collection of global functions?

Also, what is a "test engine"? What do you actually want to achieve? Don't just write engines because you can, a lot of people have wasted their time this way.

[paupav]

This is just hobby project. I've decided that i will create new .cpp file named window.cpp and put every function in it.
Thanks everyone for your time!

[Glocke]

Also, what is a "test engine"? What do you actually want to achieve? Don't just write engines because you can, a lot of people have wasted their time this way.

Previously, I was completly ignoring those kind of hints. But today I know Nexus is right! If you want to split between engine and game, that's fine. But try to focus on game development - building an engine is just a side-product of a well-designed game. And your (first) game won't be perfect.. So write a game in the style you want and don't try to build a most-flexible engine for any possible purposes.

[paupav]

Okay, I've thought that by making sf::Window global, but using its functions in just one cpp file I would be able to avoid "weird construction and deconstruction" , but it seems that I’m having same bugs (when I change from Fullscreen to Windowed window is hidden).
https://github.com/paupav/testEngine/blob/master/window.cpp

Can anyone suggest me any design that doesn't include global variables (other than SmallGameEngine , I find its design complicated ).

[Nexus]

We can't tell unless you answer your questions: what do you want to achieve? A design for what?

As stated by Glocke, developing an engine for the sake of itself is pointless. You should know what you need it for, i.e. what problems it solves and for what kind of game it can be used. I'd highly recommend spending some thoughts about the design before writing code, otherwise you'll be refactoring all the time. A typical engineering approach could look as follows:

• There is a certain problem to solve.
• You think of possible solutions to approach the problem.
• You compare the solutions and find advantages and disadvantages of each one.
• You decide on one solution and implement it.
• Mistakes you make along the process will help you know better in the future.

You've stated that it's a hobby project, and of course you can learn valuable things while developing, but I would still try to have a clear idea of the results, in order to not waste my time. A concrete game will not only give the project a meaning, but it will also determine its design -- you'll know what the game needs, thus you can provide appropriate APIs in the engine.

These things can appear very difficult if you do not already have some experience in game development and C++, and I personally consider it a bad idea to write a game engine if that's the case. Keep also in mind that a lot of game engines have not emerged as a stand-alone product, they are the result of outsourcing functionality from a concrete game, in an attempt to make it more generic and reusable.

[paupav]

Okay this is my idea:
Game engine that would have simple menu, in which you can alt + enter to make it fullscreen or windowed, that you can minimize it ( I'm talking about features that are not supported by default on the Linux), in the game create variable Vector2i called gameDrawingFrom that would hold x and y coordinates of the window plus space on the left, minus space on the right and y would hold y+ [space on the top], + space on the bottom, size of those spaces (margins) would be resolution of loaded image/s ( HUD's ) on which I would write/draw stuff like players lifes, players name and stuff like that on it.

I need something that would replace my global variable idea of handling window outside of the only one function. Any other way of calling e.g window.draw() in the function in which sf::RenderWindow wasn't declared that wouldn't produce bugs.

[Glocke]

I need something that would replace my global variable idea of handling window outside of the only one function. Any other way of calling e.g window.draw() in the function in which sf::RenderWindow wasn't declared that wouldn't produce bugs.

To avoid global variables, I'm using an "Engine"-class which holds my sf::RenderWindow as private member. The window is created within the constructor. Later, I invoke "run()" to start the mainloop. This mainloop trigger's my gameobject's render()-method and obtains a reference to my window as "target". So I can invoke draw()-calls inside my gameobejct's render-method using my window - without having it as global variable. This approach can be easily enhanced by using some kind of state machine inside your application design.

Another approach could use a singleton. Imagine you have an Engine-class. It's constructor creates your window (and additional stuff you may need). When working with a public sf::RenderWindow reference (meant as public attribute inside the Engine-class) you can easily access it where ever you have an instance of your Engine. Now you might face the problem to have the instance available where ever you need. Here the singleton pattern might be one solution. Of course there are multiple solutions - and the singleton pattern isn't really famous. But in my opinion, it's a satisfying compromise between global variables and object-oriented programming. If you never heard about singletons: http://gameprogrammingpatterns.com/singleton.html seems a great resource to me.

Just one thing about so-called "Design patterns": They are possible solutions to problems. If there's no problem, there is no need for such a solution. Don't try to put as many of them inside your application as possible.. It won't help you, increases complexity and slows down your entire progress (because of the complexity).

/EDIT:

Keep also in mind that a lot of game engines have not emerged as a stand-alone product, they are the result of outsourcing functionality from a concrete game, in an attempt to make it more generic and reusable.

As was as minor parts @paupav: That's why I'm going to outsource my statemachine-approach in some days and add it to my "outsourced stuff"'s repository at github. If you want to browse the code (it it's ready) feel free to message me.

[Nexus]

A singleton is only superficially better than a global variable and does not solve most of its problems. See also here. Avoid the Singleton pattern whenever you can, and don't just use it because it appears convenient in the beginning.

In case you're interested in my general view on C++ design, you could have a look at this post.

[Glocke]

A singleton is only superficially better than a global variable and does not solve most of its problems.

In my opinion it's a first step away from global variables without the disadvantage of writing a pure static "non-global"-faking class. But you'r right: To think about different strategys is more important than just picking the next-suitable approach.

So I think my first approach should be more suitable / or at least a inspiration for searching a really suitable solution.

[eXpl0it3r]

There's no sense in doing bad things first and then maybe one day do it right. Do it right from the beginning and you'll learn more and move on faster.

[Glocke]

There's no sense in doing bad things first and then maybe one day do it right. Do it right from the beginning and you'll learn more and move on faster.

Right now, you inspired me to remove my singletons by changing my architectural basics (currently resource caching is done via singletons, yet).