Ok, I think I got it. Also lets try a different kind of post.
I’ll start with updating a TODO list to accommodate what I’ve learned so far about the project.
Got to a few great conclusions about how to proceed with the project, and this means changes to “the plan”.
–
I think I’ve also got to an understanding of my own engine that allows me to actually proceed to the next step of the editor. Saving a project. These won’t be C files to compile for GBA, but actual edition files for the editor.
–
I’ll proceed exposing how I played around with the engine’s game objects, how I found some weakness, and future options for a better game engine. This means that I really got a good portion of my mind right for getting the project moving again.
–
Finally, during the time since my last post I was able to finish the layout of the “New Project” window. Simple and direct, but all functionalities are in place for the exception of actually starting a new project.
Doing a window like that really got me back into the groove of how to design desktop apps layouts just with code. Good times.
I’ll start with the end basically. After all this going around making 1 single window and reading, remembering, and getting the project back into my brain, I finally realised how it can proceed from here on.
That resulted in changing the TODO list, and the consequent flow of the project.
That was pretty much necessary because the previous flow was… no flow at all.
This next list has a few things that I’ve never talked about here, but they will have their own explanation and how they came to be along with the post.
–
The list above shows I’ll be focusing myself on developing the editor’s project persistence.
I did the new project window but I didn’t had an exact folder and files structure. I did have a direction I wanted to take. To “dissolve” the project in many files. Each with data about one specific reusable object/structure in the game.
I had two main worries while thinking about this this “distribution of files”. I personally cal it this “project>code>engine organisation” (I more and more have this feeling of an interconnecting flow):
- My first and main worry is to increase re-usability of assets in all fronts. Be it pixels, palettes, physics (I really see them all as blocks). This helps defining very accurately which tools of editions I will need, and to which type assets give the shortest and more accessible way of being edited.
- My second worry is how this data will organise itself in a machine as small and basic as a GBA. From both hardware front like rom > ram copying, ram usage, and whatnot. And also inside my software that is the game engine. How to keep things editable and generic enough to make a good deal of different video games, without falling into the “generic engine’s generic feeling” trap (that is however mostly game developer’s fault, but there’s limits). Allow each game to feel different while using the physics and movements engines I implemented and/or will implement.
–
However, this had only came to me a couple of days ago. I got to this direction after playing around with the editor’s code, and the project’s concepts.
So to really get my brain going on this… “organising thing”, I had to be capable of “seeing the everything”. Personally there is no better way of “seeing” a specific “everything” is drawing “it” with pen and paper (or pencil, whatever).
Don’t mind the connections at all, forget them even. What matters here are the boxes. With a first quick look through the code, and some memory work, I can reduce the engine’s core structures to the ones shown above.
Lets call them Core Data Structures for now, these are what you create to define “game”.
How did I get to them? They actually exist on my GBA code, as concept. They have similar names (most of them), so if it has a name it exists as concept. Code only makes it functional.
But my objective was the dependencies between structures and hence I moved along trying to figure it out. Decided to get into the PC and work with some vectorial graphics, they are faster to use after some work:
Well… this also doesn’t look too good, so I decided to take a different approach and organise the flow chart to represent each object’s dependencies in C code. Also added some neon.
This looks a lot better. Allowed me to realise that both UNIVERSE and SCRIPTS are almost like omnipresent entities on the game. The universe is obvious because it is basically the cylinders on a car engine. What makes the clock tick-tock. The one which holds everything else of the game world (doom doom dooooooooom).
But scripting is also present on the universe, from the bottom, and within the game objects. This is rather convoluted to be honest, specially on the C/C++ dependencies point of view.
This is because the UNIVERSE can naturally work on it’s elements. The UNIVERSE can change ROOMS, ACTORS, BACKGROUNDS, because they are included in UNIVERSE and stored within it’s own allocation.
But the scripts must also be able to act upon the game objects (actors, roms, hud), because that is their function, yet not their authority. To execute that function, scripts “know” the other objects as well as they have to know it so they can hold their own script.
You’re not understanding shit right? Neither do I… this situation is probably called something like “circular referencing” or someshit. The result is this means some seriously shady C code, and back-bone-bending to get it done. Otherwise know as “forward referencing” or someshit.
Decided to leave it alone for now because the engine is working. I’ll worry about making sense and making it work better later.
Having decided on the most important to edit objects inside my engine, and how their dependencies should work was great. But I had to figure a way to organise the game objects into files. Different files with interconnections editable on editor, and realised on engine.
Decided to keep working on those vectorial graphics, since it was there and was fast. Really didn’t worked all that well:
Hard to understand what’s folder and file (more like impossible).
So finally I ended up with this vision of a file system:
Each game object created by the editor would have it’s file or files. Name and extension would serve to claim the object’s owner and it’s function.
I have thought of another alternative structure. I really need to put it here so it doesn’t get lost on a ton of paper (causes me more impact here, believe it or not).
Another alternative would be a folder only system like this:
project_name
├ assets
│ ├ textures
│ ├ sounds
│ └ musics
└ meta (or whatever)
├ rooms
├ actors
├ backgrounds
├ vfxs
├ huds
├ colltilemaps
├ sprites
├ physics
├ hudelements
├ palettes
└ scripts
So far I can detect that the latest is the file system that by far motivates more re-usability of te biggest number of created objects.
I.E. using the same exact physics through out 20 different types of enemies (not run time enemy instances).
But it has 2 major disadvantages.
First I’ll have to create a way to edit, create, delete, and keep in check every single object for every single type (no longer “actor responsible for it’s own physics”). I have to give attention to that right now because if I want to treat all game objects the same, I should make them the same on code.
I could also implement all these functions on the object base itself. But my problem with this disadvantage is “how to allow creation, editing, and deletion, of each of the objects to the user”.
The second disadvantage is that it is a bucket load of files, and the user absolutely should not mess with the files. Broken projects for editing one character on one file outside the editor.
Meaning, a clusterfuck to keep everything in check… or stupidly simple if I get a good system to do it with the system above??? Any ideas?
How does fucking unity does it to keep all those files in check in real time.
–
Finally, the first thing that I finished during all this time was actually the last I’ll talk about this time.
The layout for the “New Project” window.
It’s looking like this:
And that’s pretty much it.
I would like to conclude with a summary, for self reference mostly and to clear how to proceed.
I should really focus on the next topics of the TODO list, and get persistence going.
This is very important because right now I am converting my GBA Tech Demo C code to get the project going.
That means to process all those pictures from text files which pixels are written as numbers on a list. SO GET IT DUUUUUNE.
After that I press into the scripting edition, but I should actually be careful and only stabilise it enough to check if the saved values are the same as the values on the C files, and if they are all of them.
Then proceed to editing tools immediately, the easiest ones, to get more practice at Qt.
But I should really pay attention at the editor > engine flow. Start looking forward to get working om both codes at the same time, improving both. This could come much later but optimisation will have to be done eventually. Even if premature optimisation is an error, I rather do at least some of it while the code is fresh, smaller, and less complex. Helps preventing added complexity.