Hey im stuck..... im writing myself an AS3 game engine (im 13)

lewl

Anyway, for starters, tell us how the thing is misbehaving.

Secondly, a glance at the first function tells me it's wrong. You need to assume a collision is false until you detect one. Otherwise a non-collision will incorrectly erase the detection of a prior real collision.

I love OOP because OOP is fun. It's like what Spore is meant to be.

Come again?

Crown Vic




ruff n tuff

I'm astounded you're only seeing this happen at 45 degree angles, although it is where aliasing should be worst.

Oops I forgot to say i am only rotating at 22.5 degrees steps, if i rotate freely i see the aliasing at many degrees, since i am only rotating wit 22.5 steps the only troubles appear at the 45's (that's why I Still feel i can quick fix)

Dude... you would've saved me some time had you said that earlier. AFAIK 22.5 degrees is below the threshold where the hard aliasing problem exists.

Since you only rotate by (effectively) two different angles, there's probably a more elegant, lightweight solution than something RotSprite-esque. Is efficiency a problem? Anyway, good you got it working.

@Danmark You mentioned that this wasn't described anywhere in the "Evolve your Hierarchy" blog post. Actually, I'm doing exactly what he says in the final solution of his blog post. I may just be explaining it badly since it is kind of abstract. The post is here :

You're right. I was responding given my egregious misinterpretation.

West kept the pure aggregation section vague. It's true that your system is exactly what he describes, but there are many ways to fulfill that spec. Many exactlies. The unusual (but not unheard-of) aspect of yours is that data storage within a component subsystem is based around tuples rather than structs.

Dunno if I explained it properly, but my EC system is equivalent except struct-centric. Sole dependence of components on their entity (which is just an ID) is in reading in the entity state for the sake of lifetime management. W.r.t. a component type, you list object IDs and resolve them to per-component data, while I list component instances which contain data as well as respective object IDs.

Now some semantics. In your upcoming post, please don't refer to a Script or Sprite manager as a single instance/copy of a component. That's not what literally anyone else ever meant by those terms, and this weird terminology is what baffled me. You're just talking about singletons that handle components of a specific type, not components themselves. While I'm an amateur at component systems, I've followed the craze from the beginning, including some heavy esoterica, yet nothing that confused me despite your system being more down-to-earth. (note actual misconstrued you as well)

I'm interested in why you went for tuples over structs, which I hope you cover in your post.

i've tried the shifting the centre (no joy), another thing i tried that was reasonably succesfull was this:
instead of having an algorithm that does something(rotate) for every voxel in the original shape, i did it the other way; for every voxel in the rotated emtpy space i looked up the position where it should originate from. It sort of works better, still not perfectly and it costs way more time because now i have to do quaternions, multiplying etc etc for every voxel, instead of only the ones that are not empty..

Dang, well it was a good idea. Although...

If you don't mind not preserving any color information from some voxels, you could do a forward rotate as normal, then find gaps (still not sure how best to go about that), then do a reverse rotation back on the gaps to find out what colors are best for them. As for the aliased voxels, just pick the one object voxel that best describes that world voxel by being closest to its center (Manhattan should suffice) & stick with it. Kill the others. This would preserve volume & shape.

Reckon the marginal cases would still bite you in the ass sometimes though.

well i don't need color (all the voxels in a shape will be the same, and actors get created by using 20/30 ish of those shapes together) i believe i do need to preserve volume of smaller shapes though (but i am curious how it makes it simpler)

and yeah:
maybe i should just bite the bullet and describe the shapes as polygons, rotate the points of meaning and fill in the rotated shapes afterwards with voxels, it feels overkill/and will prolly introduce many new problems   but it might be alot more fail-safe at the end

I wouldn't do what you describe in the last para. You're already charting unknown territory with this stuff. Closest thing I can think of is voxelization of polygon scenes.

The reason it'd be simpler to have somewhat goofy volumes is because the root of all your problems is undersampling. Refer back to the diagrams. What if for each world voxel, instead of picking one corresponding object voxel, we let all the object voxels intersecting it affect it? The edges/faces intersecting, not just center points. So world voxels get color & volume from anything touching them in their 3x3x3 neighborhood.

This gets rid of the marginal case problem. Every single world voxel will have some faces intersecting it. It also simplifies the nonexistent color problem, because you don't need to pick the best, you just do a weighted interpolation between every intersecting object voxel (based on how much they intersect).

Trouble is gnarly volume inflation. Consider a cube inside a voxel & rotated s.t. the cube's vertices poke out all the voxel's faces. Well, then you need voxels for six neighbors. Obviously in real cases, an object's volume won't inflate by 6 times, but it's still pretty bad. They need to be big with chunky features for the nuances of the shape not to be lost. You could help this situation somewhat by considering the object voxels as physically smaller for the purposes of world voxel volume creation. Picking the smallest cube s.t. gaps are guaranteed eliminated would make a huge difference, couldn't say whether it'd be enough though.

I definitely understand the C over C++ for starting. But I don't understand what you mean by "hardline object orientation".

Right, I mean the academic/code monkey orthodoxy that has sprung up around OOP. The attitude that OOP remains dominant because it's totally the best way to program everything. Emphasis on designing around inheritance and virtuals (particularly interfaces) and data hiding etc., regardless of whether these are the best tools for the job.

I prefer using C++, because it's nice having some extra tools around. Not so for a noob.

i suspect the problem is more simmilar to the rotating of bitmap images (and the artifacts you get when rotating very small images) then polygon 3d approaches because you wouldn't have that problem with polygons.

You're right, and the problem is fundamental enough that you won't find any numerical quick fixes.

I'm astounded you're only seeing this happen at 45 degree angles, although it is where aliasing should be worst. I'd start by determining the real scale of your problem. Write a test that makes a big cube of voxels (not just a plane) as big as the biggest object in your game, and rotates it by arbitrary axis-angles while recording how many voxels got aliased.

The reason 45 degrees is particularly hairy is because you have two problems. One, the problem of multiple voxel centers resolving to the same world axis-aligned voxel, which you'll have for a pretty big range of angles (hence my disbelief), worst at 45. Two, the problem of marginal cases, where the center of a voxel could just as well fall either side of a face of a world voxel, and tiny precision issues will arbitrate which side. Tell me: in the case you mention, do you see lots of aliasing along the global x and z axes?

You might hack around the second problem by shifting the center of the object on all axes by a tiny offset, to ensure a consistent tiebreaker. Hopefully someone has a better idea.

The first problem is more subtle. Gist of it is you need to identify gaps and fill them with voxels from the gaps' 3x3x3 neighborhoods. Can't think of a robust solution though. Perhaps you can get some ideas from the RotSprite algorithm (more info about it here than anywhere else, also lots of TIGers).

Here are some roughshod illustrations of the problem in 2D. Red lines are object pixel edges, blue crosses are object pixel centers, and black lines are world pixel edges. Clicky:

Note the world pixels without object pixels, and world pixels with 2 object pixels in them. In 3D, there could be up to 4 object voxels aliased to a world voxel. Also heed the complexity. The ideal pixel to fill a gap doesn't necessarily come from an aliased pixel. If you did something sequential, the order would be crucial, and you'd have to look far ahead to produce good output. Considering not every object pixel would be defined, even finding gaps is non-trivial.

BTW, if you don't need rotation to preserve color of individual voxels, or to even vaguely preserve volume of smaller voxel objects, the problem becomes radically simpler.

I'm one of the many resident advocates of C++. It really just depends on what you want. If you just want to put games on newgrounds like everyone else, then flash is fine. If you want to get to the point where you are releasing games on steam, and possibly others platforms, I don't see the point in starting with Flash. Just start with C++ and learn the language. Even if your games never make any money, you will likely have much better development skill if you go with C++.

Good motivation, but I'd recommend starting with C over C++. C++ is too heavyweight for beginners, having too many features to learn and slip up on.

IMO C++'s introductory materials lead to poor practice (particularly for writing games). Applying hardline object-orientation to games, as he'd probably end up doing at first, is dubious as hell. It's proven disastrous even for experienced devs.

Not all component systems let you attach data on the component instance itself. Instead, the entity has a generic data segment that all the components have read/write access too. The separation of data from code can sometimes be handy. For a start, components need to be less aware of each other - they can communicate by using a variable in common. It can also facilitate serialization/copy-paste and other data-centric concepts, and the "fly-weight" pattern.

Reminds me of this old GameDev thread from the peak of the component system hype.

It's an intriguing idea, but one that smacks of over-engineering and under-specifying at the same time (I realize you're not endorsing it). An incredibly versatile system against which you'd throw narrow problems IRL.

Many-writer scenarios are hard to keep track of & make robust. Being able to write to arbitrary fields in an entity looks good on paper, but if you used this much in practice, you'd have an intractable mess on your hands. A design where components must be unaware of one another makes the developer unaware of what's going on in his soup of fields.

But part of the appeal of this approach is, having disassociated data from classes, you can alter the layout of your data substantially, given more specific knowledge about what data each of your entities needs. For example, you might store all the positions in a single array, allowing you do efficiently loop over that. Or have an "entity" per tile, where much of the tile data is looked up from a palette entry.

You can do this in a simple component system by spending some memory. Altering one data layout is equivalent to having additional layouts plus redundant data, which'll run alot faster.

AFAICT the only thing this ability affects is efficiency, a concern that this soupy entity concept won't fulfill in the first place, thanks to substantial overhead. Well, you might save some memory with the system, but it's terrible bang for your buck, and memory usage is almost never the bottleneck in a game anyway.


Only concern a field soup may addresses well is ease of implementation- in very narrow cases. Perhaps if you had a great many qualitatively distinct entity types, entity-centric (not component-centric) updates/behavior that can't be broken down & systemized (or that is concentrated in one system), low responsiveness requirements, and extreme memory requirements. A big social simulation?

^ That's what I thought at first, but it's typical of EC systems, and I read weirdness like

Have a single copy of each of your components, and then have [them] contain a list of unsigned longs that are just Object IDs. If you want to attach a component to aan object, all you do is add the object's ID to the list inside the component.

Even if he means there's an object ID list per component subsystem or prototype, the location of state remains mysterious. Perhaps he just didn't bother mentioning that part (just as I didn't explain operating over all components of a type in my system), and his ID lists are in lieu of an ID stored per component, which would still raise lots of questions.

Just have to wait for enthrall.

@Danmark Obviously there is more than one way to achieve this. I figured I would just provide my solution. The reason I use the aggregation is because it's easier to implement to components  (in my opinion) and its less overhead. This works really well if your system works solely on an event system as well. Just have a list of components and an event manager, and your done. I don't make multiple instances of any component, which can potentially be a lot of memory saved. The use of events is good because it saves you from having to manage tons of pointers which can get iffy no matter who you are. Regardless, it's just my preference. I just like talking about it

Sorry, I wasn't saying you should go more basic, just that it seemed possible. However...

TBH I'm confused by this post, and by re-reading your last one. If there's only one instance of each component, how do 'entities' have unique state data? You can save a bit of memory by sharing immutable prototype data between all instances of a prototype, but this sounds like all your system does, in lieu of the things an EC system needs to do. Or have you somehow wrangled all state into the event manager?

What you describe certainly doesn't correspond to anything in the classic Evolve Your Hierarchy article, nor to anything I've heard of elsewhere. I'm all ears.

Well, i can't say much about the new marvel animations because i haven't watched they, but i  have to agree that the older ones had a slight mature feel (i don't know if it was just bad animation or they willfully made them clearly adults).
Obviously there are classics ones that never gets old like Courage, KND, Oddparents,etc. But comparing new cartoons and older ones in general i tend to prefer the new ones. Adventure Time, Regular Show, Gumball, are far better than Dexter, Ed Edd & Edddy, Scooby Doo.

Cartoon shows being made specifically to appeal to both adults and kids started in the 90s AFAICT. I think the chief difference it makes is the developers put more TLC into their work, as adults have higher standards to judge their work against, & the networks select for this. The shows aren't just cash cows.

Still, none of these shows are that compelling IMO.

the real question is WTF does danmark smoke ?

Huffing the fumes of an ailing civilization since 1990

Having to check if each component you want to use each single time is not NULL IS increased complexity and IS especially bug prone.

True in some cases, but typically null checks are needed only if you remove or add components from/to an existing entity while the game is running. IMO it's bad design. An entity should have all the components that pertain to what it can be over its whole lifetime. Again with the flexibility point- it's not always expedient to use the full flexibility of EC.

Otherwise, for merely reading info from other components, it suffices to read from a physical null component indexed at 0 (in the context of a data-oriented EC system). This is a common technique.

The remaining cases, where you might legitimately need null tests, are extremely narrow.

And to add insult to injury, you also have to specify the right type (C++ can't infer that), and you can have all sorts of hairy bugs if you get that wrong for some reason (and something that can be wrong WILL be wrong at least once).

bottom line: EC changes something that can't be wrong (accessing a member) in something that can be wrong in multiple places in multiple hairy ways, and that is definitely a cost for the developer.

Nah. Specifying the wrong type is never gonna happen. Maybe if you've botched the design in the first place, and you have very similarly named component types. If you can't even get that right, I dunno how you hope to access the right members anyway, of which you'll have more in-context in your solution (as I understand it).

No technique completely insulates you from the consequences of bad programming. I'm not remotely convinced your boilerplatey, ad-hoc anti-solution does so better than a decent, simple EC system.

The above reasons. C++ is too "dumb" (poor reflection and introspection) to really accomplish an "automatic" EC, you will have to play with crazy templates and explicit types that will bloat compile times, output crazy errors, and introduce a whole new class of runtime consistency errors.
I would understand EC in some languages where you can really compose an object at runtime such as JS, Lua or Python, but doing that in C++ is as crazy as doing manual OO in C.
Please don't do it.

Compile times are a problem you can throw a better machine at, and it doesn't make a huge difference anyway.

The compiler errors readable, largely because you keep the template and macro madness confined to a few files, and every mistake you can make in failing to pass the right data to a macro is trivial.

Runtime consistency errors- yes, inasmuch as there are bugs in the EC system, but these are trivial to test for & easy to track down (assuming it's data-oriented).

I agree that C++ isn't ideal, but only because it's lacking in the generative code department. Reflection and introspection are unnecessary.

Essentially, don't have an actual "Entity" class. Think about it backwards. Have a single copy of each of your components, and then have then contain a list of unsigned longs that are just Object IDs. If you want to attach a component to aan object, all you do is add the object's ID to the list inside the component. It is a pretty abstract way of thinking, but it's definitely worth the extra thought at first.

You can go more basic than that. Each entity has an ID. Component subsystems map entity IDs to component instance indices via an array. Each component knows its entity's ID, so given any component, you can find a component of any type within that entity.

Component subsystems have an array of potential instances. Lifetime management is handled logically via a state in entities. When entities or components are referred to, it is by index, not pointer or reference (the indices can be made type-safe though), as in the solution you describe.

I don't think it is just nostalgia. I can easily look back on older shows that were before my time and I can appreciate them more than a lot of the things I grew up with. It seems like there is a serious decline in quality of things. I'm not sure what is causing it though, if it is politics, regulations.. practices.. It seems like something has been lost. Is there just not enough comradeship to unify and produce something better? It seems like a lot of the reasons for doing things lately stem on numbers related to statistics and things like that.. WHAT THE HELL FOR?? WHY ARE WE TRYING TO SATISFY AN EQUATION THAT ISN'T REAL?? Let's focus on important things people and do something for humanity that actually means something.

I don't have any particular opinions about the overall quality of new and older cartoons, since kids' cartoons have been low-effort, low-budget affairs for at least 30 years. Don't nostalgia very hard when I watch cartoons from my childhood, because they were just crappy pacifiers for big kids. But there's definitely a shift, beyond just cartoons.


Technology is the greatest driver of social change (a timeless fact). Gist of it:

use of modern technology -> instant gratification & control of experience -> shallow thinking & short attention span -> old media changes to stay relevant


Not quite so bad now, but we might foresee:

-> children don't develop a taste for demanding media -> no demanding old media viable; new media doesn't take up the slack (its bread is buttered) -> entire generations of inept gullible fools riding currents of an ocean of shit information


Given enough time, I think Huxley's predictions of tyranny through pleasure would come true (I doubt enough time is given). Bear in mind most of us on this forum are part of the problem, or at least striving to be so. But, again, it's a matter of an irresistible historical force, not individual choices.

Whether it turns out even being a problem remains to be seen. If we don't see a hopeful trend within a few decades, we're boned. In the meantime, it's important to consider these things, lest you slip into ignorance or hypocrisy.
inb4 scoffers

[Blockland]

Add this one! Blockland - http://steamcommunity.com/sharedfiles/filedetails/?id=95710780&searchtext=

First I was thinking "Great. Another Minecraft clone...", but NO, HELL NO!

It's awesome! The game was released in 2004 (before Minecraft) and have a lot more than i was expecting. Just checking the videos I was laughing and be amazed! Definitively a thumbs up!

Haven't played Blockland in years and years. Looks to have come along nicely.

Structurally, it's nothing like Minecraft. Nonetheless, I think it's better for creative building, because you can do finer detail & more variety on a similar scale- every cool thing I've seen in Minecraft has been built big by necessity. And a good variety of solid colors beats the hell out of a few peculiarly ugly textures. I'm blown away by that Myst Island shot!

Highly recommend you guys check it out.

1. I didn't need the flexibility

Yeah I haven't yet either. There are plenty of games where it'd be important though.

2. My inheritance hierarchies were never that deep to begin with

An equally important aspect of component systems is they do type-wide updates all at once. Compared to spasmodic flickering between various types doing various things, this way it's much easier to keep track of dependencies, to reproduce & track down bugs, and to have consistent gameplay (because dependence on trivialities like order of entity creation is lessened).

Easier for people, and one hell of alot easier for the computer to process.

You can still do this without a component system per se in a traditional hierarchical solution by going through all the entities, seeing if you can downcast to the type in question, accumulating a list of the instances, then processing them. But it's a kludgy, ugly, & slow hack, and you're better off with a component system. In your case it's be even harder, since you need info about which components are aggregated by which entity types. Only practical way is to aggregate all components of one type in one place, and you're back where you started: an EC system.

3. It comes at a cost of increased complexity

Shouldn't do. For accessing a component within an entity in a simple system (such as my latest), you only need

getComponent<Type>()

Keeping track of what components are in an entity shouldn't be necessary, but if it is, each entity can have a bitmask with a bit for each type. Handling complex hierarchies or even graphs of related entities is a bitch (I assume this is what you mean by how an entity "type" is defined), though I don't see how your solution helps with this. At least with EC you can develop tools & techniques to deal with this kind of thing consistently.

4. Too much of my functionality was specific to an entity type

It sounds like your expectations of the breadth of problems solved by EC were too high. To be fair, EC has been way oversold, so disappointment is inevitable. Waiting for Crimsontide's in 3, 2, 1...

Of course it's practical to hard-code the distinction between various kinds of vehicles, whether through a Vehicle component with a type enum or a component for each type. Note that if you needed various models of fixed-wing aircraft or hovering craft, having these two components wouldn't look silly anymore (provided they were renamed).

PS if you're using C++ DO NOT EVER ATTEMPT EC PLEASE FOR THE LOVE OF GOD

Wait, why not?

I don't think you understand the definition of scripting.  If you use Unity, every single line of C# code you write falls into "scripting".   Unity is the engine, it handles the scene graph, render execution, the actual meat of collision, etc.

That's an awfully pedantic and impractical definition of scripting. Scripting is simple procedural & particularly high-level gameplay stuff that even artists and such can do, not big systems programmers work on (of which there's more than rendering & physics- not that existing solutions for either are necessarily adequate). You can do either/both in C# or Actionscript or whatever modern language, it's a question of expedience given the actual nature of the work.

Point is not every game benefits from a distinct scripting solution.

[everyone will have a computer twice as powerful]

C/C++ for game engines, other languages for games.  Write games not engines.  Quake was written in an interpreted scripting language (google QuakeC) the engine was written in C, and that was "back in the day".  You gonna tell me Quake wasn't a big project demanding C/C++? 

For tight computation, yea C/C++ is a lot faster, wanna know whats faster?  The GPU. 

Oh how cute, you wrote a high performance physics engine in C/C++, too bad its not as fast as one with hardware acceleration on the GPU.

By the time you get done writing your pure C/C++ game cause its "faster" everyone will have a computer twice as powerful and your point will be moot.

Anyways, for a Total War game, I'm guessing the biggest computational expense will be AI.  I'd suggest precomputing as much as possible (especially if you don't have dynamic maps).  If you find yourself bumping up against computational limits and are willing to go with AIR (same code as Flash, not playable in browser), then you have the ability to use native C++ extensions, and regular Flash now has multithreading, so that's another option.

A Total War-like game doesn't have much use for scripting. It's a solution looking for a problem. Flash is a terrible choice if you wanna scale up as far as Total War games do.

I mean, Shogun came out in 2000, when such a thing became technically feasible. So in principle a modern mid-range machine could run Shogun implemented in Actionscript, but I think the optimization work required to get you to that point would be egregious. If you used native C++ extensions, you'd be working on them 99% of the time as they comprise 99% of the game, and the Flash shell wouldn't be so useful.

I recommend C# with XNA or Unity. You can get away with writing even your performance-critical systems in it, while the language is usable enough to be productive in writing the other stuff as well. Strikes a good balance. Same could be said for Java, I just strongly prefer C#.

The caveat is system requirements. Lower-level languages naturally have higher ceilings for optimization, and how fast is fast enough depends on how many end-users (who run shitboxes) you omit.

An example is The Binding of Isaac. It's a good game, but when I bought a bundle with it, I only had access to my aunt's old iMac from around 2007. The game often slowed down to like 4 FPS. That's inadequate. No reason a machine like that shouldn't be able to run a small-scale 2D game. (note that Flash's vector drawing was the problem, not its general computation)

As a note, no company has succeeded at what you are suggesting...

But AFAIK nobody has tried it. Nobody has furnished this thread with any examples of such.

Read that article. It is good. It illustrates the key point. Users are almost always wrong. Feedback always has to be interpreted somehow.

There are however limitations. For instance, testers thought the sprinting speed was too slow, but this was due to the boredom of crossing vast empty distances (which remains to an extent in Borderlands btw), due in turn to joylessness of locomotion. In other words, the solution was a crutch; both devs and testers were wrong. Balance suggestions are more meaningful the better the mechanics.

The skag example isn't relevant, while the reload one is the most enigmatic. For one, Borderlands requires a vast range of reload speeds, ~0.2s-8s. Reloading isn't too slow w.r.t. combat, despite the testers' protest- they really were saying the animations suck. Perhaps you could make a game with as abstract of graphics as you can get away with first, then balance it, then go back & finalize good graphics that are harmonious with the balancing, but I'm sure this is impractical (particularly because few sign up to play an ugly game).

Or maybe you could hire good artists. Borderlands was fuck-ugly pre- and post-redesign.

If you want to balance small things, 5-10%, then you're only balancing a little. So yes, the inter-dependency drops, but so does the effectiveness of that balance. In simpler terms, if you want the players to do significant balancing then you need to care about inter-dependency; if you want them to do only minor balancing, then you need to care less. In the latter case you can get away with tricks...

Yes, together the users have a strong voice, maybe even a more insightful one. But, they don't know how to collaborate effectively. Even a 5% change will have proportionately large results. You can't say that 5% is so small that it can't break the game. It can break the game, and it will. If a bad 40% change is bad, then a bad 5% change is bad...

This is the situation you are talking about. Players play the game a lot. Then they say, "hey, maybe gun X should be 5% stronger."...

So let's assume, somehow, that users vote for a 5% change, and they're right. Most of the time they will not be. Understand that. In fact, they almost always will not be. Ok, so let's assume that this time they are right. Now, you need the system to determine that this change is a good one. How do you do that?

That wasn't the point of the 5-10% figure. ~40% (i.e. +/- 20%) happens to be a pretty typical window for balancing a number. If you go way beyond that, it's a sign you didn't pick decent initial estimated values (OTOH it may be important for some subgenres of game).

Although the relationship between votes and new numbers is non-linear & complex, a single vote would only account for a change of maybe 0.001%. So if even chunky 5-10% changes, however sub-ideal they may be, do not introduce massive instability through lack of insight, then it's absurd for tiny changes to do so. That was the point.

This granularity also implies it's impractical to determine whether a particular change was good. I don't think it's even useful. Or, if you go down that road, throwing lots of complexity at the problem, the system wouldn't do useful work anyway (above and beyond serious logging techniques married with traditional top-down balancing).

Now, it's no coincidence that when numbers change in a multiplayer game, it's a small subset of all the numbers. If there were chunky changes in every single number, the consequences on gameplay revealed through testing would be intractable, absolutely impossible to attribute properly to particular changes, even for the best developer. It's a curse of dimensionality thing. Each number is a dimension, of which you could have hundreds.

Hence, what you're proposing would only work if a small handful of numbers were up for change at any time, and there was lots of testing over considerable time in each of these 'rounds' or whatever. AFAICT it reduces to traditional techniques plus lots of procedural dead weight. Interdependence is why whether a change was good is an unanswerable question. In any case, it has nothing to do with the advantages I foresee in my proposal:

Okay, so you have a ~200 dimensional space, and somewhere within lies a point that's ideal balancing. You want to get (as close as possible) to that point. It's not quite as dreary as it sounds at first, because developers are fantastic at estimating the point's location, and setting reasonable min/max windows, thereby eliminating massive parts of this space. The human mind is great at fuzzy multidimensional thinking. It falters more when it tries to get more strict & numerical with large dimensions, while balancing is sensitive to smallish changes- hence its difficulty. Gotta get damn close to that point to have really good balancing.

W.r.t. interdependence, since in my proposal every number is changing constantly, more of the balancing space is sampled than if only a few numbers are chosen to fiddle with, and without the bias that comes with picking certain numbers. Plus, the space is sampled much more rapidly. Yes, the delay between balance changes and reevaluation of strategies is a problem, but it's at least as much so with present techniques (where each chunky rebalance shifts strategies considerably all at once vs. slowly drifting values shifting strategies continuously).

Again, the crux of the issue is whether players' votes are good enough to survive any conceivable weighting system. Players can certainly sense proximity to good balancing, most games being near-universally considered well or poorly balanced. But can they use game experiences & knowledge of its mechanics to make decent estimations as to how to navigate from present balance to 'good' balance by looking out across high-dimensional space? (remember: they only need to know direction, not magnitude, simplifying the process compared to what devs do)

Tons of other issues, like getting stuck in local maxima in balancing space, but they're not peculiar to the idea (although their solutions may be- your idea of instancing with various sets of numbers might solve this one).

No, I was justifying my conflict with your occasional dismissiveness. I'm not speculating a whole lot. I'm exploring the best way to explain these issues, because in my head it's all AI nonsense and there isn't a common language for that yet. If we worked together it would be much easier to relate ideas. So I explore the best way to simplify mine.

What you construe as dismissiveness is actually me trying to keep scope down, keep it brief (see how that worked out), identify crucial issues, and guide the thread towards resolution. I know how taxing tl;dr wars of attrition can be.

You are speculating, as am I, about an experiment, the result of which neither of us can pretend to know (my guess is an unconfident affirmative: it should work in many cases, but I won't put money on it). Hence I think the thread's (nearly) run its course. The theoretical issues raised are fascinating & helpful, but they've become exhausted, along with the thread's purpose. What's left now is a debate that'll soon go round in circles. Parts of your proposals are compelling, but mostly you're steering in a direction so far from mine that I'm no longer vested in the outcome (I wouldn't go out of my way to test it myself). On that note:

My current game has balance inside-out. It auto-balances all the time, according to how players play. That's a far more effective method than letting users mod. There are "mod" opportunities but they emerge naturally from the game's rules. "Modding" (i.e. balancing) doesn't exist in a separate system.

This sounds fascinating, as I've never heard of anything like this. Please make a thread on it.