While I may not be updating my blog very often lately, I assure you that I’ve been staying busy.
As proof, here’s a (very) early work-in-progress screenshot of my current indie game project, Slay the Beast:
Slay the Beast is a versus fighting game where one player controls a huge boss-level monster. While the other player controls a puny (but respawning) hero. The sprites are from Oryx Design Lab‘s Hifi Gothic Set and animation is done with Spine, from Esoteric Software.
The game is still at an early stage of development. Heck, I just started this project a few weeks ago! However, I plan on making WIP builds available soon. Stay tuned for more news. Continue reading →
Prank wars have an ugly habit of spinning out of control. One person pranks another, then the victim gets back at the prankster with a prank of their own. The original prankster raises the stakes with another prank and so on and so forth.
While this sort of escalation is the kind of situation you want to avoid in real life, it is a powerful tool in game design. As a matter of fact, you can find some element of escalation in almost any game worth playing. Continue reading →
Google Risk-Reward and you’ll treated to page upon page on investment strategy. Risk-Reward may be key in getting rich (or going broke), but it’s also vital for making games fun.
The basic principle here is that, in games, the level of reward provided by an action should match the level of risk it entails. Low-risk behavior should generally provide low rewards. A highly rewarding action (say a high-damage attack or a high-value treasure) should require a commiserate level of risk otherwise players will never have a reason to choose a lower-reward alternative. Continue reading →
As the cliche goes: game design is more of an art than a science. As such, there are no hard, fast rules that dictate how a game should be designed. There are, however, mountains of guidelines and examples that provide insight into how to make a better game.
In this article, I’d like to present a few of the game design guidelines that I’ve found useful in my work. Again, they aren’t absolute rules but they are a great way to sanity check game designs to make sure you’re heading in the right direction. Continue reading →
It seems I’m not the only one who suggests designing games enemy-first.
Recently, while reading some game dev books, I ran across a bit of advice with sentiments similar to one of my previous blog posts. The text in question is from “Shooting Game Algorithm Maniacs”, a Japanese game dev book focussing on SHMUPS (shoot-em-ups).
For folks who may not be able to read Japanese, here is my translation of the advice from the conclusion of Chapter 2 (called “Stage 2″ in the book.): Continue reading →
Multiplayer in video games is almost as old as the medium itself. It’s at least as old as Pong, right? As such an old institution in games, you’d think we’d have all the issues related to implementing multiplayer in games figured out by now. Of course, you’d be wrong. Otherwise, I’d have nothing to write about in this article.
In terms of handling multiplayer from a game design perspective, there are several issues that tend to slip through the cracks until they show up during actual implementation. In large teams, the late discovery of these issues can cause disproportionate amounts of time being spent to fix them as they wind their way from the discover’s desk to the people responsible for game design decisions and back to the feature implementor. Continue reading →
The classic SHMUP (shoot-em-up) may be one of the purest video game designs out there. Even for games like Ikaruga that implement systems that dramatically change the gameplay, the core mechanic stays essentially the same: the player must destroy enemies while dodging loads and loads of bullets.
Given the significance of the relationship between the player and enemy bullets, the design of said bullets is crucial to making a SHMUP work. The following is a series of guidelines that I use when implementing enemy projectiles in games. Continue reading →