• Advertisement

Was it a mistake to develop my own engine?

Recommended Posts


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?

Share this post


Link to post
Share on other sites
Advertisement

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.

 

Share this post


Link to post
Share on other sites

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.

Edited by Martin Brentnall

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
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).

Edited by Martin Brentnall

Share this post


Link to post
Share on other sites

To answer your actual question:

You can "almost" do everything in modern engines these days. How you do the thing you want is up to you.

 

To get to your camera example:

You are not forced to create manual cameras in every room - you can make a script which reposition the main camera or create and switch dynamic cameras as needed. But you still could do it manually if needed.

You can place entities manually in the editor, but you can dynamically create them too - its up to you.

 

But there are a lot of impediments which big engines brings with:

- 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.

- Sometimes you have to create weird structures for doing the simplest things

- Its totally over generalized to make any game/app you want and this comes at a prize: Performance

- There may be some features you need which are very hard to implement in unity or unreal, due to some technical directions the engine goes

- Debugging is mostly a nightmare, it may work it may not work...

 

Last year i made a platformer prototype with unreal engine 4, just to see how it is different than coding it yourself. Overall it was a okay experience. I had a lot of "Features gets changed or removed" issues which was throwing me off a lot, but it was fun and the process was much faster than writing everything yourself.

Share this post


Link to post
Share on other sites
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.

Edited by Martin Brentnall

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

My personal biggest headache about modern engines is that they are just insanely gigantic and maze-like to work with. Though I suppose that would be true of any sizeable engine, but you can tell that many hundreds if not thousands of people have layered workaround on top of workaround into a lot of the code. My main experience with UE4 has been spending dozens of hours tracing through code, googling or reading documentation to try and figure out where something I want to change is even defined in the engine code and what methods I have to get at it or override it. Even dealing with blueprint there is a lot of situations you run into where it's something to the tune of "Oh there isn't a node for that, but there is a C++ function buried somewhere that will let you do that! Connect them!"

Convenience seems to be a double-edged sword in many cases, it's quick and easy to do many otherwise hard or time consuming things in the engine due to the robust tools and deep systems set up already for you, but it makes learning it and changing things that don't just work for you right away at the top level a heck of a job.

It's hard to say whether you would have been more productive, personally, I think making an engine yourself of decent design and depth sounds like a great learning experience if nothing else.

Edited by Satharis

Share this post


Link to post
Share on other sites
3 hours ago, Satharis said:

My personal biggest headache about modern engines is that they are just insanely gigantic and maze-like to work with. Though I suppose that would be true of any sizeable engine, but you can tell that many hundreds if not thousands of people have layered workaround on top of workaround into a lot of the code. My main experience with UE4 has been spending dozens of hours tracing through code, googling or reading documentation to try and figure out where something I want to change is even defined in the engine code and what methods I have to get at it or override it. Even dealing with blueprint there is a lot of situations you run into where it's something to the tune of "Oh there isn't a node for that, but there is a C++ function buried somewhere that will let you do that! Connect them!"

Yeish, I get a head ache just thinking about it.  I opened up unity after downloading it for Windows, then I quickly closed it and have yet to open it again.  I dread the day I have to open it and begin the long journey of learning how to manipulate it.

Share this post


Link to post
Share on other sites

So, I've been on a similar journey. Off and on I've been building an engine for about 5 years. Originally in DX11, then ported to DX12, and most recently I've rewrote it from scratch in Vulkan, though I'm just at an early stage now. I think I've learned a lot, and it was a worthwhile experience, but I'm nowhere close to finishing a game after all that time. In that sense, if I wanted to finish a game, I could have done so with Unity or Unreal in much less time. However, I'm sticking with it because I have an original idea I'm not sure can be done right now in the off-the-shelf engines, and I want to give it a shot.

That said, I have evaluated the commercial engines, mostly Unity and some Unreal, as well as quick tests in less popular engines like CryEngine, (the now defunct) Stingray, etc. I've found they all did some stuff well and some stuff not so much. Unity is pretty solid overall, and probably would be my pick if I had to choose one. There are some specific reasons it's not perfect for my project, and I would like a stable Linux editor, but overall it's OK. Unreal looks really nice graphics-wise, but I found the editor to be bloated (it takes forever to load, even on a top-shelf system), and is really unstable. I've had it crash when doing seemingly common things like deleting an asset from the project (and made worse since it takes forever to load up again). One time the crash completely corrupted the project and I was unable to open it again (loading the project itself would crash). Of course, I had a backup, but it still doesn't make me feel comfortable that my project could be permanently corrupted just by removing a texture. Unreal also has limited support for custom shaders, which is fine if you like the "Unreal look", but if you want to do something unique there may be hurdles. The smaller engines I tried have some interesting features but ultimately didn't look significant better than Unity/Unreal. And there is a concern of continued support with the less popular options, like the financial situation with Crytek, or Autodesk shutting down Stingray after like 2 years. That would be really troublesome, for example if you spent 2 years building a game in Stingray only to have the engine maker abandon the project.

However, if your game is fairly generic in the functionality and graphics style, you could certainly do something with Unity or Unreal. In terms of the level editor, you wouldn't be using the engine editor to give to users, rather you would build a custom editor into your game itself. In which case, you can make it simple and user-friendly. Both Unity and Unreal use PhysX, which is pretty decent for most common use-cases. You can use arbitrary convex shapes, though, to your point, Unity used to support concave objects with an older PhysX version, and then Nvidia removed that feature. While you can still simulate concave objects with a set of convex shapes, it would require some rework if you had built your game around this functionality.

In my case, I'm investigating advanced physics solutions using the GPU, and this is a little difficult with commercial engines. While it can be done, it feels like you are fighting the engine in a way when attempting this. For example, in Unity, you could write a physics engine in a compute shader and then render dynamic objects. However, if you do this, it bypasses all the standard material shaders, in which case you lose shadowing, lighting, etc. So you'd have to rewrite the lighting and shadowing yourself and then hope it plays nice with other objects that are rendered normally. Unreal, on the surface, seems better since you have the source code and can make arbitrary changes. However, if you want to update the engine, then you'll have to manually merge those changes every time you want to update, and things could break in unexpected ways. At that point, you would have to have extensive knowledge of the code-base and would probably be capable of writing your own engine.

All that said, if you are making a vanilla game, then the existing commercial engines would probably do fine. They have their pros and cons, but they cut out a ton of work for you on day one. If you are trying to do something more innovative, I think custom engines still have a place. Even if not, working on one is a great learning experience and definitely a solid way to gain some skills. I've gone back and forth over the years (and abandoned and restarted the project several times) but I do think it can be worthwhile in some situations. Good luck!

Share this post


Link to post
Share on other sites
9 hours ago, Satharis said:

Convenience seems to be a double-edged sword in many cases, it's quick and easy to do many otherwise hard or time consuming things in the engine due to the robust tools and deep systems set up already for you, but it makes learning it and changing things that don't just work for you right away at the top level a heck of a job.

I would definitely have this concern with a commercial engine.  I use a lot of Java SWING in my job and even getting that to do what I want can be a pain at times.  For my game editing tools, I developed my own GUI component toolkit in pure OpenGL, and while its certainly a lot more limited than what SWING offers, at least I can always easily get it to do what I want.

 

3 hours ago, cyberpnk said:

Both Unity and Unreal use PhysX, which is pretty decent for most common use-cases. You can use arbitrary convex shapes, though, to your point, Unity used to support concave objects with an older PhysX version, and then Nvidia removed that feature. While you can still simulate concave objects with a set of convex shapes, it would require some rework if you had built your game around this functionality.

The biggest challenge isn't the shapes or detecting the collision, but handling how the game reacts to the collisions.

For example, when the player collides directly with a wall, he normally bounces back from the wall (which is what you expect).

However, if the player "clips" a wall at an convex corner, then I do not want the player to bounce back.  Instead, I want to adjust the player position so that he isn't clipping through the parallel wall of his movement direction, and keep his momentum and movement direction.  The idea is that my game favours the ability of the player to "slide" along walls from a corner rather than bounce away from a corner.

Yes, it isn't realistic, and it might sound a minor detail, but it makes a huge and important difference to the feel of playing the game.

Edited by Martin Brentnall

Share this post


Link to post
Share on other sites
3 hours ago, Martin Brentnall said:

However, if the player "clips" a wall at an convex corner, then I do not want the player to bounce back.  Instead, I want to adjust the player position so that he isn't clipping through the parallel wall of his movement direction, and keep his momentum and movement direction.  The idea is that my game favours the ability of the player to "slide" along walls from a corner rather than bounce away from a corner.

Yes, it isn't realistic, and it might sound a minor detail, but it makes a huge and important difference to the feel of playing the game.

 

You are correct fully bouncing off walls is not the proper thing todo. I have implemented “Collision Detection with Sliding”, but it was a while ago and it’s way past my bedtime so sorry I can’t remember any details, except it was pretty easy todo. IIRC I just had to tweak a couple of functions ... the answer might be nearer than you think.

As for your original question - no I don’t think you made a mistaking implementing your own engine. 

When I tried to understand Quake, Doom, Unreal, Unity ... I struggled to get anywhere but when I got neck deep in my own engine I gained the deeper understanding and insights I previously lacked. Now I can understand those other engines and finally could use them if I really wanted to. I suspect you’d be in the same boat so all is not lost.

So yeah go for it I reckon doing your own engine is great ...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement