Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

nurikabe

38
Posts
28
Followers
A member registered Jul 10, 2016 · View creator page →

Creator of

Recent community posts

  • Very cute protagonist.
  • I like the mode running from the snowball.
  • Race feels cozy because of the other racers.
  • Reverse look kind of sucks because of the short view ahead.
  • There is no girl wearing yeti pajamas. I am disappointed.
  • This game is looking pretty sick.
  • I like that you can customize the slime girl.
  • A lot of features in there so feels like its about ready for a vertical slice and then production.
  • I am kind of mixed on the camera
    • It works well for navigating the levels.
    • Helps keep rendering manageable even when theres no occluders around.
    • Avoids a lot of issues that cameras with more axis have.
    • Its kind of hard to judge heights with it but that could maybe be solved with blob shadows.
    • The camera being far away gives a kind of impersonal feel and doesn't add much excitement to combat but if you want that kind of stuff you can always have temporary camera effects.
  • Its about damn time for the sequel.
  • The new feature is amazing.
  • I like that the source code is included so I don't have to decompile it. but I'm completely smashed to read anyway.
  • Keep it up.
  • Firing on key up is weird. Generally you should do actions on key down unless you have some visual feedback while a key is held.
  • The fireball likes to destroy itself right after spawning. It might be responding to the player collision.
  • Input direction is being mapped to a world space, but most players find it more natural for input to be mapped based on the camera orientation.
  • There is no indication that the player needs to press a button to change scenes.
  • I could not progress further at a point when sceneChangeScript::Update started throwing null reference exceptions. Unity is kind and catches managed exceptions for you but I still do not recommend letting them go uncaught (this will crash on certain builds). In general I recommend being careful about checking for null before dereferencing things unless you have a compelling reason not to.
    • While I can't see what null reference was causing the exception, the static Animation component reference is highly suspicious. It is possible that the component was destroyed and then the reference was technically still pointing to a now invalided object, which Unity's strange comparison overloading will make it throw exceptions as if it were null. Static is a thing best avoided, but if you wish to have a static reference to a Unity Object, ensure that you set the reference back to null properly from the OnDestroy function unless you want a memory leak and possibly spooky shenanigans when using interfaces and events.
  • Too easy.
  • Maybe could have difficulty setting.
  • Cute protagonist.
  • Better practice that Loomis.
  • Looks pretty polished for a demo. Keep it up.
  • The bosses stage progression was good.
  • I don't like mashing the attack button for squeezing in hits.
  • The title image made me think it would have a cute protagonist, but then I played it and realized I was bamboozled.
  • The art is pretty cool.
(1 edit)
  • Those models looking damn fine as ever
  • I am too stupid to use the items so I just ran to the end.
  • There is a break in the navmesh in the last area.
  • I would recommend  doing a sphere cast from the player to the camera position and if it hits a wall bring it in close enough not to collide with the wall and possibly higher if it gets really close. However this should ignore dynamic objects, but turn them visible if the camera position collides with them. Make sure when letting the camera move back out to only let it do so smoothly.
  • This game can probably get away with the single raycast and cone check against the player position but I personally like checking against several points and then creating a score based on LOS, distance, and angle.
  • After pressing enter a few times the game loaded the menu screen again but still had the game UI up. I couldn't find anything about this in the code so I don't know maybe I'm too drunk.
  • Cute protagonist.
  • Pressing w through the "the sign says" part seems unnecessary
  • wtf are these default controls man
  • Pixel stretching, especially noticeable during scrolling
    • You can fix it by picking a native resolution and then rendering to a render texture at that resolution and then scaling that texture by integer units before rendering to the screen. its kind of a pain in unity when using low resolution assets but its possible to do right
  • Your character is fast enough that even if you have subpixel collision you probably dont need to fix it.
  • The interval between the two characters voices is the tritone. I would probably choose a less tense interval unless that is what you are going for.
  • I was going to complain about the portraits being higher resolution than the 2D game mode but since you have the 3D switching oh well.
  • I think I'd prefer a short input buffer on the movement controls.
  • The notes don't say which direction to put the books in a second time and I forgot.
  • Why isn't the painting a loss reference? You had one job.
  • I like the characters and the simple 3D art style.
  • The 2D is a bit hard to read but its functional for now so it could be improved later.

(; ・`д・´) This is not a roguelike!!!

I like it. Feels very polished. I'd love to see it fleshed out with more monsters, rooms, etc.

  • 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 .

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.

  • (CONTINUED)
  • 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.

Don't worry, the helmet will return. (^_-)-☆

I like how it has a really nostalgic feel but manages to avoid feeling like a clone of any of the old horror games.

Because I have a bunch of technical notes I dropped them in a pastebin http://pastebin.com/w8hmgh85

  • 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).
  • >EnemyMovement1.cs
  • 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.

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.

  • Great art style.
  • Could use some kind of interaction during the waves or a way to speed it up.
  • Give it a story about a girls in pumpkin/mushroom suits etc.
  • Could be spookier.
  • I'm not a big fan of WASD to aim but I guess I got kind of used to it after a bit.
  • I like that the knight can shoot arrows from his dick.
  • This game is racist.
  • Nightmare difficulty (appropriate for the occasion).
  • I think the original places mines on the first click so its never an immediate loss.
  • Crusader girl better show up again.
  • https://youtu.be/ZTq_XHdQPSI

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.