I didn’t have a substantial amount of stuff to talk about in the past month, that is until last week came along and really pushed that amount over the top. So here’s my long post updating you on the progress of Feast for the Senses:
New Monster Types: Taste-class and Smell-class
The game’s title “Feast for the Senses” came from the idea of all the enemies being based on the five traditional senses (sight, hearing, taste, smell, and touch). I had finished implementing the Sight- and Hearing-class monsters for a long time now and demoed them in my various gameplay test videos. However, I got sidetracked by working on other features of the game and left making the rest of the enemy types on the back burner, especially the poor, half-done Taste-class monster.
Taste Testing
The Taste-class monster is immobile, so it relies on spread a network of detectors to find the player. My initial implementation had it growing a maze-like network of tongue-like appendages to detect the player’s location and shoot directly at that spot hoping to hit them. Unfortunately, I encountered many bugs and other issues with how the tongue-growing algorithm (it was essential a maze-generating algorithm running inside an already labyrinth environment YO DAWG, I HERD U LIKE MAZES…) and decided to put it on the shelf so I could focus on other things. After several months, I eventually got around to working on them again and re-worked them with a simpler detector-spreading algorithm. Instead of tongue-like appendages, they now spread “buds” in a haphazard fashion around themselves. They do the exact same job, but with better and less buggy coverage. I also changed their method of attack from a straight shot to a lobbed shot. Their buds can potentially grow around walls, in places where the monster would not have direct line-of-sight (er, line-of-shot?) with the player. Lobbing the shots would outcome this problem.
Stop and Smell the Réiltín
This past week I’ve worked on the beginnings of the Smell-class monster. They use a simpler, modified potential field algorithm to find the player’s position, inspired by some similar techniques used for some monsters who track the player by scent in traditional roguelikes I found by trawling the internet.
The map is divided into a grid of nodes; each node has a value representing the strength of the player’s scent. Every step, the node the player is floating above is incremented by a constant; the surrounding nodes are also incremented but by a smaller number. Then, at the end of every step, the scent at every node undergoes decay; reduced by a certain percentage. If an idle Smell-class monster is standing on a node above a certain threshold, it would go into chase mode. In this mode, the monster will check all neighbouring nodes and move towards the one with the highest scent value, until it reaches the player and goes into attack mode or loses the scent and goes back to idle mode. Compared to the Sight-, Hearing-, and Bearer-class monsters, who all use GameMaker:Studio‘s potential field algorithm for pathfinding, the movement of Smell-class are clumsier and more predictable, but (to my surprise) they are able to track the player over longer distances and behind obstacles much better.
For an extended look at the tests, watch the following video:
Transitions and Other Interface Improvements
On the interface side, I made some additions:
- For all menus, I added some simple fade-to-and-from-black transitions between menus and the game rooms to visually ease the switching between and added some sound effects to that play when interacting with the menus. All in the name of feedback principles, UX design, etc., blah blah blah.
- A new menu was added where you choose the level you want to play in Arena mode, now separate from the main menu. Each level now has weapon restrictions or loadouts, represented by the icons on the right side of the screen.
- Finally, I added a pause feature during gameplay. This was necessitated by the newly-added transitions mentioned in the first point. Otherwise, the game would behave weirdly when moving from a game room back to the arena menu. In the video above, the reason I’m pausing seemingly willy-nilly is to make sure the audio cuts and resumes properly and that nothing disappears or breaks during the pause.
Gamma/Brightness Correction
When I took a look at the histogram of a screenshot of the game in Photoshop, I noticed that the range of luminance values was narrower than I expected. For a long time I had thought the game’s graphics were a bit dull, possibly due to all the colour mixing that goes on with the lighting engine. That inspired me to add a simple shader that changes the gamma level of the application surface. I’m experimenting with it to see if increasing the default gamma a bit will make the game look better or ruin the atmosphere. So far it seems like an improvement.
