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.

4 Likes

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 - CA Shooter by EternalAmbiguity. 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 :slight_smile:
Then you have addressed the issue.
That what all is about. Feedback and iterate.

1 Like

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:

6756790--779767--upload_2021-1-23_10-5-15.png

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.

1 Like

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.

2 Likes

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. :slight_smile: 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.

1 Like

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.

3 Likes

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.

1 Like

This might be it. Uploaded a new version with the power node. CA Shooter by EternalAmbiguity

arctictangibleharborporpoise

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.

2 Likes

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.

2 Likes

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.

1 Like