Spring RTS Engine

I'm getting alot of lag AFTER, a pure game (using spring.exe, the map gave me some serious water rendering artifacts, till I switched to water 0) sometimes shadows and reflectivity uses 50%, sometimes drawworld, I don't know what's going on, but I guess it's a spring problem.

Argh wrote:Do you have Compress Textures on, or off? IIRC, there's another issue, that's already fixed in SVN, relating to texture stuff.

off

Played about 8 hours of MP last night with DRB. Played lots of rush scenarios and did some extended testing on a number of things.

Made a lot of balancing changes, besides stuff that's been announced here previously.

1. Decreased buildtime for Pillbox. Increased costs, dropped buildtime for Machinegun Nest. Note that these two units may get cut, or change their roles, in the fairly near future. We didn't get to test the new World Builder cities last night, but we'll get to that next week, and I suspect that it's going to change things. When you can just plop down bunkers, and put infantry in them... it's going to be a very different game.

2. Increased hitpoints on Heavy Shell, Heavy Mech, Soldier Shell, Laser Tank, and several others.

The Laser Tank and Soldier Shell are the biggest changes here- they're both fricking viable again, after being totally useless cannon-fodder for some time You still can't charge multiple Resistance infantry who are prone, and expect good things to happen, though

3. Used Slopemod in MoveTypes to reduce the amount of slowdown on steep hills. Really helps, on maps where Engineering Teams need to hot-foot to a number of Ancient Facilities, and the terrain's nasty.

4. Increased movement speed of Engineering Teams and MegaConstructors.

5. Made various economic changes, including faster build speeds for LandFactories, Advance Bases, and Air Bases. You can and will expect to see fairly large swarms of units, especially from Overmind, once they get rolling.

6. Increased decloak radius of Resistance infantry up to 350, decreased their initial range. Big change for them, they're a little easier to spot, and can't completely destroy a rush on flat terrain now. They were taking out heavy rushes by Tanks and even Artillery Shells being micro'd weren't all that effective. Only way to remove them was to use a MortarTank or one of the two bigger Cannons, which we didn't think worked very well at all.

7. Increased capture rate of Engineering Teams, to better-balance for rush strats.

Overall... it started out with lots of big problems, and ended feeling a lot more balanced and nuanced. Early game on small maps is really hardcore now, too- you can expect combat in the first minute, and if anybody seriously screws up their build order, they're out in three or so. I like that. Newbies can play big maps with lots of chokepoints, like they always do, and I'll provide a couple of those.

That said, I think that the ideal small map is just a wee bit bigger- a 10X10. Going to use that as the standard, and rebuild Mesa City (that earlier World Builder demo).

Lastly, I'm going to go ahead and implement a tiered system, where each Factory can be upgraded to tiers 2 and 3, so that certain units may not be built immediately during a rush, which will prevent certain nasty things from happening. Price points / time points TBD, I haven't written the code yet. For AIs, I'll probably have "easy" and "hard" mini-mods, where they either get the upgrades very, very slowly, or get most of them immediately, for greater challenge.

The flat system, where you can build everything at the start, simply isn't workable without disturbing some of the long-term dynamics.

RAI was playing Overmind quite well, with the new map system, and was very aggressive about taking and holding terrain. I will try and see if I can get anything (probably NTAI, if it doesn't have crippling performance problems any more) to really play Resistance decently, I can't get RAI to play it well, even if I give it practically unlimited resources. It's either that, or a simplistic cheating Lua AI.

The only major issues that are somewhat philosophical is that, after very extensive and lengthy testing, it appears that Resistance assault forces performed very poorly in their assigned roles, if Overmind can get to the point where it can stream large numbers of tier 1 things. Resistance has no effective answer to Overmind's static artillery, either, until players can build Ion Lasers (which should, imo at least, be a game-ender). So, both things will need some creative solutions- I think that the Resistance MBT's role will change to something different, so that it handles swarms better while advancing, and a new unit, the T.R.O.L.L., is being built, to also help things out a bit.

T.R.O.L.L.

What does that stand for?
And is it gonna be one of those "ubermech" class?

I would like to announce that I have completed a tiered build system for factories. Took a minute, I found a few behaviors in Spring that, personally, I think are bugs along the way.

P.U.R.E. will now have a system more like most RTS games do, where you have a factory that evolves over time, and you cannot access every item in a factory at first.

The cool part about the approach I'm using is that you can choose which factories to upgrade, so individual tiers of factories can have different stats for build-power, etc., giving me another tool to ramp the gameplay.

Of course the code could go other directions- you could have an AoE system, where you reach an "age"... or a time-driven system for a historical sim, where what's available to build changes due to historical events on an accelerated timeline (which might be interesting).

I have finally finished a whitelist app, for excluding Widgets that should not be used with the game.

It's not entirely perfect, but it's certainly better than nothing. If any Widget makers care whether their Widgets can be used with P.U.R.E., or any players have third-party Widgets that they think are really necessary to play the game well, please let me know, and I'll test them to make sure that they aren't cheats, and if I don't consider them cheats, I will allow them to operate. By default, I will keep most of the stock Widgets that ship with Spring, except for a couple that I consider to be junk, or surplus to requirements because I have something better.

Only major piece of code left to get done for RC4, besides unit scripts and stuff, is a home-built player display, that is pretty and looks right with P.U.R.E.

So...can we have it?

Yes, I'll be releasing it PD, when it's ready and I have examples done.

I'm posting this here, so that hopefully fellow game designers will see it:

COB has some serious issues in 0.78.

Some code that would have previously been correct is no longer correct, and will cause an endless loop condition. Please check every single COB in your games, this is potentially a lock state and will basically make your game unplayable. IDK what's been changed- with the Git stuff going on, and the general craziness of the last three weeks, I haven't had time to follow any last-second changes, let alone test. Hopefully this issue is confined to P.U.R.E. alone- it's pretty specific activity that causes this.

post example code?

Sure. Sorry, it's Very Late, and I'm trying to finish something else.

Here's a typical loop used by certain construction units. There are other ways to write it, but if it locked on this, there are probably other situations that will cause a lock (or maybe it's just that I wrote some very crappy code, I don't know or care, now that I've fixed it).

If you remove that last sleep, then you get a lock state. What I suspect is causing the lock state is that the code:
Is no longer taking a frame to process. I always saw the lock just as the conditions were fulfilled (i.e., wait-for-turn completed).

This is great in a way, the hidden sleeps are a pain, and cause some borked behaviors... but it was scary for a minute.

Wait-for-turns are used for a lot of timing stuff, and IDK for certain if that's the only place where it can cause the CPU to rev out of control or not.

Previously, I'm guessing (and probably wrong, I am in the middle of Something Else, kinda busy atm) that it was treating the end of the section as if it had a one-frame sleep (and then returned) by default, so this is almost certainly "my fault" for assuming that this was safe behavior. At any rate, that's what's up, it's fixed on my end, just thought other people might want to know that a new lock state is possible, before it bites them in the arse.

126 triangles, 256 map. Still working on the map.

I rarely get excited about working on stuff like trees, but in this case I'm making an exception.

Needs some kind of cap instead of the bright branch merging, but very nice tree. That'll make what, 130 tris?

It has a cap, it's just really hard to see. Had to hide it, there isn't any really elegant way (that I could find, at any rate) to terminate the trunks without adding a lot of geometry. I added more leaves near the centers, to make that area feel less bare.

Can't just have a floating hexagon?

No, there's a real trunk there, and everything. I decided that one of the suck factors for trees is if they don't have a real presence when shadows are on. Used 30 triangles for that. The leaves and branches are just quads.

Meh, somebody really needs to make the fragment program use the alpha when doing shadows for Units, just like it does for Features.

This is really not pro:
Shadows off. Trees aren't quite there yet, needs more variety... but it all looks ok.

Shadows on...

I'll sleep on it, come back to making them a little more lifelike tomorrow.

As usual your level design sucks Argh But the trees look great :)

Ok, that was rude. Nevermind, sorry. It's 5 am, I just spent 3 hours on various experimental tweaks, I'm not in the fucking mood.

Time to sleep, obviously.

How can you judge this level's design if you just see a small street?