The game began life in 2005 as a simple OpenGL learning exercise to render a static game scene, just to see if I could do it.  The result was satisfying, and a desire to create more scenes fuelled the development of a crude editing tool, which was quickly followed by the creation of a complete game map.

Not wanting the map to go to waste, I started adding gameplay elements and logic to turn it into an actual game: player character, enemies, physics, collision detection, game logic, etc..  I didn't have much game development experience, but as a CS student, I was able figure out most of what I needed to do.  By 2006 I expected to release the finished game and map editor within a year.

2007 went by and my expectation proved to be overambitious.  I was still getting to grips with good C++ practices, design patterns, OpenGL, etc., let alone wrapping my head around physics and collision detection.  Performance was another issue; many optimisations were necessary to achieve an acceptable framerate during gameplay.

By 2009, the project began to resemble a playable game, if only for the few seconds that it lasted before something inevitably went haywire:  The player character glitched through map geometry, wandered along invisible surfaces that shouldn't exist, or the game just froze or crashed outright.  The project was a mess and I was struggling to make it work.

Aside from the game itself, the map editor hadn't been developed much beyond the crude editor from 2005.  As a child, I loved level editors, so giving players a creativity tool felt like a vital aspect of the project, but there was still much to be done if that were to happen.

Aside from these struggles, my ambitions grew and I started to feel dissatisfied with the rigid design of the project.  I'd seen so many hobby games released over the years that seemed to be forgotten within a week or two, and that's not what I wanted for my baby.  The game and map editor were no longer enough; it had to be a set of flexible and reusable components for long term use on multiple games that would enable players not only to build maps, but also to add custom assets and game logic.  Nothing could be hard-coded; everything had to generic and configurable.

The dissatisfaction and struggle lead to what I did next:  I scrapped the entire game and started again from scratch.

That's not to say four years of work had gone to waste; it was a great learning experience, but it was also clear that I needed to go back to the drawing board and rethink some of the more complex topics like optimisation, collision detection, physics, etc..

One of the first ideas for the new version was an engine design with a plugin framework for game components and logic.  I hadn't done anything like this before, so seeing game objects from one module interacting with game objects from another for the first time felt like magic.  But I still had a lot to learn, and the original design had some critical flaws that required a lot of reworking to make it fit-for-purpose.  It was yet another learning experience.

Similar learning experiences occurred numerous times over the years since as the overall engine design was continuously refined and improved.  For example, scripting support was added to replace C++ game logic, interfaces were created, removed, and improved to improve generalisation and flexibility.  It was always deeply satisfying to see a rigid component made generic, even when it added nothing new to the actual game.

It was 2015 before I began to feel that the end was in sight, but my optimism seemed to come and go in waves.  Sometimes I was certain that the end was within reach, yet other times I felt that I was doomed to work endlessly on a project that would never reach fruition.  Sometimes I went weeks or even months without touching the project.

Now it is 2018.  The game can be played from beginning to end without any crashes or glitches.  There are still a few small but essential features to be done, but otherwise the game is entirely playable.  Furthermore, the components of the game can be configured far beyond the requirements of this one game, and my mind is exploding with ideas for how I'll be able to exploit this potential in future projects.

The editing tools are quite a different story though.  As I mentioned earlier, encouraging creativity is an important goal of the project, so I'm reluctant to release the game without an editor.  But there's still a huge amount of work to be done before the tools can exploit all of the functionality that has been built into the components over the years.

In order to facilitate a quicker release, I've thought about including a cut-down editor that can only create and edit maps for this game, then follow up with the release of a full editor at a later date.  But such a cutback would be no better than the release I had envisioned way back in 2006.

Project functionality isn't the only outstanding issue.  The project is currently undergoing some major quality improvements to fix coding conventions, API documentation, memory leaks, interface designs, and several other issues.  I'm currently working on the front-end (title screen, options, demo, etc.), which is the oldest part of the project, and the code is a clear sign of my lack of experience at that time, so I've ended up practically rewriting the entire module.

Another outstanding issue is the use of some outdated libraries and API's.  OpenGL is a big one; the project is based on version 1.x (I'm not even sure of the exact version) and I have no idea when I'll have time to learn a modern version.  The project also uses Luabind to enable scripting, which seems to be dead; the last official version won't even compile on my current system and I have no idea how to fix it, so I've been relying on an unofficial fork for the last year.

Smaller issues include countless "TODO" comments throughout the code documenting minor design flaws, error-handling omissions, and other small issues that should be resolved.  The project also needs to be ported to Windows and packaged with an installer before I can realistically expect anyone to play it.

I've tried to keep myself motivated by maintaining a list of remaining tasks, but there seems to be a never-ending stream of tasks that I've forgot to include, so the list never seems to get any smaller even though things are getting done.

I feel like I haven't really moved on much from 2015; seeing the end within reach, yet having no idea of how far away it actually is.  It's like I'm constantly moving forward in a tunnel, yet the light at the end never gets any closer.  The game is pretty much done on the surface, yet there is still so much left to do.

I've heard of "development hell", and now I feel like I'm getting a first-hand taste of it.  I know software projects can often take longer than expected, and it's easy to be overambitious, but I don't think 13 years (and counting) is normal for a hobby game project.

So what's the point of this post?  Well, I guess I just wanted to hear views from other hobbyist game developers:  How do you approach a hobby game project?  How do you keep the scope under control?  How far do you go to make your project useful beyond the immediate game that you're making?  Do you think its worthwhile to create editors and tools and add flexibility beyond what your base game requires?  Have you ever found yourself in a situation like this?  What would you do in this situation?

I admire your commitment. Our problem as hobbyists is that we don't know when to stop, since the value is in the journey. As long as it doesn't drain all your energy... I've found equilibrium in aggressively limiting features but committing to completing usable versions, while working on a very simple game engine, on and off, for about 3 years now...

I stick w/turn based games. The scope is such that it only takes a month to hit a playable game state. Updates of course take years but.... at least you have something to play in the mean time.

Yep, sounds pretty familiar to me  

One man alone is not enough to do everything himself, isn't it? But there are options like using libraries (e.g. a physics engine?), and of course... engines like Unity (just joking, haha!).

Also, decide if you want to make a game, or an engine that can be used to make games. If you focus on just one game and ignore all this 'it must be flexible, reusable, extendable, run any kind of game...' wishful thinking, you could produce results more likely and after that use what you have for the next game. This way you get games, and a more flexible engine for free. Doing the latter right just from start up is impossible anyways IMHO. (Refactoring is faster than starting from scratch - we just need to accept it's never perfect.)

I like your will to include editors. Community content is the best thing that can happen to a game.

All too familiar to me too!

Trying to learn from my own mistakes, one thing I'm trying to convert to is release early and often. Make something playable, no matter how rubbish, and then improve it (or move on to another project).

Good to know, then 4-1/2 years and not even having a framework finished is an o.k thing then in the world of hobbiest's.

I use to have a similar problem. For my first 6 years I kept jumping from project to project; unable to finish a game.

It was when I made a simple match 3 puzzle game for a other developer that I finally snapped out of it. Making that small game, not following my own ideals and rules, I had the first taste of a successful game.

After that it was like some constraint had snapped. I could easily work on a project from start to end, it didn't even matter if I was keeping to my own ideals and rules; I realize how they fit in with everything else.

The only way I can think of describing it is like dislocating a joint, once it happens it is very easy to do it again.

The problem I think is we learn how to make games, but never actually learn how to finish them.

My advice is: make a small game, a clone of a small random mobile game or something. Just to prove to yourself that you can do it.