Ludum Dare 32 - Page 6

Ludum Dare 32

Moderator: Content Developer

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Ludum Dare 32

Post by Silentwings » 22 Apr 2015, 21:44

At the moment it just uses vanilla Spring pathfinding, which afaik only allows 8 directions.
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Ludum Dare 32

Post by smoth » 22 Apr 2015, 21:45

ah same thing that old halloween project had an issue with
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 32

Post by gajop » 23 Apr 2015, 05:23

smoth wrote: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?
You can pull stuff as Silentwings said. The fact that you can push blocks through walls/on walls is because we failed to make the collisions work well in the time we had.
I wouldn't say it was only that one bug, I'm not sure yardmaps would've fixed things entirely the way we would've liked.
There are many issues in the way Spring handles collisions, and most of those are at the way Spring was designed. I'll make a thread on that once all this is over.

PS: I have no idea what the 8 direction thing is. Does that mean you can move Spring units in only +-x, +-y, and +-z, or what?
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Ludum Dare 32

Post by smoth » 23 Apr 2015, 06:41

n,ne,e,se,s,sw,w,nw
Image

I could be wrong but the unit stair step on certain angles.
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 32

Post by gajop » 23 Apr 2015, 07:29

smoth wrote:n,ne,e,se,s,sw,w,nw
Image

I could be wrong but the unit stair step on certain angles.
I see. I don't think that's such a huge problem though, but it would be nice to have if we stick to mouse click movements (which I think we should: dota style movement ftw).
I think collisions are a much bigger problem though, and the cause of jitters/inconsistencies
EDIT: I played it a bit more and you're right. It does look kinda bad and should be fixed.
0 x

User avatar
smoth
Posts: 22298
Joined: 13 Jan 2005, 00:46

Re: Ludum Dare 32

Post by smoth » 23 Apr 2015, 13:08

Image
Keep in mind, I used to play around with this concept but the whole 8 directional thing kinda put the nail in my ideas for a beatemup in spring.
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 32

Post by gajop » 23 Apr 2015, 13:18

Post Mortem

ashdnazg:
The Good:
  • Working as a team was fabulous. Making this game would’ve been impossible without utilising the knowledge, expertise and abilities of each member.
  • The warmup was extremely crucial for understanding the work process, the scope of what we can achieve in 2-3 days and getting to know the team members and the resulting dynamics.
  • Github issues were extremely useful in keeping track of what works and what doesn’t. More labels (art/code/etc.) could could probably make it even better
The Bad:
  • I think picking a genre (Action/Puzzle) that doesn’t fit the engine (RTS) caused 90% of our issues. While it does make the entire development more interesting (which is very important!) it doesn’t make the gameplay better (which is a tad bit more important). When using a specialised engine, picking a closer genre may result in better games.
  • Music could use some improvement probably. I didn’t have any muse so I just made something simple and put it in low volume.
gajop:
The Good:
  • Warmup was essential, we wouldn’t be able to do half of what we did if it weren’t for it.
  • Github issues were great and so was mumble.
  • Most of the time people handled their responsibility well. There were very few cases when person’s A work conflicted with what person B was working, and you could rely on other people’s stuff to work.
  • The end result showed many new possibilities in Spring and was drastically different than any of the currently available games.
  • We made a game that I actually enjoyed playing even though I made the missions.
The Bad:
  • There were too many issues with the Spring collision system. Getting the walls to be blocking while not completely ruining pathing and impulse and having them displayed seemed impossible. This wasted much time and is still unresolved and causes the game to be jittery (it also had a huge impact on balance and made it much harder than it was originally designed to be - when there were no wall collisions implemented).
  • The full game and level design should have been written in advance or at least updated.
  • There was some miscommunication in the art requests. We ended up having duplicate gate textures, unused ground decals + textures, unused barrels and even a boss fight that wasn’t well designed. All this was done while the first robots you encounter in the first 5 minutes of playthrough didn’t have death animations (the same goes for exploding walls).
  • A better tested engine (this one seems to have ground rendering issues) as well as support for multiple specs: Low/High and an optional Medium spec as well. Different .sh and .bat files would suffice, but this needs some prior testing.
The Bad (minor):
  • Maybe a single top-level repository could have been used instead of this many. Most team members didn’t get to test the mission until late in day 2, while some didn’t do it until release. This should’ve been simplified yet still allowed for some degree of separation.
  • Slight improvement in the tools (Scened: generate build icons + better handling of /luaui + /luarules reload), as well as a better pre-existing game setup. Scened could also be made to generate .sdds as project files instead of custom project dirs, and having it enable/disable widgets (through the widget handler) instead of writing custom “if devMode then ..” would allow for better modularization
  • Engine needs to be extended to allow for in-game editing of specular, normal as well as diffuse void maps.
  • We still had damage happening by pushing stuff. This was against the mission design and completely screws up balance (there are robots that are immune to fire and are supposed to be either thrown into stun fields or killed by throwing them down from cliffs, which can be circumvented by just pushing them to each other, and that trivializes it).
  • Should have waited with polishing the map until after the final models have been made. Many of my changes turned out to be unnecessary due to the different models (width and shape).
Silentwings:
The Good:
  • We worked together very well.
  • Our skills were a good spread across what was needed.
  • Github+mumble was an effective mix of ways to communicate.
  • The warmup weekend gave us some handy code & an idea of what was realistically achievable.
The Bad:
  • It was a shame to lose quite a bit of time to an engine bug.
  • We had very little time to playtest, although idk how we could have found time.
Anarchid
The Good:
  • We have met our objectives and answered all the challenges, proving our divine mastery of the Spring RTS engine.
  • We have shattered the dominant paradigm in 72 hours. The game doesn’t even look like you expect a Spring game to look.
  • I gained the ability to use Mumble. Awesome!
  • Warmup was essential. Dragging our specialized tools to answer challenges was too.
  • Teamwork occured and was fun.
  • I learned to make textures from scratch. That stuff isn’t even *that* hard.
  • Being actually able to use non-manually-coded-but-artsily-created-in-blender animations in a live project all working flawlessly from the first attempt felt like a Crowning Moment of Awesome.
The Bad:
  • Spring physics suck. The same game done in Godot would have been faster and better.
  • There was a ton of time lost on figuring out various bugs and the voodoo that is Spring collision volumes
  • The controls are really unintuitive and we could have spared time to fix that, completely abandoning the RTS tropes.
  • Despite having an intel gpu person in the group, we didn’t have any fallbacks for fire and electricity
  • Way too few particles effects in general.
The Ugly:
  • 5 robots in the first room is enough to kill people, and yet gajop complains that they take damage from being splattered on walls!
  • We had two different art pipelines and two different animation code systems, making fixing stuff sometimes impossible.
  • That Crowning Moment Of Awesome? Is just par for the course everywhere else outside of Spring.
  • My computer melting down meant i had to use one with an Intel GPU -> we had no shader textures on most of the models. Speculars and emission would have added a *lot*.
Picasso:
The Good:
  • Realized on first day afternoon that it actually is LD ( - as in at this very moment, where the fuck are you!)
  • Springs Metall looks still awesome, and shows that good default shaders can save a day.
  • ToolKit needs a splitup by purpose
  • Functions in Toolbox proofed reliably reusable which is nice..
  • Don t remember much of the texturing was really groggy then
  • Made some nice Giger Trees
The Bad:
  • Didn’t quite grasp the whole warmup concept. Actually though that we would continue with corruption.
  • Everyone in Spring has his own approach. Approaches dont mix really well.
  • Physics. Should have put a bullet into spring ages ago. also advanced Physics not for all units.
  • Botched the unitscript- Unitscripts should have a threadnumber limit.
  • Still cant blender well
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 32

Post by gajop » 23 Apr 2015, 14:45

smoth wrote:Keep in mind, I used to play around with this concept but the whole 8 directional thing kinda put the nail in my ideas for a beatemup in spring.
I wonder how hard it would be to add support for that.
It doesn't sound that difficult, just a rework in the pathfinder?
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: Ludum Dare 32

Post by Kloot » 23 Apr 2015, 15:40

Please inform yourself about how grid-based search algorithms work before committing the all-time stupid "how hard can it be?" fallacy.

Pathfinding that is not bound to a set of cardinal directions more or less requires navmeshes, which are a bad fit for heightmap engines.
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 32

Post by gajop » 23 Apr 2015, 16:39

Maybe I'm misunderstanding something, but a quad-tree based pathfinder should be able to generate paths like this: https://www.youtube.com/watch?v=95aHGzzNCY8
It's still not what's wanted in our case, but at least that's not 8 directional.
I understood that it was claimed that the current pathfinder system can't do that.
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: Ludum Dare 32

Post by Kloot » 23 Apr 2015, 17:20

Spring has two PFS implementations, one of which is a quadtree-based pathfinder I wrote called QTPFS.

It supports locally non-cardinal paths and might work better than the default with your game, but there's only so much design freedom allowed by an underlying heightmap representation.
0 x

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Ludum Dare 32

Post by Silentwings » 23 Apr 2015, 17:45

Hah, I was just thinking today that we ought to try out QTPFS with this.

Two other things that could improve the controls:
(1) Proper colvols - the current ones for robots in particular are too small, sometimes you click to attack them and "miss".
(2) Set target, so as Gravit can use his gun and hvae his movement controlled at the same time.

I'll try this lot out at the weekend.
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 32

Post by gajop » 23 Apr 2015, 17:53

Kloot wrote:Spring has two PFS implementations, one of which is a quadtree-based pathfinder I wrote called QTPFS.

It supports locally non-cardinal paths and might work better than the default with your game, but there's only so much design freedom allowed by an underlying heightmap representation.
Ah I see, so the default PFS doesn't support local non-cardinal paths.
I tested QTPFS and I can confirm it works much better for us (we have large empty areas so it's mostly local pathing). Unless there's a gotcha (and I don't think there is), we'll use that for now (we might replace it with raw movement for the character).
0 x

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Ludum Dare 32

Post by Silentwings » 23 Apr 2015, 18:02

Unless there's a gotcha
My experience of testing it (which is now well out of date) was that the only drawback was higher cpu/mem usage. Ofc for us that doesn't matter.

I thought about raw movement too, but it'll probably just result in him walking into things. If thats going to work at all it would have to be for tiny distances only and include some hack to mean it also only works on flat sections (which on our map is not such a bad hack). I guess it won't be worth it.
0 x

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Ludum Dare 32

Post by Silentwings » 24 Apr 2015, 18:37

We tried it, QTPFS works awesomely for this. ++Kloot.
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14585
Joined: 17 Nov 2005, 02:43

Re: Ludum Dare 32

Post by Forboding Angel » 24 Apr 2015, 22:22

With the way evo unit movement works now, I should try qtpfs again. Iirc my only real beef with it was that units would get stuck on buildings. It occurs to me that I should recheck the yardmaps on any building the units get stuck on, just to make sure that the map is correct and not feeding garbage to the pathfinder.
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7015
Joined: 16 Nov 2004, 13:08

Re: Ludum Dare 32

Post by zwzsg » 27 Apr 2015, 11:22

I forked Gravitas to give it a more direct style of unit control:
https://github.com/zwzsg/Gravitas
  • Move with Arrows keys or WASD
  • Jump with Middle Mouse Button, E, or SPACE
  • Push with Left Mouse Button
  • Pull with Right Mouse Button
0 x

User avatar
Shadowfury333
Posts: 55
Joined: 25 Sep 2006, 00:32

Re: Ludum Dare 32

Post by Shadowfury333 » 07 May 2015, 08:03

I did a playthrough of the May 6th version on YouTube. Took me 4 tries, but I beat it in the end.
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 32

Post by gajop » 07 May 2015, 09:39

Great, thanks.
In addition, this video was made using a newer engine version (604) which adds the default script and isolated mode, so we no longer need a bat or sh file.
It also completely breaks the missile launcher, but that stuff isn't as important anyway imo. I thought I used an engine version that didn't have any of the recent weapon changes, but guess I was wrong.
The Gravitas version is unchanged (doesn't have a smoothed map or the last patch to prevent stuff going on wall).
0 x

User avatar
Silentwings
Moderator
Posts: 3585
Joined: 25 Oct 2008, 00:23

Re: Ludum Dare 32

Post by Silentwings » 07 May 2015, 18:53

Thank for you making that, enjoyed watching :D
0 x

Post Reply

Return to “Ludum Dare”