Parts Needed (LD35)

[gajop]

Parts Needed is out*!


You can play it at this link: http://ludumdare.com/compo/ludum-dare-3 ... &uid=52862 . Hope you can enjoy playing it as much as we did enjoy making it.

There are three gameplay videos available for it:
Forboding Angel: https://youtu.be/S2tf4NqhsDg
Tech Valley Game Space: https://www.twitch.tv/techvalleygamespace/v/61687671 (first 45ish mins of it)
Shadowfury333: https://www.youtube.com/watch?v=Wzp7YoE4SV8

*since Tuesday actually

[Forboding Angel]

Edit: I was wrong.

[smoth]

This was a big lesson in issues with springs terraforming garbage and trying to craft interior levels. I am beyond frustrated from some of the weird limitations of the engine.

[Google_Frog]

What went wrong with terraforming and interior levels?

[gajop]

Here's our post-mortem

Didn't get anything from Anarchid/smoth but I'll post random chat excerpts.

Anarchid

• "This game has good atmosphere" dude it's raymarched, that's expected
• gpus are terrifying

gajop
Future/important:

• A decal editor will be added to Scened next, as it was quite useful for the jam.
• We should start using WG/GG globals to hold variables that are tracked in multiple widgets and gadgets, such as the “wispID” (player’s unitID). It’s just a waste of time to type it in all places.
• Placeholder models are always taking too long to be delivered, or they end up being the “final” models. In any case they are too detailed so their creation takes considerable time, wastes artist effort and delays programming. I’m thinking of extending Scened to allow creation of simple models within Spring or just learn Blender myself.
• Spring needs to allow for better audio handling. We should be able to control each sound in greater detail, and not just on a channel level. Additionally basic things like track seeking aren’t implemented. This was seen as problematic in both PN (ears music change was odd) and Flove (skipping narration resulted in multiple simultaneous sounds), so it’s obviously important.
• We should just implement a reliable wasd movement framework before the jam.
• Shaders should run more reliably on different machines from now on.
• Better particle systems (not necessarily tied to units like LUPS and a lot more customizable) would be greatly appreciated. Seeing what can be done in Unity with little difficulty makes me want to invest time in making L(U)PS better.

Mistakes:

• Ugly top level terrain textures made the whole game look a lot worse even though other parts were quite detailed (e.g. walls).
• Clutter, as we made it, was a mistake. The boxes in particular suggested things could be interacted with.
• Nose didn’t have any noticeable gameplay element and the separate body part looked odd.
• Ears also had no gameplay effect and the sound difference between music wasn’t obvious (plus Spring is really poor in terms of audio handling capabilities).
• (Coding) terraforming was a complete waste of time, as none of it was used.
• Walls and collisions in Spring. Just kill me.

Success:

• The effect shaders looked very good and were relatively easy to make. Eye being one of the first things people get (and thus able to transition between states) was a good choice as it had the *wow* effect.
• Audio was very well done and it fit perfectly well with the other parts of the game. Considering this was done blindly it was quite great.
• The final game didn’t have any game breaking bugs or performance issues.

greze

• I think we had an original idea, especially after seeing things that other people made
• I’ve only seen video of people playing the game, so I can’t really say how well some things worked, but it looks like the game progresses very slowly
• The atmosphere turned out really well, I think we were able to capture the mood we were shooting for
• It seems to be confusing for players, both in gameplay and story (watching that guy try to mess with the pressure plates before having legs was grating)
• I don’t think all the sounds I made read as what they were supposed to represent, some were too quiet, and the difference in the music was pretty subtle
• It was my first LD, but I’m impressed by what we did. I especially think it’s cool that our game is made in a RTS engine, but isn’t really that kind of game

smoth

• it pisses me off a great deal that I did all that effort into details for the walls and stuff but didn't get the time to do one more splat :\
• NO THUMBS.DB bullshit (this time)
• we spent a lot of time discussing player experience; we need a whiteboard app; so we can draw up a basic level and what we need; that way a task can be written up for important parts that need test types
• at least (we) succeed to give a player experience.

[Anarchid]

Seeing how i absenteed for actual postmortem post, i'll post up my thoughts as a follow-up.

1) I need to be better at explaining unorthodox ideas, and to use pictures to explain those unorthodox ideas. Merely attending the First Hour is insufficient to shatter the dominant paradigm (that is, shatter it further than we already did).

2) The play game looks really cool but it also is mostly a subset of Gravitas' features.

3) The feel game is something completely new: we've gone for "player experience" and it's an interesting thing to experience trying. Definitely lessons learned.

4) Shaders are powerful and terrifying. Semi-incited to try getting a SSAO shader before next LD or maybe figure out a proper "materials" pipeline. The wow-factor was immanent here, but we can go deeper.

5) I am not satisfied with the modelling that i've done. Some placeholders ended up final, and generally the stuff that ended up final was meh. Despite people saying that the protagonist was uncanny and scary, i don't think it was a good kind thereof.

6) What gajop said about sounds! Sounds are paramount for immersion, and i've been craving for finer control of sounds (especially looping 3d sounds if you know what i mean) since 2008.

[smoth]

I liked your main character model, it was sureal and lacked, gender, race or anything else that would trigger a whining millennial. It was human enough to identify with but also very surreal.

What went wrong with terraforming and interior levels?

even if they are placed with a line command, the depression in the ground isn't connected, I ended up with a bunch of vertical walls coming up between my placed units forcing me to ultimately go with skooching the height field bit by bit to get it as close as possible. The time micro adjusting the heightfield took was around 8 hours.

It was a neat test but after 7 hours of playing with it in engine, creating assets etc I was pretty irate that units placed in a grid could not evenly displace the ground if you would like we can start a side thread about this.

[gajop]

What went wrong with terraforming and interior levels?

Smoth tried to have models define the rooms, by placing wall and ground pieces, he would just have a script reduce the height by a certain amount and thus automatically generate the heightmap.

@smoth
I think the problem with your approach was the difficulty of writing the code required to pull something like that off. It is very tricky to rely entirely on models and their footprints or colvols to alter the heightmap. I even abandoned using hokomoko's gadget that we had for Gravitas which controlled gates, as it wasn't working properly for whatever reason, and in the last few hours I didn't have the concentration to do math problems. I think it's still possible to do right, and not really an engine issue, it just isn't very easy.

My far bigger annoyance is that it's just so difficult to do rooms/gates/collisions in Spring correctly.

I'm opening a challenge for anyone to create a rectangular-base (box) wall as a unit, without relying on heightmap, that can block all movement/pathfinding, stop projectiles, be rotated in a 360 degrees angle and block LOS.* Even without the LOS requirement, I bet it can't be done, and I'd really love to see anyone prove me wrong. I think this is essential for the future of Spring, not just for the dungeon games we make in LD, but also for games such as battletech, spring1944, and many others that would be very interesting to see have urban warfare.

*Additional caveat is that this should be done entirely with that single unit, without any invisible-voxel units/features/unit pieces or random hacks to do so. It should be doable using either the Spring API or unitdefs and relying on unit radius/height, colvols, footprint and things of that nature.

[smoth]

I'm opening a challenge for anyone to create a rectangular-base (box) wall as a unit, without relying on heightmap, that can block all movement/pathfinding, stop projectiles, be rotated in a 360 degrees angle and block LOS. Even without the LOS requirement, I bet it can't be done, and I'd really love to see anyone prove me wrong. I think this is essential for the future of Spring, not just for the dungeon games we make in LD, but also for games such as battletech, spring1944, and many others that would be very interesting to see have urban warfare.

feel free to use my wall assets as CC:NC in your pursuit! I have no use for them and they have defs already written in LD35.

[Google_Frog]

What went wrong with terraforming and interior levels?

even if they are placed with a line command, the depression in the ground isn't connected, I ended up with a bunch of vertical walls coming up between my placed units forcing me to ultimately go with skooching the height field bit by bit to get it as close as possible. The time micro adjusting the heightfield took was around 8 hours.

It was a neat test but after 7 hours of playing with it in engine, creating assets etc I was pretty irate that units placed in a grid could not evenly displace the ground if you would like we can start a side thread about this.

I don't understand enough about how you were making the map to understand your answer. Why are units displacing the ground? That ability can be turned off in the unitdef.

[Google_Frog]

I added my turn inertia removal gadget. This significantly improves the feel of the WSAD movement although it could still use some tweaking for smoothness.

[PicassoCT]

What went wrong with terraforming and interior levels?

Smoth tried to have models define the rooms, by placing wall and ground pieces, he would just have a script reduce the height by a certain amount and thus automatically generate the heightmap.

And this is awesome, but it needs support on a engine level. Features and Units should haven /and partially have - a height map bitmask set option relative to there position + the ability to make parts of the texture invisible as long as they exist.

PS: Will go for this challenge, within the terraform limits of springity

[gajop]

And this is awesome, but it needs support on a engine level. Features and Units should haven /and partially have - a height map bitmask set option relative to there position + the ability to make parts of the texture invisible as long as they exist.

I don't think so, the fewer custom engine behavior we have, the better. It's possible to already do this via a synced gadget (see the file linked above), and it's much more flexible to stick to a API solution than an engine unitdef.

PS: Will go for this challenge, within the terraform limits of springity

I explicitly asked that no terraforming be done. A solution that changes the heightmap is invalid.
There are a number of issues that go with the heightmap solution, and I don't want to rely on it.

[Anarchid]

Unit-unit collisions are limited to spheres. Terrain blocking is doable only in 8x8 tiles. Projectile collisions are boxes, cylinders, or spheres. The solution is obvious (but questionable if better than detroit): create blocking invisible structures with radius 4, collision volume being a 8x8x8 box, blocking 1 tile of yardmap. Use these with movectrl to approximate desired geometry minecraft style.

Then go buy new hardware because a a Gravitas wall segment with dimensions 136x64x256 will have 4352 of these ghetto voxels if you fill out its volume. If you just fill out one of the larger faces (as you would with a wall or a door), that brings you a massive optimization: now you have only 544 units per wall segment, not counting the unit that will carry the visual.

I am fairly sure that this technology will work. Is there any reward for actually implementing it, or can we just agree that this is madness and engine support for non-spherical unit-unit collisions will be required for a sane implementation?

[gajop]

I am fairly sure that this technology will work. Is there any reward for actually implementing it, or can we just agree that this is madness and engine support for non-spherical unit-unit collisions will be required for a sane implementation?

Avoid doing that of course.
Currently I think the best course of action would be to fix rotatable non-square yardmaps.
Adding engine support for custom colvol unit-unit collisions would be the next step IMO.

[smoth]

PS: Will go for this challenge, within the terraform limits of springity

I explicitly asked that no terraforming be done. A solution that changes the heightmap is invalid.
There are a number of issues that go with the heightmap solution, and I don't want to rely on it.

yeah I am just putting the art assets out there for anyone who wants a go a the proof of concept. that way you can have some assets to work with.

Speaking of, Gaj, I need a place to store model and map sources, can we just make a dir for art assets something like

-CabalArt
--models sources
---ld35
--maps sources
---ld35

that way we can also create resources for those who need them?

[gajop]

yeah I am just putting the art assets out there for anyone who wants a go a the proof of concept. that way you can have some assets to work with.

Speaking of, Gajop, I need a place to store model and map sources, can we just make a dir for art assets something like

-CabalArt
--models sources
---ld35
--maps sources
---ld35

that way we can also create resources for those who need them?

Map sources probably can't be put in a separate repository, as maps are often larger than the allowed size for Github repositories.
Models sources could be done like that, although the other option is to just put them in the same folder as the game, like we did for Area17: https://github.com/SpringCabal/Area-17/ ... delSources
I'm not sure what would be better...?

[smoth]

for map sources it is the worldmachine file, not the huge assed map texture.

[gajop]

Results are out!

#101 Mood(Jam) 3.85
#209 Audio(Jam) 3.52
#243 Graphics(Jam) 3.89
#423 Innovation(Jam) 3.20
#507 Overall(Jam) 3.27
#514 Theme(Jam) 3.38
#754 Fun(Jam) 2.85

Discussion:

On a first glance they look awful, especially with the very low Fun and Overall ratings, which tend to be highly correlated, but I don't think it's all that bad. I'm completely fine with the Fun rating being low seeing as we really didn't design a specific mechanic, and that wasn't our goal in the first place. Most importantly, we also achieved the best ranking in any category so far (#101 with Mood), and Audio and Graphics were pretty high, which is what we were aiming for.
I'm glad that we've finally figured out how to test shaders for ATI/Intel which was always a big problem, and besides, what point is there making all these effects if they won't run on the player's computer. I think this will help us immensely in the future, and not just for LD games.

I'm curious how other participants think we can improve further.
1) I personally think we could get a lot more freedom if Spring's game<->map settings were a bit more flexible. I would like to have the ability to run games without a map, and not just for lobbies, but for real games (space-themed ones being the first thing that comes to mind), and I would also like to have multiple maps running for the same game simultaneously.
2) The next thing on my list (and much more difficult imo) is to have proper unit<->unit colvol collisions. This would not only give us better physics, proper walls/rooms and larger objects, but probably also things like bridges and ramps (interestingly, while pathfinding wouldn't work, I don't see what would stop us from making unit-bridges with working collisions).

[smoth]

I am a bit disapointed. I thought we created something pretty. Should I not even bother doing art next time?