[Feedback Friday #68] - What's in Your Summer? [6/29/2018]

Feedback Friday will re-open on July 27th.

Can you feel it? The sun is high, the energy is higher, and the people are hyped full of anticipation for the coming months. For me personally, we've got several launches coming up, I'm making great progress on a personal prototype, and I'm getting excited about the next cohort of students in the fall. Ready or not, it's a great time for Feedback Friday!

----

Want design feedback for your new game? Then you've found the right thread! Post here to get precious player feedback. Discuss until we lock the thread to start the two week break.

How To Ask For Feedback

• Show - Pics, videos, or best of all, a playable game!
• Be Concise - Who's got time for Wall 'O Text? Less is more

How To Give Feedback

• Be Positive - Finding redeeming qualities in the worst of games, is in itself a game
• Focus On The Design - Not the designer
• Be Specific - "Your game sucks!" is for nubs

What To Show

• Minimally Viable Product (MVP) - Core game play >>> everything else
• How To Scope Small (Unity tutorial)

Gigi

[PS - Feedback Friday #67 is here]

 

I'm back! Sorry to bore you again but I'd love to share what I've been working on since last feedback friday

I took @Gigiwoo advice and started developing an arena game where you fight off waves of enemies.
I created a potion crafting system and a couple new potions, new enemy types, and fixed up a few issues here and there.

Heres a video that shows it all plus my first crash right at the end!
It's a bit long, it's basically the same thing after the first few minutes just with more enemies.

I'm going to work on the environment next and create a "test lab" rather than an arena, and maybe look at some more interesting enemy types.

Looking forward to your feedback

Are you going to post us a video of your prototype @Gigiwoo ?

 

Ready for something different? I'd been noodling on an idea for a word game. Then, I played a game called Orbia, which inspired me to make this simple prototype. The idea is to have a faster-paced, linear, word game. It's about 20 levels that'll take you about 15 minutes. It's also my first prototype here in FF for quite some time.

-----

Title: Play On Words

WebGL Link

• http://www.goodgamesbydesign.com/Files/WordPlay/index.html

Notes:

• Use the Keyboard (backspace and enter too)
• There's no Juice
• There's no Audio
• There's ~80,000 words

Enjoy,
Gigi

PS - For the couple of really hard levels, you can use the '+' and '-' keys to skip forward/backward.

 

@Gigiwoo I like the fast past approach, I've played a few word games where I get stuck on a word and just give up and never come back to it. Having the player on a time limit with simpler words seems to get around this issue.

Couple of things a noticed (you may have considered them already):
-I like the little transition messages between levels, but it would be nice if you could skip them
-I feel the timed levels should let you continue if you get one wrong, frantic typing can lead to typos!
-In the levels where you can enter 4 or more letters, it would be nice if there was some visual indicator to show that more letter slots are available after the fourth circle (maybe faded out or something?)

What are you plans for juicing it up? Any particular style you're going to go for?

Looking forward to seeing more

 

I decided to upload a playtest demo here for anyone that's interested. Let me know what you think

https://www.dropbox.com/s/8amw72zoiwu8asv/Devolution_v02.zip?dl=0

Notes
- There are only 4 potions, the other colour combinations wont create anything, you'll have to clear it or cancel if you get the combination wrong
- Potions (besides reflex) lock down the inventory until you press V to vomit and cancel the effects (or the potion times out)
-The potion spawns on the left of the bench (from the start position) just in case that's not obvious
- There's currently a bug where you can't pick up multiple items in close proximity, so try to use 1 potion at a time to avoid this

Cheers!

EDIT: Does anyone know a good place to find playtesters?

 

@Gigiwoo - It's fun! For some reason the enter key often caused my entries to fail; I had to click Go manually with the mouse, which broke the flow. What are your plans (if any) for taking this forward?

@Serinx - If you're looking for testers who will be too kind, take it to an in-person meetup of gamers or gamedevs. Most people have trouble being brutally honest face-to-face. If you're looking for testers who will be too unkind, post it online, like on Gamejolt or Itch.io. People on smaller sites like Gamejolt are generally kinder than Steam, especially if you make it clear that it's just a prototype and you specify what kind of feedback you're looking for.

 

Thanks @TonyLi, I took your advice and added my game on itch.io

https://serinox.itch.io/devolution

 

@Serinx and @TonyLi - Thanks for the great feedback. I don't know what I plan to do with it. For now, I just wanted to bring this idea that was noodling in my brain into reality. Sometimes, seeing a functional prototype is enough, other times, I want more.

PS - I think I observed the return key issue - I think it has to do with going very fast, entering a 4 digit word, when you were only allowed to enter 3. It feels like the game messed up. If that's the problem, then the fix is to modify the experience a tad so that it is more clear when you can't enter a word - for example, shake the letters a bit, gray them out, etc... It could even give you a slight pause to prevent the error key after hitting one-letter too many. I could also make the failure text give a specific indication also.

Gigi

 

Not to get caught up on implementation problems (I realize it's a design prototype after all), but I narrowed down the issue. If you use the mouse to click Go! to submit one word, and then press Enter to submit the next word, it always fails, even if the word is correct.

That said, I refreshed the game and played through with keyboard only, and enjoyed it yet again. I also like how you use the same mechanic for UI responses, such as having to type Y-E-S to acknowledge that you're ready for the next stage.

 

@TonyLi - You rock! Thank you for exploring that in more detail - that's a great edge case. Awesome!

Gigi

 

@Gigiwoo
A fun little game that, with the right sprucing-up, could be popular I imagine. One thing that bothered me was the lack of ability to undo a letter choice. Sometimes I click a letter only to realize an instant later that it's not the word I thought it was.

 

Squeezing this in at the last second but here is my latest demo of Wake of Poseidon, a prototype I started last fall and am now pursuing full time.

It's still in a rough state as far as menus, crashes, and quality-of-life but the core gameplay and visual style have been nailed down at this point and it's mostly a matter of content creation rather than systems design. At this point I really just want to get an idea of what the difficulty is like for others.

Rough Demo - Windows Only: Supports Gamepad and Keyboard/Mouse. Two players can be supported with two gamepads.
http://wakeof.net/wop.zip

 

I like it very much! I even made it to the end.

Gameplay:
1. Autoaim: I love it, not every game needs to be a decrepit Mouse-Aim-Top-Down Shooter. The auto aim is nice since the game is more about evasion and positioning, speaking of which:
2. Reason not to shoot: There is no reason not to shoot. Game input needs a reason of not constantly being used even if it is minor, otherwise, why even bother making it an input? Suggestion: Add a Magazine and a 0.75s Autoreload to each gun, When not shooting the magazine is restored after 0.75s, when out of ammo, this 0.75s are enforced. That would give me enough reason to not constantly holding the trigger on automatic rifles
3. More Options: Add a Melee attack that also reflects enemy projectiles, reflecting a projectile will nullify other projectiles within a certain radius, i can totally envision a Ninja class focusing on melee only.
4. More Options: Add a dodge roll because every game is better with dodge rolls
5. Presentation: It is hard to make out the depth of enemy projectiles. Projectiles need a small definite shadow in my opinion so you can see exactly where it is

Design Choices
6. No fire rate restriction on default gun. I would make it a slow firing auto with a slight boost to rate of fire when manually triggering, rewarding those who like to trigger each shot themselves. Also, make is a bit more potent, because shooting too much is a chore
7. I am not sure about killing enemy projectiles once the owner has been killed, makes it very rewarding to just stand far off the enemy and spam bullets so the enemy is dead before the bullets reach you
8. I like how the upper body animation switches when not shooting for 0.5s
9. I like how enemies sometimes engage in battle by jumping off a cliff, gives you some time to evaluate and looks flavorful


Issues you might not be aware of:
10. Your background stutters, like really hard, very noticable in bright scenery.
The character's screen positions looks smooth, but the background scrolls in a very stuttering style. Possible sources:
- Rigidbody usage? If you use Interpolation, be aware that doing anything to the rigidbody that is not Forcebased will break interpolation. I got some code to do manual interpolation of you are interested
- Time of Camera-Position-Update? Update cam-position only after every other gameobject has settled, this is might be achieved by moving camera in LateUpdate but depends totally on your scripts

Issues you are certainly aware of:
11. Settings | Continue | loosing all lives | finishing: crashes the game
12. At the first upturn, i ran right, thinking i need to jump on the rocks. I landed on the first rock but was unable to get back up loosing all my lives trying
13. later in the map there is a small jumping section where you need to fall of in downwards direction. The design suggests that this is a gap so i overjumped it into my death
Sound: Track is fitting and subtle, like i should be. But volume levels and some sounds feel a bit off
14. recoil when being hit does not regard attack direction, only player look direction

15. I jumped into the waterfall.. and died? There is no waterfall in any game i know that does not hide some easteregg

Great Job so far, please continue on this build and post the progress into the next FF-Thread
EDIT: I forgot: I totally dig the visual style of your enemies

 

Thanks! I'm glad you like it! And I certainly will be posting more!

To address a few of the points you made:
1- Auto-aim: Everyone seems to agree that this was a good choice and I'm very glad and proud of that gact. Thanks!

2 - Reasons to not Shoot: This is partly a goof. The weapon pickups actually have limited ammo but I usually keep it disabled for testing purposes. Forgot to switch it back on in my haste. Also, I had planned to add many destructable objects for cover that would get obliterated if the player attacked indiscriminately. Sadly, had to abandon that due to limited dev time.

3 - More attacks : I really wanted to include melee combat but, again, time forced me to drop it. I did prototype a projectile deflection system but it didn't play as well as I imagined. It was usually easier, faster, and safer to just dodge.

4 - Rolling : I considered this and then completely forgot! Thanks for reminding me. I'll try a prototype soon.

5 - Projectile Depth: This has plagued me for a while. I tired adding lights to them to help. I'll give shadows a shot too.

6 Pistol Fire Rate: Great idea! Consider it done!

7 - Projectile Despawn: Agreed. I've been putting off fixing that due to mote pressing mattets. Instead I want projectiles to have a limited lifespan after the enemy dies along with a flickering effect to indicate it as such.

10 - Background Stutter : Thanks for the headsup! I thought I had fixed this but I know in some cases (especially low framerates or slow player motion) it can still be seen. It's very complicated and results from the camera smoothly tracking several other invisble, smooth tracking objects. This is likely causing a kind of 'strobe effect' when things get out of sync.

12 - Jumping on to rocks: Thanks for the info! I'll redesign it to make it more obvious where to go.

13 - Poorly designed drop: Yeah... I knew better than this. I even have a rule about this in my design document. Thanks for re-affirming it. I'll fix this asap.

14 - Recoil on hit: This was a deliberate choice based on games like mega man and castlevania. I personally prefer it the way it is. Thanks for the opinion though! I'll take it into consideration.

15 - *Shhhhh*, are you trying to give away all my hiding spots before the game even comes out

Thank you for the thoughtful comments! This is the kinda of thing I need to hear more! It helps me confirm/reconsider designs!

 

So I've come back to this point because it is a little concerning to me. I thought I had found an effective solution for it but the fact that you've raised this issue makes me think I need to reconsider a fundamental design (which is scary considering how late in the game I am here!)

As I stated before, this issue has plagued me since the start and my best guess at how to address it was... to remove depth.

So collision detection for the player actually has two modes. When they are grounded it is screen-space collision which means any overlap of hitboxes will trigger damage. I did this so that players would effectively always know when a projectile would hit them - when it overlaps them (note that the hitbox is smaller than the character so it gives a little bit of leeway). However, this simply won't work when the player is jumping or falling. I've added a system so that when they become airborn it switches to world-space collision detection. I've found this works well except at the interface between the two. Often the player will jump over a series of projectiles to a location they think is safe only to find that they are instantly pegged upon landing. I'm not sure what to do about addressing this situation but I feel pretty confident that using screen-space collision or a hybrid is a better way to go than to use only world-space. Mostly for the reasons you stated above - the player has a difficult time of predicting when projectiles will actually hit them due to a lack of depth perception.

Any suggestions on how I could fix or improve this would be more than welcome!

 

Nice solutions, this is a hard question that really depends on how you want your gameplay. E.g. I "thought" that bullet collisions are world space. Reason: Your camera is very tilted, so vertical Movement (= world's Z-Axis which is the Y-Axis in screenspace) is slow compared to horizontal movement. So screenspaced collisions would make your hitbox artificially BIG, bigger than i expected, i got hit very very often.
Also, i remember old games like the old NES turtles, little fighters etc, where your depth was all that mattered and where sprites may overlap, but hitboxes do not.

Your game is not EnterTheGungeon, which has seemingly same screenspace-movement-speed in all directionsand have Characters that are almost a circle in shape.(they used a pixelperfect collision system which is screenspace of course)

So i would insist that world-spcae-collisions and adding clear shadows to each projectile is the best way to go for your type of game. Make sure that the capsule depth of your character is the demth of the shadow below it, so the player can learn: When shadows don't overlap, there will be no hit. Then you can also tone down the movement speed of the avatar if need be.

But try it and see how it reads, if black and colored shadows dont read very well on your floor-texture, my approach is false.

 

I was on a boat, and on a boat, in the water, the premium internet was not sufficient to login to the unity forums. To quote Jim Gaffigan, "It's gotta go to space and back. Give it a second." Now that I'm back on land, the internet is once again a reality! Fantastic FF all - see you next time.

Gigi