#First project feedback

9 messages · Page 1 of 1 (latest)

vivid frigate
#

For my first MonoGame project, I built this simple game involving a circle jumping across a line.

  • The line segments are generated randomly and aligned properly next to each other using some trig.
  • The collisions are handled using the separating axis theorem as that seemed to be an appropriate method for handling non-axis aligned collisions.
  • The highscore is just stored in a textfile, which seemed like a quick and easy way to store a single number, but I understand it probably isn't the best way to store variables between games especially when the projects get more complex.

Taking inspiration from #1237119102389194792, I would love some feedback on this project, mostly along the lines of if there are any poor programming/monogame practices, if the structure/engine design is bad etc.. Any advice would be greatly appreciated, thanks in advance!

Repo: https://github.com/noah-dyson/Circle

old ember
#

I'd say well done, that's a great core game mechanic and not an easy feat for a first ever game at all!

I think what is misses the most to make it more fun is little things to spice up the experience and dopamine delivery, this is an amazing talk on this; https://www.youtube.com/watch?v=AJdEqssNZ-U I bet if you implement just a few of these ideas, itll improve the look and feel of your game by at least 500%, 7 day moneyback guarantee.

YouTube
Dutch Game Garden
Jan Willem Nijman - Vlambeer - "The art of screenshake" at INDIGO C...

INDIGO Classes 2013: Jan Willem Nijman is 50% of indie power house Vlambeer. He talks about 'The Art of Screenshake'. Why is it that one game plays great and another, similar game feels terrible?

▶ Play video
#

because you specifically asked for programming feedback, I had a very quick scroll through, nothing glaringly standing out. I would never really be concerned about this unless it is causing performance issues. In game dev far more than software dev we dont really care of right solutions, we care for pragmatic solutions, approximations, and any approach that gets us to deliver what we want to deliver. The only time you need to rethink your approach is when you have dificulty with maintenance or performance, otherwise just focus on building games.

vivid frigate
# old ember I'd say well done, that's a great core game mechanic and not an easy feat for a ...

Thank you so much for the kind words.
I can definitely see where you coming from about fun-ness, the little animation at the beginning is probably the only interesting part. I've had a watched through the video and he makes some really good points, and I can see some applications despite my game not being particularly shooter-like. I have come up with a short list of things that I could add to improve the fun-ness:

  • sound effects upon jump, death, and new highscore
  • colour animation upon death not just changing it straight to orange
  • camera follows player up line, removes the need for a top and bottom, and could make it feel like you're actually climbing
  • a little animation on the score counter
vivid frigate
old ember
#

Sounds great, pretty much a rule is that everything that happens should have both visual and audio feedback, aside from that I would also think about adding a way that gives the player more feel of the movement, perhaps you cna have rings behind your main ring where your previous position was like some kind of echo trail effect, the camera can move forward a bit, you can increase the speed over time etc. the sky is the limit and these little fun bits really are where its at no matter how simple the game is you can make anything feel awesome and its always fun to do all these little bits that give so much back

old ember
#

if software is a science, games is an art form, there's no rules 🫡

vivid frigate