Feedback Friday #154 - February 26 - 29 - 2021

[Billy4184]

G’day folks, it’s Feedback Friday time!

Want free design feedback for your work in progress project?

Then you’ve found the right thread! Feedback Friday runs from Friday to Monday every week.

What To Show

• Minimally 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 #153 is here.

[EternalAmbiguity]

Well, I’m late, but I’m here. Latest version: CA Shooter by EternalAmbiguity

Let me know if there are performance issues–I recorded the GIF below using the version I uploaded and didn’t have any issues (despite the framerate of the GIF).

prestigiousdisfiguredaxolotl
enchantingimperfectamericanshorthair

The big things I spent time on were the structures seen in the GIF and the NPCs. The structures trap the NPCs. The player can shoot them to destroy them, and then once destroyed the NPC will follow a simple FSM/behavior tree (I’m not sure of the difference) - idle around until there’s an enemy within a range, and at that point flee to a location and disappear from the map (since this map is so small they hit the “flee” state immediately).

While the NPCs are trapped their health decreases as seen in the GUI (nothing happens when it hits 0 presently). Also you don’t see it here, but as shown in my GIF last week the NPCs can be trapped again if they’re surrounded by the blob - the blob will create the cage structure around them.

Within the framework of this little demo the goal is still to grab the McGuffin from one room, as indicated by the “quest text” at the bottom (this and dying are the only two things that trigger ending the map), but you also have the GUI elements to the right related to saving the “workers.”

I’m interested in feedback on this gameplay - on saving and escorting the NPCs to safety, and the enemy building these structures. Escort missions are infamous for being terrible, is that the case here? Should the NPCs be smarter in any ways? Overall does this feel like it complements the previously existing gameplay?

There’s something related to all this I’m worried about: my idea has been for a single persistent map where the blob grows continually regardless of where the player is. In this demo a big part of the gameplay is getting to the NPCs before the blob can, and it’s kind of fun, but in the real game I imagine any trapped NPCs to be surrounded by the blob (and be much further from the player in some cases), and furthermore for the blob to be established as the player carves out a path.

That’s not well represented here, but I’m curious about the changes I ought to make to support that kind of gameplay (giving the blob “thinner paths” to travel upon (which would in turn allow the player to better pause their advances), reducing their growth rate, increasing the delay after they’re shot by the player, slowing the NPC health decrease, etc.).

Extra discussion points:

The structures are meant to trap the NPCs and extract “biomass” from them, though I’m not sure at present how to use that. Related to the whole blob-as-eusocial-organism thing I’ve imagined I can see them using both the biomass and electricity (from the power nodes) to build things, though I’m not sure what. At the very least I imagine little organic “pipes” running between structures.

^^^ I like that idea more each time I think about it - almost like the blob is “playing” a citybuilder/rts, and the player is going against that - but I’m curious if others think it’s interesting.

NPC activity. Right now it’s just entities fleeing, but I can imagine some of them, “security officers” or something, fighting back. On the other hand there’s a different vibe if the player is the only defensive/offensive force in the game. Thoughts?

[Billy4184]

@EternalAmbiguity

Well, I’m late, but I’m here. Latest version: https://eternalambiguity.itch.io/ca-shooter

Let me know if there are performance issues–I recorded the GIF below using the version I uploaded and didn’t have any issues (despite the framerate of the GIF).

prestigiousdisfiguredaxolotl
enchantingimperfectamericanshorthair

The big things I spent time on were the structures seen in the GIF and the NPCs. The structures trap the NPCs. The player can shoot them to destroy them, and then once destroyed the NPC will follow a simple FSM/behavior tree (I’m not sure of the difference) - idle around until there’s an enemy within a range, and at that point flee to a location and disappear from the map (since this map is so small they hit the “flee” state immediately).

While the NPCs are trapped their health decreases as seen in the GUI (nothing happens when it hits 0 presently). Also you don’t see it here, but as shown in my GIF last week the NPCs can be trapped again if they’re surrounded by the blob - the blob will create the cage structure around them.

Within the framework of this little demo the goal is still to grab the McGuffin from one room, as indicated by the “quest text” at the bottom (this and dying are the only two things that trigger ending the map), but you also have the GUI elements to the right related to saving the “workers.”

I’m interested in feedback on this gameplay - on saving and escorting the NPCs to safety, and the enemy building these structures. Escort missions are infamous for being terrible, is that the case here? Should the NPCs be smarter in any ways? Overall does this feel like it complements the previously existing gameplay?

There’s something related to all this I’m worried about: my idea has been for a single persistent map where the blob grows continually regardless of where the player is. In this demo a big part of the gameplay is getting to the NPCs before the blob can, and it’s kind of fun, but in the real game I imagine any trapped NPCs to be surrounded by the blob (and be much further from the player in some cases), and furthermore for the blob to be established as the player carves out a path.

That’s not well represented here, but I’m curious about the changes I ought to make to support that kind of gameplay (giving the blob “thinner paths” to travel upon (which would in turn allow the player to better pause their advances), reducing their growth rate, increasing the delay after they’re shot by the player, slowing the NPC health decrease, etc.).

Extra discussion points:

The structures are meant to trap the NPCs and extract “biomass” from them, though I’m not sure at present how to use that. Related to the whole blob-as-eusocial-organism thing I’ve imagined I can see them using both the biomass and electricity (from the power nodes) to build things, though I’m not sure what. At the very least I imagine little organic “pipes” running between structures.

^^^ I like that idea more each time I think about it - almost like the blob is “playing” a citybuilder/rts, and the player is going against that - but I’m curious if others think it’s interesting.

NPC activity. Right now it’s just entities fleeing, but I can imagine some of them, “security officers” or something, fighting back. On the other hand there’s a different vibe if the player is the only defensive/offensive force in the game. Thoughts?

Here’s an idea I got looking at the video:

How about you have a ventilation network running alongside walls and corridors etc, with ventilation ports going into each room. Imagine Alien Isolation type of thing. And the blob can spill out of a ventilation port when the player is around or if there is an objective to trap there.

One advantage to this is that the player would be able to see the blob all the time but not always interacting with it, creating a more suspenseful atmosphere. Right now, the runaway growth of the blob all over the place just seems like a tiring thing to combat and reduces any sense of anticipation or strategy.

So then, each time the blob spills out of a ventilation port, in a sense it is a new enemy and a new situation. And I think it might also be beneficial for the blob not to grow continually (or to grow very slowly) but to be able to retract units of itself back into the ventilation port where the player is not present, and regenerate itself forward to wherever it wants to go.

Thoughts?

[EternalAmbiguity]

@Billy4184

Here’s an idea I got looking at the video:

How about you have a ventilation network running alongside walls and corridors etc, with ventilation ports going into each room. Imagine Alien Isolation type of thing. And the blob can spill out of a ventilation port when the player is around or if there is an objective to trap there.

One advantage to this is that the player would be able to see the blob all the time but not always interacting with it, creating a more suspenseful atmosphere. Right now, the runaway growth of the blob all over the place just seems like a tiring thing to combat and reduces any sense of anticipation or strategy.

So then, each time the blob spills out of a ventilation port, in a sense it is a new enemy and a new situation. And I think it might also be beneficial for the blob not to grow continually (or to grow very slowly) but to be able to retract units of itself back into the ventilation port where the player is not present, and regenerate itself forward to wherever it wants to go.

Thoughts?

Some of this is related to what I was saying about my intentions for the player to arrive “late” to the party - in the real game I envision the blob already established, so it’s not the player racing it for growth (see the picture below). And I agree, the speed of the growth is pretty high and not easily combated. I can handle that a couple of ways already - by making their paths thinner (so when the player shoots there’s less space for them to go around the spot where the player shot), and by lowering the growth rate itself.

Initially the blob did not go after the player but as was suggested (by certain individuals…:P) I added that. I wonder if it could be more granular - having it only respond when the player makes an attack? Or is it fine as-is, and needing this other system?

I do like the ventilation idea for a couple reasons. One is it makes me think of stealth, as you imply with A:I. Shielding oneself from view somehow. I also think it would work as an interesting indicator of the blob’s presence - if the ventilation shafts are clear, the blob isn’t in the present area, and visa versa.

[Antypodish]

@EternalAmbiguity

Some of this is related to what I was saying about my intentions for the player to arrive “late” to the party - in the real game I envision the blob already established, so it’s not the player racing it for growth (see the picture below). And I agree, the speed of the growth is pretty high and not easily combated. I can handle that a couple of ways already - by making their paths thinner (so when the player shoots there’s less space for them to go around the spot where the player shot), and by lowering the growth rate itself.

I suggest put that settings into game difficulty.

[Billy4184]

@EternalAmbiguity

Some of this is related to what I was saying about my intentions for the player to arrive “late” to the party - in the real game I envision the blob already established, so it’s not the player racing it for growth (see the picture below). And I agree, the speed of the growth is pretty high and not easily combated. I can handle that a couple of ways already - by making their paths thinner (so when the player shoots there’s less space for them to go around the spot where the player shot), and by lowering the growth rate itself.

Initially the blob did not go after the player but as was suggested (by certain individuals…:p) I added that. I wonder if it could be more granular - having it only respond when the player makes an attack? Or is it fine as-is, and needing this other system?

I do like the ventilation idea for a couple reasons. One is it makes me think of stealth, as you imply with A:I. Shielding oneself from view somehow. I also think it would work as an interesting indicator of the blob’s presence - if the ventilation shafts are clear, the blob isn’t in the present area, and visa versa.

I think it’s good for the blob to operate with intentions, responding when the player is near, makes an attack or to surround a player objective.

The way I imagine the ventilation is that the player can see what is in the ventilation duct (it has no top, and runs parallel to room walls and corridors) but cannot break into it or enter it. That way the blob is always visible, filling the ducts, but the player does not know which vent it might decide to come out of. And it can potentially retreat its growth back into the duct as a defensive strategy, and simultaneously reemerge from another vent.

In this way the blob is ‘omnipresent’ but cannot always be interacted with, meaning that the player won’t get firing fatigue from just mowing it down all the time.

It’s a significant diversion in the game design, but personally I think it would be worth exploring.

[EternalAmbiguity]

@Billy4184

I think it’s good for the blob to operate with intentions, responding when the player is near, makes an attack or to surround a player objective.

The way I imagine the ventilation is that the player can see what is in the ventilation duct (it has no top, and runs parallel to room walls and corridors) but cannot break into it or enter it. That way the blob is always visible, filling the ducts, but the player does not know which vent it might decide to come out of. And it can potentially retreat its growth back into the duct as a defensive strategy, and simultaneously reemerge from another vent.

In this way the blob is ‘omnipresent’ but cannot always be interacted with, meaning that the player won’t get firing fatigue from just mowing it down all the time.

It’s a significant diversion in the game design, but personally I think it would be worth exploring.

For the blob’s bursting from a vent - are you thinking this would be something random, or would the player be able to influence it in any way (like by being stealthy)?

[DanielDemidov]

Hi all!
Continued working on my game. Added a cooldown so that the player couldn´t just spam satellites and a launch success chance, which is just a random % for now. Each successfull launch gives you (apart from the net coverage) reputation, while each failed launch decreases reputation. If it is <= 0, the player loses

Would you please share your thoughts on the chance system? Is it wise enough to use it like that? Or should some more subtle methods be implemented instead?

By the way, do you think such a game could be interesting to play on PC?

Thanks in advance!

[Antypodish]

@DanielDemidov

Would you please share your thoughts on the chance system? Is it wise enough to use it like that? Or should some more subtle methods be implemented instead?

Regarding chances, I would suggest add some simple research feature. Nothing like research tree. But very simplistic. Maybe cost of research increases per number of researches. You could gain research per complete missions. Then based on research points, your launch success rate per distance will increase. Something like that. Keep it simple but engaging.

[DanielDemidov]

@EternalAmbiguity

Well, I’m late, but I’m here. Latest version: https://eternalambiguity.itch.io/ca-shooter

Let me know if there are performance issues–I recorded the GIF below using the version I uploaded and didn’t have any issues (despite the framerate of the GIF).

prestigiousdisfiguredaxolotl
enchantingimperfectamericanshorthair

The big things I spent time on were the structures seen in the GIF and the NPCs. The structures trap the NPCs. The player can shoot them to destroy them, and then once destroyed the NPC will follow a simple FSM/behavior tree (I’m not sure of the difference) - idle around until there’s an enemy within a range, and at that point flee to a location and disappear from the map (since this map is so small they hit the “flee” state immediately).

While the NPCs are trapped their health decreases as seen in the GUI (nothing happens when it hits 0 presently). Also you don’t see it here, but as shown in my GIF last week the NPCs can be trapped again if they’re surrounded by the blob - the blob will create the cage structure around them.

Within the framework of this little demo the goal is still to grab the McGuffin from one room, as indicated by the “quest text” at the bottom (this and dying are the only two things that trigger ending the map), but you also have the GUI elements to the right related to saving the “workers.”

I’m interested in feedback on this gameplay - on saving and escorting the NPCs to safety, and the enemy building these structures. Escort missions are infamous for being terrible, is that the case here? Should the NPCs be smarter in any ways? Overall does this feel like it complements the previously existing gameplay?

There’s something related to all this I’m worried about: my idea has been for a single persistent map where the blob grows continually regardless of where the player is. In this demo a big part of the gameplay is getting to the NPCs before the blob can, and it’s kind of fun, but in the real game I imagine any trapped NPCs to be surrounded by the blob (and be much further from the player in some cases), and furthermore for the blob to be established as the player carves out a path.

That’s not well represented here, but I’m curious about the changes I ought to make to support that kind of gameplay (giving the blob “thinner paths” to travel upon (which would in turn allow the player to better pause their advances), reducing their growth rate, increasing the delay after they’re shot by the player, slowing the NPC health decrease, etc.).

Extra discussion points:

The structures are meant to trap the NPCs and extract “biomass” from them, though I’m not sure at present how to use that. Related to the whole blob-as-eusocial-organism thing I’ve imagined I can see them using both the biomass and electricity (from the power nodes) to build things, though I’m not sure what. At the very least I imagine little organic “pipes” running between structures.

^^^ I like that idea more each time I think about it - almost like the blob is “playing” a citybuilder/rts, and the player is going against that - but I’m curious if others think it’s interesting.

NPC activity. Right now it’s just entities fleeing, but I can imagine some of them, “security officers” or something, fighting back. On the other hand there’s a different vibe if the player is the only defensive/offensive force in the game. Thoughts?

Played for a few minutes. The idea is rather interesting, though navigating is a bit too hard without any signs or clues…
Maybe you could add some? Or I failed to notice…

[DanielDemidov]

@Antypodish

Regarding chances, I would suggest add some simple research feature. Nothing like research tree. But very simplistic. Maybe cost of research increases per number of researches. You could gain research per complete missions. Then based on research points, your launch success rate per distance will increase. Something like that. Keep it simple but engaging.

Thanks! Thought about the research mechanic, but decided to leave it for further stages of development…
Maybe will add sooner, after your message

[TonyLi]

@DanielDemidov

Would you please share your thoughts on the chance system?

If you can provide a playable build, we can give you feedback on it.

[Antypodish]

@EternalAmbiguity

Let me know if there are performance issues

Yeah, hitting pretty large lags and frame drops. Is not always, but in certain occasions. But to be honest, I was running intensive application at the same time, using 35-50% of my 8 cores CPU power. So maybe after that, I will test again.
Check your GC, memory GPU and CPU use.

[DanielDemidov]

So, first playable build!
The goal is to make “Net coverage” = 100. If your reputation < 0, you lose.

Would you please share your thoughts on the idea in general, the mechanics and on what could be improved/added?

Utopia.rar

Thanks in advance!

[TonyLi]

@EternalAmbiguity - I tried to play, but it was very stuttery, and the player even seemed to pop back a few times.

Also, the blob didn’t react to bullets. They just passed straight through the blob and walls.

What if the workers have rudimentary AI to take what looks like a smart route away from the blob? Then you could free them and leave them on their own to escape, or to get caught again in which case you’d have to free them again.

What about flipping the purpose of ventilation shafts? They could be blob-free tunnels that provide a way to move around some limited areas. The player could choose to try to blast their way through the blob to rescue an NPC or make their way through a ventilation shaft to get closer to the NPC before having to cut a path through the blob.

Freeing the workers seems a lot more interesting than retrieving the keycard.

I also like the idea of the blob “playing” a city builder – kind of like how the Zerg expand their creep in Starcraft. Maybe the goal of each level could be to free as many workers as you can and then destroy the blob’s “brain”. (Maybe I’m thinking too much of Ripley in Aliens extracting colonists from the aliens’ gooey walls and then taking out the queen at the end.)

[Antypodish]

@TonyLi

and the player even seemed to pop back a few times.

Yeah I experienced tha too few times. Even on earlier releases.
Now, I suggest to stop on implementing features. Start investigating profiler and llresolve source sof these weird lags. Game a bit behaves as if it was multiplier. But is obviously single player. So there is fundamental performance issue.

I was able to simulate 10s of thousends entities in my prototypes. Never had such weird performance issues. Some lower FPS yes, but no such lagging and jumping.

[DanielDemidov]

In addition, the first version has more actions (raising money and boosting popularity). Wondering whether they break the gameplay or not in terms of balance

[TonyLi]

@DanielDemidov

In addition, the first version has more actions (raising money and boosting popularity). Wondering whether they break the gameplay or not in terms of balance

Do you feel like they support and enhance the core idea? Is the game more about the on-the-ground activity of planning and getting support for your satellite launch program, or more about the technical aspects of launching a satellite such as timing?

It would be helpful if there were some feedback when a launch fails.

I like how the mechanics and visuals are simple and straightforward. It’s a good way to go. It’s less intimidating for a player to experiment with, and it’s easier for you to iterate on different variations.

[DanielDemidov]

@TonyLi

Do you feel like they support and enhance the core idea? Is the game more about the on-the-ground activity of planning and getting support for your satellite launch program, or more about the technical aspects of launching a satellite such as timing?

It would be helpful if there were some feedback when a launch fails.

I like how the mechanics and visuals are simple and straightforward. It’s a good way to go. It’s less intimidating for a player to experiment with, and it’s easier for you to iterate on different variations.

Thanks for the feedback!
I added them to give the player kind of a reserve tool to keep going if the situation is on the brink of a defeat. As for the focus, I think it would be better to keep it on managing resources as it works now.
Yeah, will certainly add events with descriptions to make it more comfortable

[Billy4184]

@EternalAmbiguity

For the blob’s bursting from a vent - are you thinking this would be something random, or would the player be able to influence it in any way (like by being stealthy)?

Always better, in my opinion, to have things be based on what the player is doing.