Refactoring

[NicoM1]

I'll do this soon, but I realized one thing, theres no problem with mixing scripts and hard-code, but they need to be kept distinct or debugging will be a nightmare. Easier to do something with code? Do that entire chunk with code. Want to do it with a script? Do that whole chunk with a script.

[sruloart]

I think hard-code for the conveyor belt, the procedural generation and the camera stuff, while continue to use scripts for the specific animations and entities behaviors. So: You'll have a class that gets an entity group, chooses what entities should be on screen (how many, when and where) and then moves everything to the left. The specific animations and behaviors (like, what does a zombie do when he sees the player) will be scripted like it is now.

[NicoM1]

thats how I feel too, no reason we cant use "components" too, which are hard code linked to entitys, that you can spawn from xml (that was the original form of scripting in iceentity)

[NicoM1]

ok works now but theres a new bug and I'm not sure how its related, might be from stuff yesterday: sometimes a hit on an enemy (in range) is not registered

[NicoM1]

I think maybe its some weirdness with getMidpoint() I checked and it always hits "in range" but it sometimes it will say you're out of range when you're right beside a guy

[NicoM1]

now were getting somewhere...the fuck?

[NicoM1]

ok its better now, not perfect, but better, we can always tweak later, but I'm pretty sure it was just due to the offcenter frames for the enemy, which is fixed, but the animations move the center a lot, so sometimes it seems strange

[sruloart]

I still vote for fixed sized graphics/animations (16/32/64/128) together with real overlaps. I'm not sure it would be better, but this way is less prone to error (well, to an unknown type of error).

[NicoM1]

I don't think it will make any difference at this point, maybe I'll switch over at some point but I dont think its really nessesary...

[sruloart]

The states are now obsolete so there's no point in setup and objects xmls referring to them, better go with scenes I think (Like, intro, tutorial, game) and other supportive xmls (like, HUD) that all the other scenes may use.

The way I see it, the scene.xml (intro/tutorial/game) will be the list of entities (and their behaviors scripts links) which the hard-code Conveyor/MapDistributer/ProceduralSectionMaker (I'm having troubles with how to name it) class places on the map.

Procedural Section Generation:

• I'm mainly referring to to the actual game scene: a group of entities is built from the xml, based on the amount of entities from each kind that you want to have on screen at a section, and is distributed along the x value of the map randomly, based on inter-entity rules ("this entity can't be placed more/less than 120px than this entitiy" etc to avoid graphical / game related problems).
• The background elements probably should have a similar function of their own (and a different group/xml).
• The "retry? 5...4...3...2...1" like scenes can also have their own function (+ group/xml).
• The amount of time per section is determined by the speed of the conveyor belt (how fast do stuff move to the left) and the placement of the "end of section" markdown.
• List of possible entities: Zombies, Rocks, Spikes.
• There's still the issue of random vs fixed: If a user continues his game, he starts with the last section he's managed to get to. Problem is that this section looks nothing like the section he tried to beat (things are placed differently), so this might be a bit frustrating. Then again, I don't really want to design every section by hand (though it would be cool if we could do that, like a level editor, especially for the pre-made scenes).