Feedback Friday #146 - January 1-4, 2021 - New Year's Edition!

Happy New Year!

Let's ring in 2021 with a great Feedback Friday thread!

If you're looking for free design feedback for your work in progress project, then you've found the right place! 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 #145 is here.

 

Linkie linkie: https://eternalambiguity.itch.io/ca-shooter

And a couple GIFs:

Okay, so here're the changes I've made (the asterisks relate to overlong questions/areas of subjectivity at the end):

Added a new enemy faction - robots. Currently a turret and a roaming robot. Like the blob is/are susceptible to atmospheric antiseptic, the robots are susceptible to poison. This should be almost all but one of the enemies in the game.

The turret obviously sits in one place and fires at the player when in view and close enough.

The roaming robot will patrol all accessible areas. If it sees the player it will stop patrolling and attack while approaching. If it loses sight of the player it will go to their last known location, and following that return to its patrol path*.

And of course these are "factions," so the blob and the robots will fight if they encounter each other. Right now they target each other first*.

I also added a couple rooms to this map to feature these enemies. It's set up so the last room with the McGuffin is the roaming robot one.

I also added a "weapon type" system, where the player can shoot a "bio" bullet or "energy" bullet. The blob enemy shoots bio bullets and has stronger defense against them, and visa versa for the robots.

Related to the above, I also added player "hazard protection," where their damage from a given type of damage can be reduced or mitigated completely. Right now it's randomly chosen when a level starts.

I also made a modification which allows players to fire over cells that are blocked for movement (on this map that means the diagonal objects, which block enemy/player movement for any square they occupy)*.

I also tweaked things to provide more enemies for the player to fight in the room adjoining the starting one, hopefully with the effect that the second, following room will be too full for the player to charge into, thus forcing them to use the "room modification" system.


I'd love any and all feedback - mainly on the combat, the room modification system, the player "upgrade" system, and the room/map setup (in the end I imagine something much more complex, but this simple design should inform that).


To address those asterisks:

The way I create the patrol routes is actually kind of cool, and I feel like it would get a little bit of buzz on "development showcasing" platforms. That along with an article featured on Gamasutra I read recently has me thinking about marketing: should I be starting it? Should I have some type of devlog going? Should I be starting up social media accounts to talk about this game? I would like to have it on Steam by the end of 2021. That's probably unrealistic, but in any case it's a goal that suggests I need to start considering everything involved in development and release, and furthermore start these different measures early enough for them to be effective.

The justification for each faction targeting each other before the player is that they see the player as more similar to themselves - the player is an organic meatbag sitting in high-tech armor. I could always have them target the player first (would be faster in code actually) or the closest or something, but this way provides for more non-player interactivity so seemed more interesting.

Related to this ability to shoot "around" occupied cells is the potential for something like "cover" shooting: having objects you can shoot over but can't cross, and possibly also allowing the player to crouch behind such objects. It seems like a natural progression, but it also seems like scope creep, so I'm not sure if it's a good idea.


Something else I've been thinking about is having the view of the map be limited to what the player can see, Among Us style. The benefit is a more isolating and "scary" experience, but it would obviously prevent the player from seeing into other rooms, which might be a negative - the room modification system in particular would probably suffer with this change. There are things that could be done to work around it, such as allowing a limited view through closed doors or something, but I'm curious if anyone else thinks the "atmospheric" benefit would outweigh the cost.


This time next week I intend to be living in a new place I don't yet have keys to, so I'll be pretty busy the next 7 days (or days 3-7) and may have to skip the following FF.

 

@EternalAmbiguity - I like how mobile blob entities (blob mobs?) are immune to bio weapons and explode into blob particles when killed with an energy weapon.

It's really satisfying to destroy blobs, or at least pare them down. Can you lean into that more? The robot faction doesn't add much right now, and at the moment muddies the primary gameplay goal. You might consider putting robots on the back burner while you refine the hook.

Something unique and satisfying to play is on the horizon. I'd like stronger guidance on the primary "win condition" goal, and the gameplay hook that the player uses to achieve that goal. Right now, there's just a bit too much going on. Is the goal to get from point A to point B? If the gameplay were just fighting blobs to get to point B, without additional factions and environmental controls, I think I might enjoy it even more. Then you could add environmental controls back in, but solely as a way to enhance the primary hook. Maybe changing the environment presents tradeoffs -- one room gets colder and the blob grows more slowly, but the heat is shunted to another room that makes the blob there grow faster. Or maybe activating a powerup (e.g., for an ammo recharge) also wakes up additional blobs.

Once you have a very refined, single-sentence hook, it wouldn't be a bad idea at all to start a devlog.

 

For the destroying blobs part, which are the most fun to engage with (and how - avoiding the melee trackers, the "gunplay," or just stopping the growth of the immobile blob)? If it's one of the mobile types, do you think the growth of the immobile ones should be tweaked somehow? There's something appealing about them growing indefinitely like a bacteria, but as I've said before they're kind of boring. Right now they go down in one shot but if they manage to fill a room it's still the player sitting there shooting at them and waiting for them to die out.

I like the instantaneous "equal and opposite" environment reaction idea, that's clever. Currently I've just been trying to integrate a benefit or drawback for the two sides, with the two factions being affected opposite-ly (such as machines moving more quickly in the cold while the blob is slower, and visa versa for heat).

I want to lean in to the Metroid influence for the overall narrative goal and player gameplay progression. As I mentioned before, I see the premise as this blob being pulled in from another dimension and escaping confinement, causing the station to start a self-destruct countdown. The player would arrive fully upgraded, but in the first level encounter the one enemy I haven't added yet (a corrupted robot with bio and mechanical components, with resistance to both weapon types (and who shoots both types), who is completely ignored by other enemies - a boss type basically) who damages them and causes them to lose their upgrades. Following this the player would be found by allied but passive NPCs, and then they would begin exploring the station to figure out how the blob was released, how to stop it, and then stop the self-destruct sequence (finding upgrades along the way to return to full power).

I see the goal being point A to point B, with multiple routes from here to there, with the various routes having different environmental effects (requiring a non-fully-upgraded player to choose based on their resistances/protections). It might be best to completely remove player environmental control for that, I dunno.

Edit: when you say "too much going on" do you mean in the moment-to-moment gameplay or just the design--the different enemy types and environmental control aren't integrated well?

 

I would really suggest to create WIP thread.
Then you can write about your project, as much, as you like.
Is really easy to loose important feedbacks and hard to track, or remember, if you post in thread, which is weekly closed.

 

That's actually part of what I was trying to ask when I mentioned a "devlog," 'cause there's a lot I'm not talking about here because it's not directly relevant.

How does that work in conjunction with each iteration of this thread? Do I just post a link, a couple GIFs, and then reference my WIP thread? Or should I still mention what's changed, things I'm interested in feedback on, and specific questions/uncertainties? Or do I skip this thread entirely?

 

We don't have strict rules on that matter.
You can stil link, or post media directly as normal. Or quote from from your WIP. Is up to you.
But that allows you to focus on specific aspect of the game, rather than whole game at once every time.
And keeping detailed devlog in your WIP thread.
As well you can grab link to Feedback Friday threads, or quote its part in your WIP.

WIP will allow you and reader see the progress of your project. Which can be motivating.

 

By "too much going on," I mean the design, at least right now. I feel like there's a great core mechanic that's getting somewhat obscured by the addition of other mechanics.

For me, at least, it's very gratifying to shoot at the immobile blob to reduce its size. But that by itself isn't a game. If I look at the mobile blobs as minions that the immobile blob is sending out to defend itself, then it feels like it fits with the idea that the blob wants to grow, and your goal is to... what? prune it enough to get by to point B? save the station by completely eliminating it? Maybe when you get to point B, you can hit a button that immediately kills any remaining blob so you don't have to go around mopping up.

Every action should have a push and pull. If you stop to shoot at the blob, you reduce its size locally but at the expense of ammo and giving it time to grow elsewhere. If you run past, you avoid the blob but maybe it grows to envelop and destroy a critical station system. And, as mentioned before, if you freeze one room to slow the blob, the heat goes to another room which speeds the blob there.

In any case, the robots feel a bit extraneous to that core idea, although they'll be a good additional impediment in the future.

 

Alright, thanks (to both of you!). Reading that makes me think I need to work on the level more. This was just "bigger rooms with obstacles," but it's missing the full scale that would allow for more widespread blob growth (along with uses for the environmental manipulations).

I'll take a look at doing something better on that front.

 

Well it's New Years Edition, so why not



I recently added weapon selection and the Rocket Launcher. To quickly summarize.. blasts from airstrikes and rockets affect terrain surface, replacing a radius with dirt/rock texturing and throwing particles into the air which then land and transition out - each of which is textured based on the surface point it's originating from. Blasts also remove dotted lines from the road, destroy guardrails, trees and other groundcover, and explosive force is applied to the vehicle and/or whatever if close enough.

Right now there is no cooldown period or ammo limit whatsoever, so you can just fire off rockets as fast as you can click. On modern systems this should have little impact on framerate.. I can fill the screen with impact debris and it still runs smoothly for me in a web browser - but do note I capture my videos from the Windows build, which can be downloaded from the in-game menu and is an automated inclusion with every build. Actually, earlier in development I also included Mac and Linux downloads but since I don't have either OS to test with (and no testers) it was just making the build process take longer every time for nothing. If anyone does want to try a Mac or Linux build just let me know.

Feedback I'm looking for:

1. If you could change one thing about the blasts themselves (re impact with terrain), what would it be? Smaller particles? More space between them / less of them so they obstruct the view less? A brief fiery core at blast point? Whatever comes to mind. Note you switch to Rocket Launcher with the mouse wheel, by pressing 2, or by clicking the rocket icon in the weapons list. Weapons are not enabled in the "just drive around" mode.

2. Does the game stutter at any time during gameplay? If so, when? And if you've tried an earlier build, does it run noticeably better or at least just as well since last time? Since the previous post about my game in this thread I've reduced draw calls significantly (there are hundreds less now, even in the city test - which isn't included in the current build but will return), but there's also a lot more stuff going on. There are a few minor bugs but nothing related to performance or stability that I'm aware of. It doesn't have any stutter for me while playing unless other programs are really busy, for example if I'm building a project while playing.

If anyone does get a chance to check it out, it's worth noting here that you can press R at any time while you're playing to abort the current scenario and pick another one/restart, press F to switch between first person and third person cameras, press SPACEBAR any time your wheels are pointing up to flip over. To reset all destroyed content you can pause the game and click "again" or select the world from system menu. Please see the in-game help for a full list of controls

 

Playing the online build...

Feels extremely, extremely jerky. Like sub-20 FPS jerky, regardless of what the counter says. I'm using Firefox.

Just starting up, I'm on a road but I'm not given any instructions. There are a few explosions on the road in front of me, but I have no idea why they're happening. I don't know the context. I don't know what I'm expected to do. I sat there for a moment and failed.

Started driving and realized I was supposed to go through the gates and hit the stars, but the explosions do make it confusing. I also lost control of the vehicle very quickly--started going too fast and swerving all over the place. It may be over-sensitive, it might be the low framerate I'm experiencing, and it might just be I'm bad at the game. I failed again, and I'm not sure why - presumably because I didn't make it through one of the green hoops.

Played again and I got pretty far. I like the on rails/booster things. I don't find myself really using the weapon much at all. Finally noticed the timer. Might be nice to have a timer sound for like 3, 2, 1.

 

At default graphics options and size I get the following - by starting up and clicking the first route and watching fps until running out of time. Note my monitor is 144hz adaptive sync and won't go higher in browsers:

Chrome: 138-144, Edge: same as Chrome,
Firefox: 89-95 (I can only get ~100 even with all options turned down to absolute minimum).

In full screen I get:
Chrome: 109-114, Edge: 136-144,
Firefox: 56-65, VERY jerky/irregular and effectively unplayable.

Note the above won't be typical - framerates will be lower by the time the game's done, and with "sub-20 FPS jerky" it's clear you're in the desktop builds demographic, at least where this is concerned

You just throw rockets at the terrain and guardrails (for first feedback question), but you do need to drive and make it through checkpoints in order to get more time - that's an oversight on my part, if I'd considered posting here before I did Friday's build I would have made a key to disable the timer or enabled weapons for "just drive around" mode. I'll keep that in mind for the future.

Thanks - and yeah, there's no current need for the rocket launcher aside from shooting at the environment. As for timer sound for 3, 2, 1, that's a good idea. The only current roadblock is that the actual duration between numbers varies based on how far the camera has to fly to reach the start of the selected scenario once you select it as I'm counting down while in flight, "GO" is actual arrival at starting point. It would feel broken right now if for example there are 3 rapid beeps and then next time 3 beeps with a long delay between them. I guess I could just not start the countdown until you've actually reached the starting point, that probably is the best way to go anyway ..for testing purposes, it's made the most sense to be as near-instant as possible to try again (i.e. hit R then click the route, over and over.. and over.. and over.. and over lol).

 

Yeah it's almost certainly something with my browser, though I have no idea what. I wasn't using full screen. I have a 5700XT, so it's not a horsepower problem.

The only real thing was that I didn't know the goal itself. Some simple text at the start would have made it clear what I was supposed to do.

Sorry, I was talking about during the race. The first time through I didn't realize it was on a timer, so I had no idea why I failed. If there had been some countdown noise when the timer during the race got low enough to hit 3, 2, 1, I'd have realized what was going on.

 

It's not just your browser - it's that Firefox is weak for WebGL from what I've seen and gathered (i.e. search "firefox webgl performance"). It's so far behind Edge and Chrome that I've considered adding a warning on startup.. which wouldn't be that difficult and may be added soon.

I agree, I'll add some text for now. I plan to have a tutorial mode / camera flying around and slowing and looking at things being pointed at with explanations etc., but a bit of text would be a good idea in the meantime as I won't be putting time into that for a while yet.

Ahh - I see, yeah that's a good idea. It's got me before as well, all of a sudden fail and be like ..maybe I'll do something like a warning sound plus flashing a /!\ type of icon near it. I'll try a few things see how it comes together.

Thanks for the feedback - I've actually meant to take a look at your most recent build since Friday, I'll grab it a bit later tonight.

 

@EternalAmbiguity I just cleared the world (5th try). It's coming along nicely, there's been a lot of progress since the last time I checked this out. I'll share my thoughts on doors in particular:

1. Not easily seeing where a door is without backing away from the wall. Maybe there could be some kind of indication across the top of the wall where each is, or on the floor, or whatever so you could just move along the wall to one without having to move outward first to see where it is again? There were several occasions where I had to move around a few times until it worked (worsened by the next issue). Enemies shooting at me, limited health.. "here lies polemical. died fumbling for the door."

2. Using E while running around with WSAD.. means you have to stop moving / let go of either W or D in order to interact. This magnified the above issue because you can't navigate / dodge projectiles while you try to open a door. It would feel more immersive not to fight with controls. Maybe spacebar would be a good alternate control for interaction (if you don't have other plans for it)? That way you could tap it with your thumb while moving around without losing any maneuverability.. or some other key, but spacebar stands out to me as a good option. The gameplay would feel much more fluid if you could run around opening/interacting while also dodging and shooting all at the same time.

That said, it was still fun to play and I can see you've put a lot of work into this. I can't say the end of 2021 is realistic or not - but a good rule of thumb would be if you think it will take 6 months, plan for a year - it's your project, so there's no reason not to. If it is done in 6 months, you'll have time for polishing things further, clearing up whatever bugs, adding additional content, more time for promotion (since you'll be less focused on production), the impending release date won't be keeping you up at night and so on. If it does end up taking a year, you still met your goal and you'll definitely be happy you gave yourself that extra time

 

I played a bit in "just drive" mode in Chrome on Windows 10 with a gamepad, and the FPS counter in the lower left stayed consistently at 60. I didn't notice any stutter. It would be nice to have some crash feedback when I run into a telephone pole -- er, not that I did that. I'm a good driver. ;-)

 

@polemical

Game runs smoothly at 60 FPS for me, on Chrome Version 87.0.4280.88.
As long view camera is from the bumper, I have not seen anything.
But 3rd person camera shows that your vehicle stutter. I suspect that you got something in wrong Update / FixedUpdate, which cause jitter.


@EternalAmbiguity

the room modification system
I would like to see more responsive menu.
So the changes should take place, without needing click CLOSE.
When in modification menu, energy does not restores. But enemies does grow.

the room/map setup
I think better control over opening and closing doors would be nice. At current, you need stand right face into door, to be able open them.
Returned to starting point after getting diode and nothing else happened. Possibly that feature is not complete yet.

combat
I would say looks ok at current state. Need some work of course.

 

Good feedback, everyone! Join us Friday for the next one.