Spring RTS Engine

gajop wrote:Windows version is not isolated (Linux one is).

This caused it to take roughly about 5 minutes to load due to it building archivecache. If you're going to distribute something like this, you need to isolate it.

As far as the gameplay itself, I couldn't get past room 3. I tried pushing the cubes into the spiders to push them into the flames, and that didn't work. I tried dodging them and trapping them in the first room and died before I could pull that off.

The character movement is awful. It's clunky and slow, not like a dungeon crawler should act, so I went in and gave my character turnrate 5000 and turninplace true and the game was instantly much more playable.

I got past the 3rd room, but I don't understand the big room. I tried using the canisters to damage the walls (I thought that's why the fire was there), but they usually flew through the walls, so that's not the answer.

Tbh this game really suffers from spring's grid pathing. It makes the game quite jarring. There is another far more serious issue though, the lups flames used cause extreme cpu lag for me. To the tune of 500ms or so. Bad enough that playing becomes quite difficult. I wish you guys had asked me. I already have some CEG flame effects that would have been just as good for nowhere near the performance cost of lups.

It's impressive, that's for damn sure. I like it, but it does need some spit and polish here and there.

I got past the 3rd room, but I don't understand the big room. I tried using the canisters to damage the walls (I thought that's why the fire was there), but they usually flew through the walls, so that's not the answer

You need to place one of the canisters into a flame, preventing it from overshot by strategically stopping the attack. At least that's how i did it.

The alternative option is, of course, to scale the wall.

I wish you guys had asked me

Hop in next time?

All in all, we still have to write a proper postmortem because a *lot* was learned. One thing i'll say though is that i'm going to keep using these screenshots as an example of "how to shatter the dominant paradigm in three days".

Oh, and i finally got to use blender2lus at full speed, guns blazing. It was a good thing. I was able to do the four-step jump animation from a single attempt, and I laughed so maniacally and so loud that i heard my own echo over mumble.

I did get past the 3rd room, on second attempt with less vigorous clicking :D Handling the spiders is actually quite easy once you get the hang of it - I like. Made it over the first jump but had to leave for work at that point so I jumped back in it and killed myself.

This caused it to take roughly about 5 minutes to load due to it building archivecache

Not for me - only those with large numbers of sdd/sdz are affected afaik, which ofc LD players don't have. Isolated would be better ofc, but afaik I was the only Windows user on the team and I was long gone to bed at the time it was getting packaged.

the lups flames used cause extreme cpu lag ... I already have some CEG ...

I guess you didn't profile - the cause of the cpu lag is from LUS (https://github.com/SpringCabal/Gravitas/issues/84).
Just fyi, all artwork (incl lups effects & models/scripts/textures) had to be made during the 72h.

I've tried giving 100 gravit on a neutral map and having them jump, run and shoot around for 5 minutes with no notable loss of FPS.

Needs more investigation.

My first guess is that its related to the robots, based on how the profiler reacted to my game playing, but I haven't investigated much. But lets keep development discussion for github/mumble and leave this thread free for "normal" discussion.

I got to the 11th room on a try now before combined LUPS made everything unresponsive and I died. This is probably good seeing as how the 12th room (puzzle) is bugged.
I don't think it's that hard, although there was no time to balance it.

Forboding Angel wrote:f, I couldn't get past room 3. I tried pushing the cubes into the spiders to push them into the flames, and that didn't work. I tried dodging them and trapping them in the first room and died before I could pull that off.

I thought it would be obvious that you could also push robots. Not sure how to present that better :S

Forboding Angel wrote: The character movement is awful. It's clunky and slow, not like a dungeon crawler should act, so I went in and gave my character turnrate 5000 and turninplace true and the game was instantly much more playable.

I think the character movement was fine, although there are many issues regarding collisions still present... That deserves a special thread later on.

Forboding Angel wrote: I got past the 3rd room, but I don't understand the big room. I tried using the canisters to damage the walls (I thought that's why the fire was there), but they usually flew through the walls, so that's not the answer.

I think I failed in mission design here. Initially Anarchid made an explosive barrel, but it got replaced with these small canisters, which really don't have an obvious "I can explode" mark on them. Maybe I should've used the original barrels even though they didn't have a sci-fi vibe to it.

Forboding Angel wrote: Tbh this game really suffers from spring's grid pathing. It makes the game quite jarring.

I think that's not so much pathing as it is impulse/collisions.

Forboding Angel wrote: There is another far more serious issue though, the lups flames used cause extreme cpu lag for me. To the tune of 500ms or so. Bad enough that playing becomes quite difficult. I wish you guys had asked me. I already have some CEG flame effects that would have been just as good for nowhere near the performance cost of lups.

I'm not sure why, but it seems our current resources take more and more memory until they become unusable.
We couldn't just fully copy your effects since we still had to make our own art (all art you see here was made during the 3days).

Forboding Angel wrote: It's impressive, that's for damn sure. I like it, but it does need some spit and polish here and there.

No kidding! I think we needed one more day to polish it all. But we have learned and improved.

Anarchid wrote:Oh, and i finally got to use blender2lus at full speed, guns blazing. It was a good thing. I was able to do the four-step jump animation from a single attempt, and I laughed so maniacally and so loud that i heard my own echo over mumble.

I have to say that seeing Gravit jumping over the void ground (which doesn't look all that good atm) is one of the most enjoyable parts of the game.

I could remake those flame effects in 2 minutes. It's not black magic, all it takes is understanding how ceg properties and behaviors work. At this point I have a pretty thorough understanding.

@anarchid, I legitimately wanted to, but given the general attitude towards me around here, I didn't figure I would be welcome nor that I would be able to contribute in any meaningful way. The above reasons being why I didn't post in this thread at all.

@gajop, dungeon crawler characters need to be instantly responsive. Especially when you need to micro your hero. The lups lag combined with bad hero movement made for a pretty frustrating experience.

@silentwings, it is most certainly lups, everything is fine right up to the point that that fire gets on screen, then it all goes to hell.

@silentwings, it is most certainly lups, everything is fine right up to the point that that fire gets on screen, then it all goes to hell.

it is not.
Actually it was a bad unit script.

it is most certainly lups, everything is fine right up to the point that that fire gets on screen, then it all goes to hell.

Correlation is not causality.

Actually it was a bad unit script.

That.

gajop wrote:one more day...

I think if we'd had one more day, we'd have planned something more abitious to match and could still then use a one more day to polish (& rightly so, too). They don't mind if you fix a handful of bugs & imbalances after submission - the script issue was unlucky, maybe also a couple less robots in that third room, the logic issue with the twelth room. Those are what stand out to me & I'm all for giving it a bit more attention on top (at the weekend, for me) but I don't think we need to fix anything else for LD.

Update 22.04.2015:
- Fixed one resource hog
- Fixed room 12 bug
- Made the game easier
- Made the character control slightly better
- Changed distribution archive from 7z to zip

Silentwings wrote:

gajop wrote:one more day...

I think if we'd had one more day, we'd have planned something more abitious to match and could still then use a one more day to polish (& rightly so, too). They don't mind if you fix a handful of bugs & imbalances after submission - the script issue was unlucky, maybe also a couple less robots in that third room, the logic issue with the twelth room. Those are what stand out to me & I'm all for giving it a bit more attention on top (at the weekend, for me) but I don't think we need to fix anything else for LD.

I think the number of robots is fine. I just buffed the player HP to 2x of the original, his turn rate to 5k, and with your regen buff, I think it certainly makes the game much easier, although you still can get yourself killed if you do stupid things.
Some parts of the game deserve larger balance changes, and the boss fight is just ridiculous.

PS: The collisions are still causing major issues with impulse weapons, we haven't removed radius stuff from the walls (it causes walls to not be rendered, and tbh, GFX are the major selling point of the game now).
PSS: Seems like there's no shader support on many GFX cards and thus no effects. I'd rather game crash in this case instead of getting lower votes because they didn't see fire/ion.
PSSS: I had a student play the game and he got to the boss on first try (I only gave him basic instructions since the tooltips were in Engilsh and fire/electricity wasn't visible). Maybe we should add a game-end if someone is good enough to kill the boss?

Forboding Angel wrote:@anarchid, I legitimately wanted to, but given the general attitude towards me around here, I didn't figure I would be welcome nor that I would be able to contribute in any meaningful way. The above reasons being why I didn't post in this thread at all.

The people who act on their assumptions, but don't bother spending 2 minutes to make them match the territory.

I could remake those flame effects in 2 minutes

I doubt the exactness of this quote Would it still be 120 seconds when minutes actually counted towards a total end-sum?

gajop wrote:PSSS: I had a student play the game and he got to the boss on first try (I only gave him basic instructions since the tooltips were in Engilsh and fire/electricity wasn't visible). Maybe we should add a game-end if someone is good enough to kill the boss?

Yes, there should definitely be a victory condition! Also was that student Korean or something.

Anarchid wrote:

gajop wrote:PSSS: I had a student play the game and he got to the boss on first try (I only gave him basic instructions since the tooltips were in English and fire/electricity wasn't visible). Maybe we should add a game-end if someone is good enough to kill the boss?

Yes, there should definitely be a victory condition! Also was that student Korean or something.

(This is the buffed version I posted today)
He was Japanese, and they mostly just play visual novels and eroge. He wasn't that good really, but I was happy how he managed to figure things on his own, kinda how I intended it (although he also came to some conclusions that are mostly the result of bugs, like the fact you can kill robots by pushing one to another or by pulling them to you).

gajop wrote:like the fact you can kill robots by pushing one to another or by pulling them to you).

Actually our game description mentions that as a feature.

In fact i would have loved if the physics better respected the normal of the ground or collidee colvol when colliding so that hitting walls flat-on at high speeds would make things splatter.

Anarchid wrote:

gajop wrote:like the fact you can kill robots by pushing one to another or by pulling them to you).

Actually our game description mentions that as a feature.

In fact i would have loved if the physics better respected the normal of the ground or collidee colvol when colliding so that hitting walls flat-on at high speeds would make things splatter.

Bad game description (collisions were never balanced)
Maybe we should talk more about the design when LD ends, but in general I think that "kill stuff by throwing them at each other or at the wall" should be avoided, since it trivializes gameplay. Throwing stuff in fire/electrical field, off-cliff, or by sending bombs at them should be far more rewarding as it's harder to pull off and requires a better tactical approach (e.g. "how do I position myself in such a way that I can throw these enemies into fire").
That said, it shouldn't be completely removed, and maybe there should be enemies that can be killed better by collision rather than fire, but it shouldn't be a rule that collision is better than other stuff.
For early bots I think you should be able to kill them by both collision and fire, but the collision should be far less effective, (i.e. take no more than 10% of their health if short range, or up to 40% if higher range (~60% in the case of high collision crate vs robot), where as fire would usually take them out if you successfully throw them in).
PS: I really look forward to develop the game further. I've got many ideas of the enemies/encounters that could be added later on. Maybe even a slight redesign of the original map and gameplay is in order.

I rather liked robots dying when they got pushed into each other, although I agree smashing them into yourself/walls seems a bit cheap.

between the fact that boxes get pushed through the walls and outside of the play area, it creates a situation that makes the game uplayable. Also there is no way to pull a block, only push. Why is it that blocks are able to be pushed through the walls and outside of the play area?

Short answer is because we had 72 hours... longer answer is that there's a bug in the way Spring handles rotation of yardmaps after Spring.SetUnitRotation and we had to do a horrible hack. gajop can tell you details, I didn't touch walls.

If you look at the hotkey information, which is perma-displayed on the bottom left of the screen, it says that pressing q swaps your gun from push <-> pull

I could not tell but did you guys get past the whole 8 direction thing?