Feedback Feedback Friday #149 - January 22-25, 2021

Hi all,

It's Feedback Friday time!

Proper playtesting and feedback early on in your game will save you tons of time - according to this postmortem, it might even save you a whole year!

If that sounds like something you could use, you've found the right thread! Feedback Friday runs from Friday to Monday every week. Share a build of your work in progress game to get playtesting and feedback, get new perspectives to help you overcome your biggest obstacles and take advantage of the Unity Community to boost your game development!

What To Show

• Minimum Viable Product (MVP) - Core game play > everything else
• How To Scope Small (Unity tutorial)
• Post a link to a playable game, preferably WebGL. If you don't have a playable game, post something substantial, not just text.

How To Ask For Feedback

• Be concise.
• Specify what you want feedback on and what you don't.
• Resist the urge to write an immediate defense. Take the time to understand their points. Remember that your friends here are taking time out of their busy schedules to help you for free.

How To Give Feedback

• Be positive. There's something of value in every game.
• Focus on the design, not the designer.

Feedback Friday #148 is here.

 

Okay, following the discussion last week I took another step back and built a very simple level to test out gameplay against individual enemies. It's up at my page - https://eternalambiguity.itch.io/ca-shooter. It looks like the following image:

The player starts in the lower-left room, and the enemy can start in the upper-right room or the corridor outside that room.

Interested in feedback as it relates to these specific enemies and the player's options in fighting them.

When you start up you're given the option to pick the enemy type and the starting location. When the level loads there are options allowing you to define how fast the simulation runs, how fast the melee enemy moves when they spot the player, how fast "shooter" enemies shoot bullets, and the growth rate of the "grower" enemy type.

Couple other changes: the doors are now automatic - if you get close enough they'll open automatically. They'll do this as well for "machine" faction enemies, so the robots. I also added a "trap" weapon, which shoots ahead of you and falls, sticking to whatever surface it hits. You can switch between secondary weapons by scrolling with a mouse wheel.

The robot enemy's patrol is not really correct, but the method I was using before had issues (massive memory usage) so for now I just went with this.

The blob shooter/spitter still bursts to produce the grower enemies.

Enemy speed is loosely coupled to the simulation speed, in that if the enemy seems to move quickly, stop, and wait a moment before moving, you'll need to increase the simulation speed to have them move faster.

As mentioned I'm interested in really nailing the gameplay for the individual enemies so I can take the next step and start combining them, or considering larger maps like I had last time.

 

You got memory leak, or something.
Game used all my memory in matter of seconds from starting play, when I walked to up room and approached the right door.
Had to shut it down from the task manager.

 

Was this with the first enemy, the grower? I just encountered that myself. I tested every other enemy but that one...ugh. Sorry about that. I just uploaded a new build without that enemy. All the others should work correctly.

 

Yep it was default settings. After that I gave up further testing. I may try again at some point later, or tomorrow.

 

Okay, sorry again. This was actually a blessing in disguise, because it led me to rework a couple things and resolve the memory issue (possibly for robot patrolling as well, but I'm leaving that as-is for the moment).

There's a new build up with the grower added back in. I've had it running for 5 minutes and the memory is hovering around 250 MB. Also, the shooter enemy no longer bursts into the grower enemy, just to keep them as separable as possible.

 

Well not to worry about it. You got feedback, what you asked for in the end
Then you have addressed the issue.
That what all is about. Feedback and iterate.

 

I chose Grower + Room. It ran fine with the default settings, but when I set the growth to 0.0125 it crashed. (Maybe coincidental?)

I may have misunderstood, but I thought the primary hook was the blob growth mechanic? If so, can you set default values (environment, growth variables, etc.) so the gameplay for that scenario is challenging, interesting, and fun? With the default values, I ran into the room in the upper right and shot the blob and two mobile units. It's functional, but I didn't come away from it feeling like "wow, that was an exciting encounter!" I also had no idea where to find the quartz thing.

Recall for example this prototype that I posted for feedback last year:



It's no masterpiece by any means, but it has a fairly clear primary mechanic: build towers to defend the blue crystal thingies until you've pulled all the levers in the scene. Once testers understood the controls, they generally had a clear idea of what to do, what opposed them and how, and how they could experiment with different strategies to accomplish the goal. So most testers thought it was fun to play, if a bit sloppy design-wise.

 

Okay, I just uploaded a new version that fixes the issue with adjusting the growth probabilities. It's set such that the maximum is 1/8 = 0.125, so it might be easier to select within the input field and delete a 0 or change a number.

As for the primary gameplay loop...I guess I'm still struggling to convince myself that my main focus needs to be just one enemy in one situation. I have all these enemies that act differently - I see them as able to work in concert with one another (for the blob at least).

 

I could be wrong, but maybe each enemy should be fun in its own right. When my tower defense prototype above only had one type of thing to build (arrow tower), it was still fun to build and maintain your arrow towers to defend against the enemy onslaught. Additional buildings just multiplied the potential (e.g., build walls to protect arrow towers, and slow traps beyond walls so enemies get hit with more arrows before closing in).

I feel like there's something really fun and unique just over the horizon with the blob. Maybe kind of like how the Zerg creep works in Starcraft.

 

Okay, maybe I misunderstood your original statement. I thought you were hinting at the blob/grower being the main focus with the others secondary to that. I definitely agree that each type should provide interesting gameplay on its own.

 

Both. The prototype should be fun to play with each enemy type. But, also, the blob is the enemy that's the most unique and interesting to me, so maybe that could form the base of the game.

 

Okay thanks. Just seeing them in action, though...I'm not sure how interesting I can really make them. In my "story" about them last week I hinted at them coming from a power node, and that the player would need to kill them at that source. Apart from that, though, they're mostly just an easily-dispatched obstacle, and any rapid growth basically fills the level and prevents other enemy types from acting appropriately.
Perhaps I could limit their growth in some way - make some maximum distance from the power node limit, or a limit on the total number of them clustered together.

 

To me, that would be a red flag, except for:

Playing around with this could be really interesting. For example, maybe they cluster around nodes that you need to access. So you can burn a path through the blob to get to the node, but the blob could slowly regrow behind you. It seems like there's a lot you could do with that.

 

okay, I'll try that next. Thanks for talking through this.

 

@EternalAmbiguity I had a play of the demo. A couple of suggestions for the demo presentation:
- Would be good to have a 'restart' button.
- Would be good to have the enemy spawn at a random location, giving more options for something to spontaneously produce an idea.
- Melee enemy disappeared every time it tried to go through the door at the bottom of the room it started in.

I agree with TonyLi that the blob enemy is where you should focus, and I also think it feels close to offering some possibilities. I also agree that every enemy should be fun in its own right, even if putting them together does compound the fun.

I was trying to think of a very minimalist game like yours and I came up with Thomas Was Alone so I watched a bit of gameplay, and these are the things I picked up on:

- The game starts off with only one thing to do (move) and this is already fun.
- As the game progresses, the creator clearly develops around this one mechanic, with the level modified to provide variety to this same mechanic.
- A bit later on, the single mechanic (movement) is further evolved into two characters with teamwork.

The main thing here is that the developer didn't think "I just have a character that can move, the game hasn't been created yet because there's nothing to do" but made that one thing, the thing that the player does and enjoys.

I think the blob is the mechanic you need to focus on, and rearrange the levels to influence and provide variety to the player's interaction with it. That means that it is significant:

- Where the blob is and what it is creating an obstacle to.
- How the blob reacts when the player shoots
- How the blob re-grows
- etc

To start with, I think you would already start to feel a sense of meaning by creating a level where a blob covered every door. Then the blob is an obstacle to exploration that the player feels a sense of satisfaction in removing, and also they cannot ignore or feel that it is irrelevant.

Then you can explore different kinds of blobs, maybe the red blob releases poison gas, while a black one has nodes that 'explode' and splash bits in all directions, and each splash after some time starts regenerating a new blob - so it cannot be fully destroyed until (for example) the air in the room is removed, which can only be done by getting past it and closing the room off. And there might also be a blob that grows a tentacle fast toward the player or something like that, or the blob moves toward the player by destroying its rear nodes and creating new ones in front.

I think at this point it would be best to put all other enemies on the backburner and focus on interactions between the player, the blob(s) and the environment.

 

This might be it. Uploaded a new version with the power node. https://eternalambiguity.itch.io/ca-shooter

Now if you select grower at the start it'll just turn on the power node, from which the grower enemy will emanate. Their growth rate is relative to their distance from the node, and you can set that distance. Additionally, I removed their ability to produce the melee and shooter enemies - there's commented-out code to have it start producing them when it reaches the edge of its range, but for now I kept the scenario specific to that one enemy type.

If you get close enough you can turn off the power node, which will stop the enemies from growing.

 

I think it's getting somewhere!

The green and white particle effects make it a bit hard to see what's going on.

Is the blob supposed to damage the player on contact? If not, what do you think about adding that?

I cleared a path to the power node but it didn't seem to do anything, either in proximity, or pressing E, or shooting it with either weapon.

It's satisfying to clear paths through the blob. I think it's just a matter now of finding the fun in that activity beyond just Marie Kondo-ing the room. What kind of push and pull can each action have?

For example, when you shoot the blob, the push is that it clears a path. The current pull is that it uses ammo, which might be enough. If not, what if shooting it causes bits to splash outward, enabling it to grow faster elsewhere?

When you turn the power node off, the blob stops drawing power from it to grow. But what could the pull be? The blob gets attracted to an active power node elsewhere and starts to migrate? That could make some interesting emergent gameplay where you're shepherding the blob around by turning different power nodes on and off.

Or maybe it's like Aliens and your goal is to free captured scientists from cocoons that the blob has put them in. There might be more push and pull there, too. You can choose to free scientists in one area before the blob dissolves them, but at the cost of leaving a power node active for now in another area, which allows the blob to grow there. I just think there's a lot of potential to be tapped in what you've come up with.

 

Agreed about the particle effects, so I just uploaded a build with them removed entirely.

There should be a "Press E to interact" thing that pops up on the left side of the GUI when you get right next to the power node. When you press E, it should stop spinning and the noise it makes should stop. Just tested those myself, so please let me know if that's not working for you.

I agree there needs to be more push, maybe on the side of the blob itself responding and not just player resources. I'll think about how to do that.

I like the idea that it's trapped scientists - that's more immediately understandable than simply clearing them for the sake of clearing them.

 

Would the production of other enemy types at the attack of the blob (who then attack the player) be within the spirit of giving the blob enemy a meaningful defense (or a push for the player's pull)? Reading up a bit on eusocial insects and a response to attack seems typically centered around a "defense" or "guardian" variant of the creature.

 

That would be interesting! I'm envisioning when you trim away part of the blob, deeper in the blob forms a chrysalis that eventually spawns an attack unit. So there's a very apparent push and pull. You can trim away the blob to get at things, but doing so causes it to spawn attack units. So you have to be judicious with your actions. Maybe you'll leave a power node active for a while because you're not ready to fight, but at the cost of allowing the blob to absorb power and grow faster. Or maybe you'll choose to risk your safety to cut your way to a weapon upgrade, in the hope that you'll get to the upgrade before the attack units reach you.

 

Awesome. I've got a primitive version working, but I'll continue to play with it over the next few days.

 

Well you start getting something there

 

It's an interesting idea, but in my opinion the blob mechanics (growing, moving, reshaping etc) are worth focusing on first.

 

Thinking more about trapped scientists, the blob concept and related story/movies/etc.. a common theme is that "the blob" grows not only in a physical sense, but characters become appendages of it mentally before it "bursts forth" - whether being controlled telepathically or a chemically-induced empathy or even just doing things to avoid quarantine or worse once they know, infecting more people. So a scientist in a lab is a bit too close for a bit too long, next thing he's unlocking stuff and a blob is escaping. Or another adjusts environmental controls to cause faster growth.

In that tradition, the longer it takes you to rescue them, the more likely they've been assimilated. Rather than random blobs spontaneously appearing (especially since you've already coded morphing from one type to another), a scientist or visitor or guard morphs into something once the process of infection reaches a certain threshold.

Another idea, maybe there's a radius of mental influence from a "brain blob" - there it is all safe behind the glass, but it's got just enough psionic ability to infect a scientist at the controls or a guard by the door, even if that's just to let it out. Expanding on that, maybe if the player gets too close to that kind, there's a weight-based system on your movement controls, so the closer you are, the more movement is controlled by the blob (pushing you towards hazards, whatever) and you can't do what you wanted (and maybe even ends up in a game over given your inability to defend yourself).

Maybe early in the game/temporarily, from a story perspective, you're a member of a team, you get messages from them (tutorial text). Later if you're doing tutorials via dialog or cutscene.. something like a scientist saying "today we found out the [red kind] is susceptible to cold.. unfortunately, Red didn't make it, but if he hadn't fumbled that nitrogen tank..!" ..now rather than needing to remember just "red = use cold", the memory is stronger because of association and story - about what happened to Red (the team member), that likely won't be forgotten easily. If you use character portraits, he/she could have red hair and/or a red beard or something, a red backdrop, whatever. The more connections between red and cold you could pack into a sentence or two and a thumbnail the better for retention ..and this could be aesthetically pleasing as well, with each color of blob's tutorial presentation themed to the given type's color.

 

Appreciate the suggestions.

Reshaping and moving towards what? Other power nodes, or something else? If you're thinking power nodes, that seems predicated on building out the level a bit more, yes? Or just putting another somewhere in the same level?

Related to the "eusocial" idea I was thinking about searchers, kind of like ants searching for food, who upon finding another power node would form a path between the two and thus allow the blob to grow between them.

 

Yes, I think it's best for the blob and the level to be worked on simultaneously. I just think that creating more enemy types right now from the blob, before making the blob itself a fun and functioning mechanic within the level, is skipping ahead.

 

This needs experimentation. I would start off with the blobs covering doors. Then have them covering controls that the player needs to use. Try making them spread out to each side and try to encircle the player. Or move toward the player by regenerating in front of itself. Maybe it degenerates/regenerates in a direction perpendicular to where the player is firing from. Maybe the blob scatters when the player shoots it, and reforms when it is taking less damage, or separates into three or four blobs surround the player and start working together, like some kind of Michael Crichton story.

The blob is a feedback mechanism, and until it reacts to the player, and strategically places itself in front of things that are meaningful to the player, and operates with the player as a focal point, the player won't find meaning in it.

 

All good points, thanks. I'll try to get that worked out over these next few days.

 

Retain the idea that blobs react (e.g., by spawning moving enemies) when attacked. Your latest gif shows a really good push and pull in that regard. It's the first gif that looks like there's actual strategy and challenge involved. I found myself rooting for the player in that gif -- could he make it to the scientist before the blob got either of them? To incorporate Billy's advice, perhaps when you shoot a blob it could spawn fewer enemies, but also play harder into the blobbiness of the blob (growing, covering important things, etc.). I think some of that is a matter of tuning, but you'll want to know that it's possible to tune this gameplay into something that's genuinely fun. I think it's really getting there.

 

Welp. That was the exact kick in the pants I needed.

More in 4/5 days.

 

It looks like we had great feedback this weekend. We'll done all.
It is time wrap it up and invite to next FF coming soon.