So I've been working on-and-off for several years on my hobby project.  The project is around 90% complete.  It includes a game, a level editor, as well as a general tool for adding/modifying game objects and mechanics.  The engine also supports plug-ins that allow new functionality to be added via DLL's.

Although I'm happy with what I've accomplished so far, I sometimes have this nagging feeling that I could've accomplished everything so much quicker if I'd used Unity or Unreal instead of starting from scratch with C++.

There were a few factors to my choice:

My biggest concern was uncertainty that an existing engine would give me the flexibility to do everything I wanted, especially the level editor and engine tools.  I think it's fair to say that engines like Unity and Unreal are proven for developing games, but it's not clear to me if this also applies for non-gaming applications like level editors?  The tools are a very important aspect of my project because one of the primary objectives is to encourage creativity in players, including non-programmers (ideally, I want the level editor to be accessible enough that even a child can use it).

I also had some concerns over how much control I'd have over the precise functionality of an game itself.  For example, collision detection is usually talked about in terms of cuboids and spheres, but this wouldn't have allowed me to get the exact feel I wanted in my game, and I have no idea how much leeway an engine like Unity would give me to customise something like that.

I'd hate to invest months in learning an engine only to find that it can't do something I need.

Now, with all that said, I should probably confess that I don't really know anything about modern game engines.  I pretty much mastered the Build engine map editor (Duke Nukem 3D, etc.) in the 90's and I dipped my toes deep enough into UnrealEd to make a few decent deathmatch maps for the original Unreal, but I literally haven't touched any game engine tools since then.

My only exposure to Unity comes from reading a blog from a developer who was working on a similar project.  Unfortunately, that blog seemed to confirm some of my fears about using an engine like Unity.  Perhaps that wasn't a fault of Unity; maybe the developer didn't have enough experience or just didn't care about doing things in the best way.

So I wonder what your thoughts are on this?  I'm too deeply committed to my own engine at this point to change, but I often wonder how things would've turned out if I had opted to use an engine such as Unity or Unreal.

I suppose at least I've gained some good experience from developing my own engine!

So what do you think?  Could I have done better with an engine?

Tho points you listed are probably the wrong arguments to develop a custom engine.

It's extremely unlikely your tools are more productive than what Unity/UE4 offers.

Those engines use Physx, which can handle arbitary collision shapes, not just spheres or cubes.

Proper Arguments would be:

No licensing fees or other costs (but development cost).

Highest performance

Custom requirements / tech that those engines neither have nor would be easy to add.

But as you do this as a hobby, you usually do it to learn. Also if everybody would use just Unity etc technical progress would be achievable only by the few people that work on this.

My collision detection problem isn't only related to shapes, but also the way I need to define reactions to collision in very specific ways that don't necessarily correspond to real-life physics or other games.  I have no idea what kind of flexibility PhysX offers for doing that, or how easy it would be to get the exact behaviour I want.

Regarding tools:  My objective is to create tools that are intuitive and easy enough to encourage creativity in non-technical players, not to rival commercial engines in terms of possibilities and professional productivity.

In an ideal world, my editing tool wouldn't look out of place on a games console, so it would be something more along the lines of LittleBigPlanet's level editor (although a lot simpler of course) rather than Unity, though I'll admit that it's still a fair way off from that.

I still don't have any insight into how capable tools like Unity/UE4 are for developing such tools like level editors, etc..

Of course, one thing I keep forgetting is that Unity/Unreal didn't even have editors on my development platform when I started working on this project, so I didn't really have as much choice back then anyway.

Makes sense. Usually you can use just the collision detection of a physics engine, but if this physics engine is abstracted behind a game engine this becomes maybe more cumbersome. (It's possible e.g. to replace PhysX entirely with Newton in Unity, but exposing everything to managed code is some work.)

If you release your tools to the community so they can create custom content, i would say that's a very good reason to use a custom engine.

I don't know enough about those engines to further comment, but personally i think it's very good what you've done and you should not regret it.

15 hours ago, JoeJ said:

It's extremely unlikely your tools are more productive than what Unity/UE4 offers

This is not entirely true! It depends on a bunch of factors to say that and we do not know about. Even experienced Unreal/Unity developers have points where they wish one for another or a second solution, thats why people write tools and do not stop for inventing new technology to use the existing one. Thats like saying

Quote

You dont need something like Toyota or Skoda, just drive Mercedes or VW

Fact: Unity and Unreal are made for general purpose not for some special cases so you will always have some edge-cases where a nother solution would fit better or a function isnt implemented you need. It is true that non-code content creation has become more important to game developers and designers (at least from the indie aspect) and it is also true that Unreal's Blueprints beats Unity but Unreal has also some other drawbacks like heavy startup time and the fact that new Unreal versions dont override old ones so you need parallel installed Unreal versions for different project versions.

There are also aspects they do not even touch. Both Tools dont have support for story design and content driven game design, thats why tools like Articy Draft exist. I also very like Unreals shader editing tool but dislike for example how the UI is structured in general.

To come back to the question; I dont think you waste time for doing a custom engine from scratch as I do the same too. You have learned about what you have done and this is the most important point in my opinion, that you will benefit from and people arround the world that also think of making an own game engine is worth the work. Take a look at the Urho3D community for example.

I quit here because there are already good posts on GameDev discussing the pros and cons for driving your own engine so you might be interested in what other people's reasons are

1 hour ago, Shaarigan said:

To come back to the question; I dont think you waste time for doing a custom engine from scratch as I do the same too.

I guess the title question was somewhat hyperbolic; I never really doubted my decision to develop my own engine and tools, even if only for the experience I've gained from doing it.  I guess the question I was really interested in is what could have been had I decided instead to an engine like Unity or UE4, since I am so out of touch with modern game engines.

What I read of a developer blog regarding Unity seemed quite off-putting.  The developer was manually placing cameras in all the rooms of his game, then setting up triggers to change the active camera upon the player entering each room.  In my engine, I just defined a "Room" object type, then wrote a short script to automatically reposition the camera when the player enters based on the location and size of the room.

I can't imagine having to do all that manual set up every time I create a new room, let alone imposing that necessity on end-users of my level editor!

That said, I have no idea if that was a limitation of Unity, or just a develop who lacked experience or just didn't care enough to implement a better way.  He also ended up switching his project to UE4 later, so presumably he stumbled upon some obstacles in Unity (I don't remember if he gave a specific reason for switching).

25 minutes ago, Finalspace said:

If one feature gets removed for whatever reason - you are screwed. You can either use the old version forever or implement that feature back when you get the sources or fully implement it in a independent way.

To be fair, I've found that this can happen when developing my own engine too.

For example, I'm facing the possibility that the scripting library I'm using in my engine might not work for much longer.  It hasn't been officially supported or maintained since 2010, and some recent updates to my system have caused the compiler to start throwing up errors when the library is included.  It's lucky I was able to find an unofficial fork that worked, because I wouldn't know where to begin if I had to maintain or fix that library myself, and the alternative libraries I've looked at in the past didn't look as nice to me.

Another example is that my code still uses a lot of deprecated OpenGL functions like glBegin, glVertex2f, glEnd, etc..  I could update it, but I'd rather my spend time getting my project finished on the old version of OpenGL first rather than rewriting existing code to use a new API.  I know that I'll need to do it eventually though.

2 hours ago, Martin Brentnall said:

Another example is that my code still uses a lot of deprecated OpenGL functions like glBegin, glVertex2f, glEnd, etc..  I could update it, but I'd rather my spend time getting my project finished on the old version of OpenGL first rather than rewriting existing code to use a new API.  I know that I'll need to do it eventually though.

Ouch, have you tested on AMD GPU? They're really slow with that stuff.

I haven't tried on AMD; my current system has an nVidia GT660.

I don't think performance will be a huge issue in my game though; the graphics are so simple that it's fully playable even using a software implementation of OpenGL, running on a CPU that's five years old and wasn't even very expensive when it was bought.