Advice on "actually" making games with SFML?

[hass5]

I'm kind of stuck when it comes to gamedev. I use C++/SFML.

One of my problems is that river online casino my attempts at making a game always go like this:

Have some vague idea about a game.

Draw some designs and flesh out the details.

Open up VS and start programming.

Once I get a window up and some sort of game object/entity system, I start piling on features.

Eventually, everything gets so messy and poorly designed that I can't continue. Oftentimes I will drop a project, come back to it months later and realize the existing code is impossible to work with. Furthermore, it seems by using a low level framework there is always way too much to get done before its a "game" and not just some hunk of code. For each "game" I have to work out a some system for animations, GUIs, scenes, etc.

I know that that last particular issue is probably to be expected in using a framework like SFML. I arrogantly stick to SFML, however, because I'm not comfortable with using a large engine like Unity.

[Paul]

Make a simple game engine with managers, scenes, GUI.. and create the own tools (simple animation system, GUI) or interface for existing tools like Spine, parcticle editors. You can improve anything in next project.

You can use another languages than C++, with readable syntax, that allows you to think more globally and which are more bulletproof.

[Nexus]

I somewhat disagree with the approach of writing the engine first and then the game. You end up inventing a lot of features you don't need, while missing several you do need. Trying to extract and generalize components from a working game can be more organic, even if it comes with some refactoring. Plus, it won't leave you working for months on an engine without doing any progress game-wise.

Now how to get to a working game? You're talking about piling up features, which may bring you closer to your goal in terms of visible progress, but it comes at the cost of accumulating technical dept -- the messy code that you yourself don't understand after some time. At the risk of sounding obvious, you need to count in extra time that will be spent just on refactoring and cleaning up -- that is, functionality is kept exactly the same, but code structure and organization is improved. If you're doing it for the first time, it can be helpful to be strict about this: don't try to add even the slightest game-related feature while doing refactoring; make sure that the playing/running experience is exactly the same.

Refactoring and robust code architecture is a huge topic on its own, and there are libraries full of books about it. Delving into some research would definitely give you a nice overview (there's also a bunch of Internet resources, e.g. about design patterns). Apart from that, you should probably investigate your own code and ask the question "why is it messy?". What are the patterns that make it hard to understand? Once you found that out, look for solutions about these problems, one by one. For example:

• Lots of duplicate code -> reuse code in functions, classes, templates
• Too many dependencies between different parts (e.g. graphics, game logic, input) -> split your application into modules, and limit interfaces between modules to a single class/interface
• Doing a lot of algorithms/data structures/for loops by hand -> check out STL and other C++ libraries

Having said that, there are some extensions to SFML that may make it easier to use certain features without starting from zero. I wrote the library Thor, which contains particle systems, animations, vector algebra among others. There are other snippets and libraries listed on the SFML Wiki.

[rileyman]

This may or may not apply to your situation...  What's helped me get focused on getting back into game development recently is simply limiting the scope of my first few projects.  I finished a simple Pong game, added some game options to it.  Now I'm moving to the classic "Snake" game.  Each new project will get a little more ambitious -- and hopefully put me in a better position as I build up a code base, design experience, etc.

In my first go of things (in the 90s and early 2000s), I was no stranger to what you're describing -- starting something, getting part-way, and finally giving up and letting other pursuits take over.  My past ten years I'd let work (I'm a web application developer) sort of take over.  Hopefully my recent strategy of just getting some simple games *done* will take hold...

(And while I'm here... hello SFML forums!  Just getting started with SFML!)