Is it worth it to build my own engine using SFML

[jamun99]

I'm a Comp Sci major and programming is a passion of mine. So when I first started out on developing my game I thought it would be best for me to just knuckle down and build everything using C++/SFML which I already had experience with instead of using a pre-made engine like Unity or Unreal. Unbeknownst to me this would become a major time sink for my project. There are so many things that I spend days trying to figure out that I feel like would be incredibly simple were I to use a pre-made engine. Things like collision response. I still have zero idea how I should go about implementing that through SFML. I've spent the majority of the last few days of programming thinking about how I'm going to design it, when I feel like collision is a simple no brainer in an engine like Godot.

Beyond that, I'm a one man team, and I'm beginning to think I should cut the workload wherever I can so I can actually get moving with my project. At the rate of progress I'm going now my game won't be released for the foreseeable future.

[binary1248]

The M in SFML stands for multimedia. You shouldn't expect SFML to realistically help you with anything else that belongs in a usable game engine.

You have to ask yourself, what is your goal. Do you want to end up with a game of sorts? Or do you "just" want to gain experience in programming, libraries, and the other 1000 things that engine developers have to care about.

There are some people (myself included) that aren't interested in the game itself but more the underlying technology which is why I enjoy programming and working on libraries even though I never actually end up with anything "shippable" to a consumer. And then there are the other people who really just want to make games that they can show their friends once they are done, this is also a task that shouldn't be underestimated.

The effort that goes into games comprises way more of actual content creation than the raw programming. If you look at teams, you will find way more artists, designers, writers, testers etc. than actual programmers. The programmers do their part of the job writing an engine the rest of the team can work with and the "stuff" that makes the game what it is comes after that. In smaller teams, you will find that each developer will have to fulfil multiple of these roles.

If you really want to do both, you will be doing the jobs that normally rest on the shoulders of multiple people, the workload included. A beginner misconception is that one must write an "engine" if one wants to make a game. This is not true. You write an engine so that non-programmers can also contribute to making the game in their own way. At the present time, if a game is big enough, writing an engine is the only way to realistically ship the game before the budget runs out, spread the work out among many people. If you are a smaller team or even just one man, you have to ask yourself: Would I really benefit from writing an engine considering I will be the only one using it?

Most indie games either use pre-existing engines or if they feel that those wouldn't get the job done as they envision their game they just write the game from scratch. I haven't heard of a small indie team writing an engine first then building their game around it. That just wouldn't be financially feasible. What does happen though is, if the first game becomes a financial success and they decide to write a sequel, they reuse parts of the first game to make the sequel. Would this be some rudimentary form of engine? I wouldn't count it as such. It is just code re-use to me.

TL;DR: Engines are just a tool to help make development of complex projects financially viable. Bigger projects always go in that direction. Smaller/Tiny projects should focus on getting deliverables out the door ASAP however they choose to do it. You have to choose now what you want to have in your hands after 2 years. It won't be both.