Jump to content

  • Log In with Google      Sign In   
  • Create Account






Changing deep game mechanics

Posted by h0wser, 24 January 2014 · 612 views

Game mechanics game design
So, me and a good friend of mine are working on a game together. It started out as a dungeon crawler type game, taking inspiration from the Diablo series. The Diablo games feature mouse movement, e.g. you click on a spot on the ground and your character will move there. So this is how we initially set out to do movement in our game. My friend implemented an A* algorithm and I tied it to the player. So far so good.

After further development and play-testing, I got the feeling that the character movement was a bit stale for a couple of reasons.
  • Player was locked in a grid (this can be good or bad depending on the game)
  • Game-play became focused around just clicking, there was very little keyboard use.
Looking at the first one, the reason the player was locked in a grid was because of the A* implementation. The map is made up of square tiles, so naturally the A* simply uses these tiles for pathfinding. I didn't like it because it felt so restricting towards the player.

The second one takes a bit of explaining. Our combat was at the time limited melee weapons and the way it worked was, player clicks on mob -> player moves to mob -> player hits mob. Which meant that the combat was more or less a choice of which mob you attack.

Then we added ranged attacks in the form of spells and arrows we added a mechanic where the player could fire in a given direction, instead of selecting the mob you want to attack. Before we added the ranged attacks the game was quite boring, and after a while we decided to focus mostly on ranged attacks.

The big change

A few days ago we decided to scrap the mouse movement mechanic and replace it with simpler WASD movement. Soon after this we decided to remove melee attacks, essentially changing the core of the game. We immediately felt that this was a big step in the right direction. The game became a lot more fun and satisfying to play. With this change we became more inspired and it gave us a lot of motivation to feel our game was going somewhere.

The lesson I'm going to take away from this is that developers shouldn't be afraid to change core parts of their game if it doesn't feel good. You can't fix a boring core mechanic with fancy lights and particles or amazing sound effects. If the core isn't fun, the other crap doesn't matter.

-h0wser




Sounds like a good change -- it's always important to be able to let go of things that just aren't working properly! :)

Have you looked into navmesh-based pathfinding such as Recast/Detour? I've found that to be better than grid-based A*, due to the fact that finding a path returns straight lines to waypoints rather than the tile-based zig-zagging of a grid path. It's more natural-feeling. Plus, it's pretty fast, often faster than a grid-based approach since larger areas are often condensed down into a single triangle.

Have you looked into navmesh-based pathfinding such as Recast/Detour? I've found that to be better than grid-based A*, due to the fact that finding a path returns straight lines to waypoints rather than the tile-based zig-zagging of a grid path. It's more natural-feeling. Plus, it's pretty fast, often faster than a grid-based approach since larger areas are often condensed down into a single triangle.

We saw an article on this and thought about it for a while, but that was after we made the switch. We have a deadline in about a month and we felt we'd rather run with what we know instead of trying to do something completely new in just a months time when we still have a lot of other features to add to the game. But we'll keep navmeshes into consideration for future projects!

August 2014 »

S M T W T F S
     12
3456789
10111213141516
171819 20 212223
24252627282930
31      

Recent Entries

Recent Comments

PARTNERS