2.5 KiB
Project Plan
This is my like 4th attempt to get this project off the ground and I'm getting a little sick of my perfectionism getting in the way, so this is a project that I am promising to myself will be used to get this thing off the ground, even if it kills me.
Issues with the various Dawn Versions
"Dawn 0"
For lack of a better term it was inexperience when coding with a lower level language like C and C++, I ran into a lot of problems trying to test and figure out my coding styles and preferences. The code was fairly solid but not good enough for a production code.
"Dawn 1", aka "DawnPlusPlus"
Inexperience with C++ mostly, the engine was really good and adding/using stuff felt fast and great, but the problems came with trying to use the classes I had written in a reusable way given the differences between a language like C++ and C# that I had not yet experienced.
Most learnings were done on how C++ doesn't really have an interface system, I think I would be better off just writing C-Styled functions in these scenarios.
Additionally event subsystem was likely going to cause me massive issues.
"Dawn 2" aka "DawnPure"
Really great, loved everything, but when it came to doing component lifecycles it hit hard walls, particularly when it came to trying to do things that would normally use classes, namely, UI. UI was a pain to work with and added a tonne of inefficiencies.
Focus
- Better usage of arrays, maps, hashmaps, key value pairs, etc.
- Better component lifecycle.
- Better event system.
- WAY better UI system.
These are my main areas of focus, everything else should fall in to place as a result of these.
Structure
Let's address each of the pain points directly and cut to the chase.
Better usage of arrays
Main issue before;
int32_t i;
arrayset_t someArraySet;
for(i = 0; i < 100; i++) {
if(someStatement(arraySetGet(&someArraySet, i))) {
// I need to remove from array set, this modifies both the indexes but can
// also affect the literal raw memory in the array set.
}
}
Ways to improve
- Use the std::vector and other standard models
- Create clones while iterating, or backstep during iteration
- Defer the removals to "next frame"
Better Component Lifecycle
TODO: Detail in greater information, but essentially having "entities" be simple structs, and all of the "other parts" not be related to the entity itself.
Better Event System
TODO: Come up with one
Better UI System
Classes should solve this issue, assuming I can use them somewhat sparringly.