__
Programming-Approach (systems)
cheap tricks, advanced results
----------
The "systems-based" philosophy in regards to fleshing out a playable experience can already take place using Unreal's 'blueprint' designer-style features, and the NeoAxis 'logic editor', among a few other disparate components. The massive problem with a blatant and total systems-based approach is performance and reliability. Simply put, it's a more lazy and wasteful method that lacks precision and penalises performance for the sake of ease, nobody wins, and should only ever be used for things calculated very seldomly, overarching back-end mechanics. That's true, but let's be determined to attempt results in the meantime instead of waiting forever for the genius mathematician programmer of our dreams as we become dusty skeletons all draped in cobwebs.
There are a few extremely important things we CAN do in the meantime, all of which involve both optimising for performance from the outset at a fundamental level, that everything we do, from the tiniest to the most convoluted, stand the best chance of using the least amount of computer resources as we do them, how, where and when. Some trigonometry, a little dash of calculus and a generous heaping of algebra, and all things are possible. There are no perfect results to be found here, but with a little luck, some or much of it might fit into the "good enough" category, even long-term.
__
- "Quantisation"
Absolutely vital and also leads into the following concept. The idea with quantisation is to calculate something less accurately, with less mathematics, less frequently. This is more on the logic and data side of things than the timing, but a little of that too. The more everything is quantised down as to use only the least amount of mathematics as necessary to be passable, the better. The trick here is to establish quantisation rulesets at the deepest level that are shared among everything involved in a branching hierarchy of influence. It also requires that many things be dictated to happen on chunks of iterated number of seconds and usually never even per-second. A lot of careful and tricky planning is required to quantise everything in such a way that nothing is ever stepping on anyone else's toes, everything synchronised in a non-intrusive manner and memory gets spent in an even and fair way, whatever the hell is going on. There are many aspects that can be quantised in one way but compensated for in another, such as small fast projectiles compensated with larger/longer hitboxes to ensure success when facing such lack of precision. The projectile can still be smoothly fast, but the quantisation risks it failing any collision detection, which is an easy workaround. Other things may be slow but unsteady, which may be resolved by "playing into it" with animation or effects, such as giving it a "busy" appearance anyway, or setting a perfectly smooth path but disguising the snapping that occurs on a clock-check with some animation or effects. A bit of creativity can go a long way to not being obvious about actually being so cheap and sleazy behind the curtains.
__
- "Permutation arrays"
These are used to populate all variables on-the-fly during a level initialisation, also kept resident to refresh them on-the-fly and can also be used for saving and loading progress. These are 8-digit combinations, like pins in a keyhole or a lock on a briefcase. They are not linear numbers, although can be, they are grouped together and usually represent single-digit values, many true/false booleans, while also accounting for the index of the value. They are then used to create all necessary variables and their counters on-the-fly, as needed, which the rest of the game logic interfaces with. In this way, we get a higher degree of flexibility to sandbox a world to be constructed and configured, but is an extremely efficient way to bring everything we need in from the outside to do so. The values are brought in whole-cloth as a concatenated sum and split by the engine into sets of 8, which is intended to slot into memory banks in a clean way, a little like a mix of hexadecimal and binary, borrowing concepts from both. It's possible to attempt rapid changes to these primary permutations, and adapt them through unique variables at a slower pace such as 12HZ, variables which are only active when needed. This is, from what I'm able to both propose and achieve, the best case scenario for a gameplay-engine that is all of efficient, digestible, flexible and still scalable. It also allows almost everything to be designed from outside of the engine and source code, with the source code only considering how to interpret the permutations in a universal way, but constructing its own variables and counters as each entry in the permutation is activated. Theoretically, each level will only contain and process the information presented to it via each permutation, a self-regulating measure to optimise itself at the very core of the initial programming.
__
- "Sloppy Clocks"
This is where time itself is both averaged, quantised and reinterpreted in various different ways, all with the intention of saving computer resources. Almost all of the game logic itself will run at 12hz with very few things requiring 30hz. This does not mean the rendering, animation, effects or input, or anything like that, only the internal logic itself. It's a different thing to framerate, which its own implications. The 30hz mode is also slightly imprecise with fence-posting overflows, sometimes hitting 29 or 31, and thus counts as sloppy. Even though 12hz is calculated the same sloppy way, it remains precise. The way everything bigger (quicker) than that is done is by dividing that value, which means almost all logic is still triggered at 30hz, the math can be quicker at the exponential expense of lost accuracy. The real memory savings come from the sloppier and more quantised calculations, none of which use the CPU clock but only derived from the 12hz "staple" value. Sloppy seconds keep the seconds in the minute fairly well, running into minor issues similar to the 30hz sloppy problems, but result in about 3/60 seconds not being useful for reference, which is pretty good if understood from the beginning. If everything using that kinda goes to sleep for 3 seconds every minute, the audience need not know about that. Some other clocks quantise iterated minutes into 6ths and 8ths, which is a good compromise for more accurate chunks to be available for timed events and only require a few decimals, for precision without relying on CPU seconds. These compromises do wonders to keep framerates high, and it means only 1 value out the dozen actually references the CPU on-tic at all, and is only polled at 12hz anyway.
__
- "Medians\Averaging\Snapping"
All this scary talk of sloppy imprecise kindergarten math is gross and sad, but fear not because with some careful timing on the higher-end, we can fix everything right and be comfy again. Sometimes this can mean a few seconds, I might say the lowest being 3 but not very often, more likely 8 as an average. 3, 5, 8, 16, each using the CPU to synchronise back again, with probability of checks rising with the number of seconds. Averaging means that the iteration of the check itself is used in the mathematical formula to determine where that median should be at which point, leading it closer to a following iteration where the known accurate result should be. This means that while things are at risk of becoming janky and glitchy, due to the sudden accurate snapping, the averaging at the median point almost brings the correct result close anyway, resulting in only a few pixels of inaccuracy even at 12hz at around each 8-second interval, and a few more pixels each 1-minute interval as everything is snapped for good. The low frequency of checks combined with the quantisation and sloppiness of time-keeping establishments does not need be such a recipe for disaster, as the solution actually boils down to synchronisation of compatible mathematics. Much harder than it sounds, but it means there is a good chance of avoiding any jankiness with the audience none the wiser to how the sausage gets sizzled under the hood.
...now that we've gotten housekeeping out of the way, right from the outset, time for the fun stuff!
- Arrays & Tables.
..."Where all of the meaningful data is derived, which even includes a lot of level design elements that would otherwise be consolidated in a graphics-orientated approach, although are intentionally interchangeable and mostly originate from animation, physics and graphics."
...
- Cascading Variables.
..."The core logic of a systems-based approach is really just like a series of locks and keys that govern different mechanics and even different other arrays, and while this is where things can get insanely messy, it's primarily mitigated by use of a concise and rational permutations."
...
- Intentional Randomness.
..."An art in itself, how to be meticulously random, or randomly meticulous, or accidents on purpose or purpose by accident. So long as extents are contained and perimeters are clearly defined, a lot of 'wiggle room' can be baked in to keep an otherwise restrictive system more interesting."
...
These components are driven by clocks and their subsequent calculations, many of which are simple iterations but also include formulas that produce sine/cosine values for interpolation, circular movements, acceleration and deceleration. All of this done at a core fundamental level and organised as a branching hierarchy shrouded with data-management driven portable systems-based structures, designed to be easily expanded with text-based scripts while also usable across different engines.
AAA top-tier games are typically half systems-based, quarter engine-level and quarter clean dedicated code. A little clean dedicated simplistic code is possible, and this is bolstered by the technique of handing a lot of it off to animation, a topic I didn't want polluting this ramble. So we might be talking about 5-10% instead of 25%, but that's still well within AA-quality standards if done well enough, and if done with absolute forethought and care, potentially AAA also. Conceding and reverting things to relying on tight CPU timings to fix jank, stutter and chug, if it all adds up to not such a huge performance hit, there may just be enough luck to still classify it as a very playable game. If to let absolutely nothing stop you, this is simply the penalty to potentially suffer, in exchange for the sake of seriously solid progress in a team lacking a true coding genius.
.
.
.
----------
...clocks:-
Flipper = 12hz as divided to 1 digit, 8 and then 4 counted as rough cycle. =30HZ*
12HZ = the one true clock until we get to true seconds. (0.083)
Switch = when 12HZ reaches 60 minus one flipper, use like a lightswitch.
Slops = as interpreted by the lightswitch and increment, fixed along the way, widely used.
6th = almost precisely 1/6 of a second, roughly 7 seconds of 10 increments, widely used.
8th = almost precisely 1/8 of a second, roughly 3 seconds of 10 increments, widely used.
Seconds = true clock at exact seconds, only used to sync a few things.
Near-ten = not quite 10 second mark where many things are synchronised.
Minute = last true clock at each minute where absolutely everything is synchronised.
(*the Flipper is so erratic and unreliable, 30HZ only calculates the first definite 8...
...it uses the remaining value as an average (minus low from the high or add high to the low))
...
----------
...permutations(P):-
_INF(Z) = "information"
1: category
0: type
3' "
6: health
4: damage
1: act
3: value
1: matter/respawn
_FIX(Y) = "coordinates" (larger than 10k can use quantised values)
1: lead (can be used to count Y axis to 8999 by subtracting 1000)
3: y-pos
2' "
0' "
0: x-pos
6' "
4' "
0' "
_ACT(X) = "behaviour"
1: team
2: ai(initial) (9 sets traverse with target)
1: attitude
6: speed
7: jump/fly
1: response/target
3: hold
7' "
_VIS(W) = "visuals"
1: category
0' "
2: set
0' "
0' "
1: index
1: colour
3' "
.
.
.
https://www.violationentertainment.com/wiki/tiki-index.php?page=Hooks
https://www.violationentertainment.com/wiki/tiki-index.php?page=Design
https://www.violationentertainment.com/wiki/tiki-index.php?page=Art-Centric
.
.
.
.
.
.
.
.
.