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
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.
Just checked out itch: it looks like WebGL builds are no longer permitted? It’s just as well, because I foolishly moved to HDRP and Unity won’t build with WebGL.
This is a sort of bullet hell, using a cellular automaton as the backend. There are a couple different scenarios, one with moving enemies and the other with them simply growing from one location. There’s no real “player death” or fail state yet.
This is based off of a previous thread of mine here (still on the front page–man, this place is dead): Seeking Simulation-Sourced Solutions: Suggestions?
(Martin, I like your idea, but I think it’s a little too ambitious for what I’m going for)
One could of course spend time tweaking the details for each scenario (like the “bullet spread” or movement speed of the first, or the growth of the second), but I’m mostly curious if you guys think this is interesting, and worthy of further exploration. As shown in my thread there are a few other types of scenarios I could add. My end goal is a game I could release on Steam.
It’s worthy of further exploration if you’re enjoying it - watching the first video, I felt sad for the little guy, no matter how much he was shooting… the sheer hopelessness of his situation, it was inspiring that he never gave up. I’m glad you didn’t post how it ended, it’s good to remember him that way
Is worth to know, what are your players say about the game?
Regarding exploration, there is always a space to explore things. Adding other weapons, challenges, upgrades etc.
Seems like you would be benefiting a lot from System Jobs and ECS. In short DOTS.
@EternalAmbiguity - It could be a fun, unique action strategy game – maybe with a few additional gameplay tools such as being able to drop walls that would corral the growth for a while (until the wall disappears or the automata grow around it, or maybe drop some other environmental things that would affect their growth. The fun would be in devising and executing strategies on the fly under pressure. Narratively, lots of ideas immediately come to mind, such as trying to stop The Blob in a 1950s horror movie style, or defending a sci-fi base against an alien or bioengineered thing long enough for the scientists to escape.
I know I’ve opined in the past on the ease of browser-playable builds of games, but it looked like that was no longer a Unity-> itch option. Does anyone know if I’m wrong, or if there are alternatives?
As to any alternatives for browser-playable builds, what about https://play.unity.com ? You’d still need to be able to build to WebGL though. There’s also the option of just registering your own domain and grabbing cheap hosting somewhere - then your builds for any platform can have (and share) a back end you control, you can use FTP, have your own email accounts, pages can be styled how you want …along with the privacy benefit of no embedded 3rd-party tracking/ads/etc.
Didn’t even know Unity had such a place. Awesome. I can probably drop HDRP (literally only switched because I thought it was a necessary download for the Entities stuff) and get things working with WebGL.
I wouldn’t mind feedback on something related to my compass (the ring+indicators around the text). I just added this in yesterday’s update. It’s better to see it in motion (video link in my signature) or play, but to illustrate:
Firstly, the compass shows nearby points of interest. If an indicator is at the top, it means the interest is directly ahead of you. In the first shot, North is to my right, there are still 3 stars to collect in the next 3.3 seconds, and the green spike is another challenge (which turns gold and transitions out when activated). In the second shot, North is to my left and the next checkpoint is directly ahead.
If you saw that compass for the first time while playing, would you think indicators are relative to the vehicle, or to the camera? At first, I had the indicators around the ring relative to the vehicle. But what would happen is let’s say you approach something and don’t hit it dead on, that indicator would fly around to the side of the ring as you hit it with your corner for example. It was really distracting and sort of looked glitchy because of the rapid change. So I switched it to be relative to the camera view - which sort of solved it, now you can side-swipe something in front of you and it’s still shown as being mostly ahead of you the entire time. But I noticed when I drove past a checkpoint / missed it, but it was still in view of the camera, it shows that the checkpoint is ahead of me, when it’s actually behind the car but still ahead of the camera. That resulted in a moment of confusion. Another issue related to this, let’s say you’re far away from the character/vehicle, you’re looking down at it from the sky or whatever - with indicators being relative to the camera, everything in view is “ahead of you” despite the character being in the middle of it all. Generally in my gameplay you will always be just behind, above or inside a vehicle. I guess I could do it vehicle-relative but offset the “relativity position” to the very back of the vehicle? That’s probably what I’ll do now the idea has occurred to me. Or is doing it relative to the camera just more sane - like most people will assume it’s relative to your view anyway? Without fresh eyes I don’t know which is more likely for a new player. I guess I could put a checkbox in options like “Vehicle-Relative Compass”…?
Make compass relative to a car.
And numbers in it as they are, there is no time to look at them, while driving.
So you either scrap them, or figure out, some other way, to indicate what you need.
Are these number important for gameplay?
If you missed, you will see on the compass anyway.
You got info already perfect / complete messages etc. It is clear enough to me.
On side note, you car behaves weirdly on some turns, before was much smoother.
O maybe is with combination of following camera.
And slow motion is jittery.
Thanks for taking a look …I think the compass being relative to the car is a good idea too - I’ll set the point to the rear bumper and call that resolved.
About behaving more weirdly on turns now, a number of control options were added and defaults are different than when I had them hard-coded, also added assists like anti-roll and airborne auto-level, which is probably also changing the feel of it - a good set of defaults and min/max ranges will definitely be something I’ll need to have playtested at length to refine later, but as I’m probably spending a year on this game and a lot of things are still subject to change, hopefully I can dodge that for a while aside from a quick adjustment or two.
The other world (Vehicle Tuning Pit) has control sliders visible without needing the Control Options menu open, so you can adjust them while driving around. If you get a chance to try again, does turning “Camera Drift Max” down make it better? “Vehicle Turning Radius” can also be adjusted, but if you make it too tight you’ll flip the car more easily turning at high speed. The suspension stiffness and the drift/grip bias can also be adjusted, but a bit too far either way can make things worse (i.e. too drifty you can’t turn so precisely, too grippy you’ll roll instead of drifting a bit, suspension too loose you bounce more when landing, etc.). I get it’s not exciting to spend time tinkering with that stuff, it isn’t for me either, so for now I’ll go with blaming rough defaults
Re slow motion jitter - originally I was running physics at a fixed 120 steps/second regardless of framerate or time multiplier. Now I have a system in place that adjusts based on time scale and will increase if framerate exceeds physics framerate etc. However, recently I’ve had it set to a minimum of 60 steps/second. So it can drop to half as many steps at worst than it could initially. This is good for performance and I didn’t notice jitter myself, but I would rather go back to 120/second and hopefully that resolves it / won’t happen for anyone. Thanks for letting me know.
The numbers that aren’t on the compass or at the top aren’t important for gameplay, they’re just indications of what you earn but there’s always a secondary. For example getting a star briefly displays +# of points at that point in world space (but total still increases at the top of the screen), a checkpoint briefly displays +# of seconds time earned (but total time remaining is always shown - haven’t decided on placement yet, maybe up by the score, it’s above the compass for now). So no, they’re not actually needed. I’ll add an option for the player to enable/disable. I like them so I wouldn’t scrap them entirely, but I get that some people won’t and might find them distracting or obstructing the view. It would be a benefit to performance not having them, so it would also be another useful option to provide for people trying to get higher framerates on lower-end systems.
Edit: I’ve set the physics step minimum to 120/s and added a toggle for the unnecessary text in advanced config of graphics options:
If there’s still any slow motion jitter for anyone, please let me know if it’s in general or only when attached to “rails” (which currently are pulling the car’s body closer to the ground against the suspension a bit). Thanks
I think the concept of shooting something that is growing is fun, since it triggers a sort of ‘disgust reflex’ that is always good to have in enemies.
But right now obviously there’s a problem with it growing exponentially which of course the player can’t keep up with. I would suggest tentacles instead, or limbs you can shoot off without having to destroy the entire limb’s worth of pixels.
I think the next step would be the enemy design, each with a specific type of player win scenario. For example there could be ‘hotspots’ embedded in the enemy that explode and wipe out an area of pixels when you hit them. You could just try a lot of different approaches.
Again, the concept of an enemy growing from nothing into different shapes and forms is very cool and unique, so I think it’s time to explore all the things you can do with that.
Definitely make it relative to the car. The car is what you use to interact with the target.
I think the issue here is really that the marker is always on the edge. What about the circle being like a ‘radar’ and the marker comes in toward the center (the car) when the car approaches the target? That way the marker would not move wildly when you swipe past the target.
Nice game btw, had a play and it just feels like fun!
Thanks for the feedback - I’m glad you enjoyed it!
I can’t really take the “radar” approach while it’s little because I’d lose the center of that to display information (it would cover the markers, or be covered by them). I had considered making them smaller by distance, also considered having mini “range text” over each with the distance (more transparent by distance, so overlapping markers wouldn’t be a mess of text) or over their reflection just under the ring. But I thought that might be over-complicating / too much to look at. I do agree though, it feels like something is missing by not having any indication of how far away something is. I’ll think more on that. However…
I think where it’s headed is that an input toggles the compass “growing” into a larger glass disc map displaying more details while time slows to a crawl (i.e. almost paused). Then when it’s larger - a toggle between your radar view idea vs. sliding the markers out to the perimeter again while it shows a bunch of relevant scenario-related details in the middle. I’m mostly leaving that for the future when gameplay mechanics are done though. I also considered having the compass elsewhere on the screen instead of where it is, but anywhere else felt like too far away to glance at / disorienting.
Edit: Fixed typo (I meant to say “glance” not “glace”). Also about the compass being relative to the car, I did include that change in the update I posted about earlier, just forgot to mention it
Edit: Except the stars …but it’s fixed now, all indicators are vehicle-relative (rear bumper).
…but it’s fixed now, all indicators are vehicle-relative (rear bumper).