Even from telling myself to go slow, I started wayyyy too fast

So I rushed into this engine development thinking it was going to be easy to just start and go.  It turns out I was horribly mistaken.  I put some lines of code onto the screen to make a window pop up and had it close when I hit escape.  Awesome!  Now where do I go next?  Oh.  Right.  I have not a singular speck of a clue. 

So in front of me is a piece of paper with a whole bunch of scribblies on it and at its very center is the text "WAIT.  How is this engine supposed to work?"  That's always a good part of design, isn't it, figuring out how the product is going to function so you actually know what you're implementing?  So let's break it down.

A game engine is a software tool used to create games.  It can be geared towards being used by the general population of game developers or it can be created to generate specific types of games.  As I'm not planning on making this a super general game engine (That can get complicated and messy, I imagine.  Especially without a team.) I believe I'll be sticking with the latter. 

Either way, I think that's still a bit too general.  After all, we're developing a game engine from the ground up, tools and all.  I think we need to ask a couple of deeper questions in order to get to the root of exactly how we want to go about developing this.  Questions like...

And to me, this is a bit of a question that has some answers that are mirrored from the similar question "Think like a player: What is in a game?".  Well, a game has characters, for one.  Visual art, that's another thing.  We can even go and say it covers a wide range of art, from visual artistry to music to storytelling.  A good game has intuitive controls and GUI, reaches good standards of accessibility, has intelligent level design (or at the very least gameplay design). 

So how can we translate that into the functions of a game engine?  Good question.  Here's my answer: Make the tools that make the product.  You want good level design?  Make a decent level editor.  You want great art?  Make a system that can import and utilize media files such as .jpg's, .mp4's, .wav's and the like into an asset list.  Accessibility?  GUI editor and input manager. 

Great, so we have the tools needed to effectively create the front-end for the user.  But how about how the game functions?  That's where we have to get a bit more specific.  In the case of a general game engine, I would have to account for every possibility of game that's out there.  However, I'm not planning on making an MMORPG or a simple puzzle game.  Not even going to touch the phone game market.  I want to make a story-driven RPG that does a bunch of crazy computer things that the general gaming audience would be caught off-guard by. 

Taking that into account, I can say that I want to integrate a game state system, where progress in the game is dictated by a certain game state.  I need to have an API that allows me to create assets that would then be recognized by the level editor so I can place them in my game.  I need debug tools.  Like a lot of debug tools.  Those can essentially be written as I find spots where they're needed, but a good start would be a logging system. 

Oh yeah, speaking of assets and logging, I do need a filesystem to keep everything organized.  A place to keep project files separate from the engine proper, a place to keep engine files, a place to keep helper files and engine assets (separately from project assets).

I could keep going about how levels and project specifics are going to be encoded in the system, how exporting of games will work, and the like, but I was starting to lose my mind a bit there just talking about it and I think anyone reading this might have been starting to lose their mind a bit reading it.  I think at this point everyone gets the point.  A lot more goes into a game engine than I originally believed, and it is dawning over me how much of a monumental task this will turn out to be.  Nonetheless, I still think it's worth plowing forward.  The amount of tools this will generate for me (and possibly for other people) is going to be positively huge.  Without question, having any kind of end product associated with this project is going to be one of the most satisfying things I will ever experience.  Probably.  At least that's my hope. 

Anyway, that's enough daydreaming.  Now that I've covered my bases on what a game engine has, it's about time for me to ask:

And that one's a bit tough for me.  I suppose I'll have to look at it from the perspective of "How would I want this game engine to work?"  My personal answer to that question would be this: Unreal, but a lot more specific, a lot less clunky, and reliant solely on code for game functionality rather than whatever bs blueprint system they force users to abide by.  Pretty much the only GUI I want to have is for developing any kind of visual that will be used by the engine and for level creation.  I'd want everything else to be done through code.  After all, I am a control freak, and if I want the freedom to make everything run the way it's specifically supposed to run, the best chance I have is to make as much of my engine focused on code development as possible.  That means a huge focus on the API and the filesystem.  I would like this system to have a hot-reload function so that I can update the behavior of the game while I'm in the middle of debugging, as well as a command line interface for checking variable states. 

Hoo baby.  That's a lot and that's not even the end of it.  I'm honestly thinking on too specific of a scale to avoid burnout at this rate, so I'm going to keep it a lot more general.  I need a level editor GUI, a GUI editor GUI, a debug and runtime state, a way to export games, a filesystem, a file format for levels, project preferences, and system organization, and a solid API that has a whole host of things I need on its own.  

So with all of that covered, I can finally reach my final question, which is:

Honestly, I should probably plan a bit more.  Unless that absolute mess of a system overview is enough, in which case I can move forward.  If I were to start now, I would have to say that I want to start laying out the interface on which all of this is going to lie.  Just really hammer on the internal structure of assets by writing some initial documentation and some header files.  I should probably make some graphs that show what depends on what within the system as well, and see if there's any flaw in the logic I'm currently using.  As this is starting to look more like a modular suite of tools than it is one huge piece of software, I can probably hop from thing to thing  to work on structure whenever the inspiration hits me, which is great for my hopelessly distracted brain.  So yeah.  Documentation, graphs, and header files.

That's about all I have for this update.  Though this was written like 2 days after my initial post, I can't really say that I'll be posting this often.  The only reason I made this one was to get all of my ducks in a row and figure out how I'm going to get this to work.  And with that mission mostly accomplished, I bid you adieu, and leave you in stunned silence to ride out the night.  Hopefully that wasn't all TOO illegible.  If it was, I'm sorry, but I refuse to say it all a second time. 

Let's get this show on the road.