Music sounds kind of like its made in one of those loop stitcher programs.
The models look pretty good but the faces need work. For the style I think you are going for maybe reference some japanese animation models. I liked this MMD tutorial but it might be hard to follow. I don't know a lot about shaders but it would probably be good to use a cell shaded one.
Recent community posts
Music sounds kind of like its made in one of those loop stitcher programs.
- Arted up sections are looking nice.
- Might want to add some pathfinding to that dude.
- I think this can stand out from many indie games of this type since most of them are made in/feel like rpgmaker games.
- I like the painted look and the protagonist is CUTE.
- Please don't use tank controls. I much prefer motion relative to the camera facing instead.
- Use a blend tree in your characters controller that interpolates the speed of the walk animation to get really smooth feeling with the analog stick. This can be made to look especially good if you are using root motion. In this case its really important to implement a faster stopping deacceleration.
- You can solve your camera clipping issues by checking for open space with a raycast from the character to the camera and then confining the camera to that open space. Maybe starting with checking out what the standard asset packages have available would be good.
- <`～´> Fix the mixels! You will either need to use higher resolution characters or do something to render the game at a lower resolution and then scale up in a second render. For the later you would need to write a platformer-suitable collision system instead of using the built in physics. I think higher native resolution might fit this game better though but at the same time it can take more work to make higher resolution assets.
- The camera follows slowly and cannot keep up with a falling player. Given the massive field of view you can probably just use one that is snapped to the player most of the time without any problem.
- On restarting the game the camera stops following the player and instead anchors to one of two fixed areas only.
- It is usually better to leave the control binding dialog enabled for demos until you get in-game keybinding in, or at least don't disable the option to force it with the command line.
- Rocket jumping makes me happy.
- I was critical of the melee attack in the thread before but after trying it out in the demo I think its fine.
- After smashing a window, climbing on the roof, and escaping the level I was not treated to an easter egg but instead to death.(; ･`д･´) Please fix ASAP .
- There are some pretty cute heroes in here. I really like games where you can capture enemies so it would be cool if you could deploy them on your side later.
- The simulation progresses based on the AI instead of the player which can lead to a lot of waiting. I think this needs ways for the player to force the AI to progress.
- Some resolutions the UI is cut off, or the scaling is too small. Unity doesn't have good controls for selecting options in the launcher but you can prevent resolutions you don't want to support inside the game.
- For the scaling I think it might make sense to allow zoom(done by scaling) in-game but default it to something that roughly gives the same viewable area to players on startup regardless of resolution. IIRC you are using the 2 camera/render texture method but you would have to add one more camera and render texture if you want to do this
Pretty neat demo. Its been a long time since oracle and ages so i think its a good time to make this kind of game. Would like to see more juice especially when hitting enemies. Its is maybe too similar to zelda, almost like a romhack. I think it would be good to come up something unique for the game that zelda would not likely do. For example (a bad one though), replacing the combat with duckhunt. Good luck and hope to see more.
- Your game mainly runs out of the Update function, coroutines, and invokes. However since you have a fast-forward, and are spawning things in theses Update based functions the fast forward changes the behavior of the simulation. For example a gun that might have fired twice over 2 frames now needs to do so over 1 frame, while accounting for the enemy position being in 2 different places during that frame. The standard way to fix this in Unity is to run gameplay related evens in the FixedUpdate so framerate/time warping does not mess up your simulation. Otherwise you would need to be able to simulate things like multiple shots over the past frame all happening at different times during that frame.
- Characters are CUTE.
- I expected right click to drag the map instead of pan.
- Needs an easy way to toggle between towers or something to make it easier to upgrade a bunch of units.
- Would be nice to be able to see tower upgrades on the sprite somehow. Pallate swaps could work but are a pain in Unity.
- TO BE CONTINUED DUE TO CHARACTER LIMIT
- Damn son, looking nice.
- Would play well with a controller.
- Difficult to talk to people. Maybe the regions could be larger.
- I would recommend changing the mast controls to one of the following:
- When the mast is pressed down (Input.GetButtonDown), the mast toggles on or of.
- If the mast button is being held down (Input.GetButton), the mast opens if it is not already. If the button has been released for X amount of time, then it closes.
- Camera maybe should gradually move back towards the front while sailing.
- I accidentally off the map and then got teleported kind of far away back inside.
- I would probably copy the controls for wind waker a lot since they designed and playtested it a lot more than a solo dev can, and then change it from there.
- Neat game that belongs in an arcade cabinet.
- The levels start out very different but end up playing pretty much the same after digging around so I think it would be good to introduce the hard blocks a level or 2 earlier.
- I couldn't figure out how to grab the box instead of pushing.
- A couple more enemy types might be good.
- Spooky executable.
- Vampires sometimes spawn inside of the environment and are not reachable.
- Player can jam himself in the environment because turning seems to also move him.
- The retry button after dying sometimes prefers to not appear onscreen.
- Barely any of the screen is visible at one time. I'd recommend adjusting the flashlight size and moving the camera to make sure there is enough visual stimulus onscreen.
- Should probably slow down flashlight rotation speed since I was able to just go helicopter mode and basically see 360 degrees
- I think I broke out of the level or something because everything was black and white outside and the UI flew off the screen.
- Fits the theme the best.
- Cool logo and music.
- Logo has kana mistakes.
- I didn't understand the bounce mechanics well. This probably would be solved with an effect on the player sprite plus sound effects.
- The ball return button seems out of place and I think is better without.
- The spacegirl is a cutie but her proportions are weird in game. Bunny girl proportions would suit her better maybe.
- I like the visual style and color pallet.
- Its a little hard to navigate without landmarks for each path.
- Need a better way to aim the gun. Something like the original resident evil game aiming might work well unless you want to add a lot of vertical bits to the game.
- I think for short music loops like this you need to go more monotone (chords mostly emphasize I) or non-tonal (percussion only etc).
- Art style is pleasant.
- Gameplay would work well if paired with more detailed interactions with planets and other space men.
- It would be more interesting if the fights were not simply win vs die and maybe you could have partial successes and failures.
- Gameplay is unique and really stands out in this jam!
- The pacing feels like a lot of thought went into it, especially how it ties into the music.
- At the same time a fast mode would be nice for after playing it a few times.
- Some kind of online high score table would fit well.
UNITY PROTIP: I recommend to use private variables instead of public HideInInspector because currently if you change the value in the definition it actually won't update on previously placed instances because the value is still technically serialized. This doesn't seem like a problem in GRAVITIES since you generally aren't initializing fields in their declarations but I've seen this be a problem in other projects so I feel it is worth mentioning for future consideration. Generally HideInInspector is meant for when you either are displaying the field through a custom inspector or are setting it through an editor script and don't want humans touching it.
The reason I would prefer the navmesh in this situation:
- Don't have to tweak two different sets of navigation set ups.
- The navmesh is easier to visually debug than collision. It can be harder to setup since it bakes based on renderer meshes though.
- Navmesh does not allow for the player falling off into the void. This sounds like a joke but it was a serious problem on the development of some big games.
- Having the player pathfind is possible (can be useful for cutscenes or some interactions if you want to have much larger interaction regions than interaction alignment).
- Kinematic rigidbodies are difficult to tweak to a good spot for a player character. They are suited for physics type games but for a player character they tend to bounce around and clip through things too much.
There are some drawbacks too though. I haven't done 3D in a qhile but off the top of my head:
- Doors are tricky to do well. Its worse on AI though than for a player character. You can probably handle with either navmesh links or navmesh obstacles. I guess even for rigidbody or CC doors are a pain though.
- You need to add a kinematic rigidbody if you want to get trigger or collision callbacks.
- Other agents may try to walk around the player which could be a problem for zombies chasing the player. Once way around this is to have them approach a point that is between them and the player instead of the player center position.
- Different sizes of agent sizes are not supported so unless you want to do fancy workarounds your player needs to be the same navigation width as your enemies. This is probably not a problem as they are both humanoids. If you add dogs you will probably need to solve this anyway between zombies and dogs. You can do this using an iterative navmesh bake process where you dynamically create a mesh based on the first bake and then change navmesh layers to do the second. Thin enemies can walk on both layers but fat enemies only on one.
Probably for the time being its not important to change but when you get to a point you want to work on player character control I would recommend considering it. At some point when you get around to animations of zombies grabbing players send me a message or something since I have went to hell and back to make pair animations look good.
I'd recommend switching your player character to using navmesh agent like your enemy is unless you are going to add jumping. Doors will be kind of a bitch to solve though unless you make them all loading screens, but you will have to solve that for the zombies anyway. If you want jumping then switch to CharacterController.
- I like the old style 3D graphics and atmosphere.
- Examine is the best feature.
- The main character looks too much like a Unity capsule.
- The music in the starting area feels like its a fancy party.
- Controls are kind of weird being rotated 45 degrees.
- The player moves faster when moving diagonally. If this is not desirable then you should call the clamp function on Movement._movedir right after you are assigning it from the input axis.
- I would recommend writing the player speed into a local variable in your movement function and then you can simplify your sprint code. Alternatively just keep base speed as a separate variable.
- There is a function to hide the cursor (I forgot to use it too).
- The game appeared to have a bilinear filter probably due to being set explicitly to a resolution and then letting the GPU do the scaling. You can do pixel perfect scaling yourself by rendering to a render texture then rendering that in a camera that is scaled to integer multiples. But even in that case if the user sets the resolution below native the GPU is going to fuck it up so you have to either disable it or warn the user.