[2.xx] Expanded FFC Things

[Gleeok]

Destructors, linked lists, queues, stacks, more complex efficient implementations. Encapsulation, polymorphism, inheritence, etc. You just gotta think.

C++ was made to optimize memory management as perfectly as possible.
if you need help with that, I'm on board. I have a book on Game Design if you want, it's graduate level though but I'm sure it'll be easy for you.

Object-Oriented Programming for the win.

AGILE manifesto, team iterative processes, etc. Basic Software change procedure.

Concept Location -> Impact Analysis -> Prefactoring -> Actualization -> Postfactoring -> Verification -> iteration -> ... -> Conclusion

You guys are stuck in the Waterfall Pardigm from what I can see, that's why we need OOP

The problem is that ZC has no dynamic resource handling. Think about it if ZC were a skyscraper built on sand, and you wanted to add some support to the foundation, maybe concrete, without collapsing the whole thing. Jenja!

I thought about today while I was doing laundry (This is when I do most of my deep thinking), and I think the best solution is in-memory compression; although rarely used nowadays would be the easiest, cheapest, and fastest solution. I'll look into different compression types for the FFC structure (something combining RLE concept and LZx probably) and see what ratio I can get. If I can get 20:1 FFCs shou;d be able to be increased with no additional problems. Additionally: If I can work out a special case where any screen that has no FFC data can safely be treated as its own type then I should be able to get 6500:1 ratio O_O.

There's also the problem of this potentially bloating quest files, how the editor can cope with all of it, and FFC script buffers, etc.

It's still problematic. Maybe this can be the first community project when the open source version gets done.