I stumbled across a small shareware game called Magi by a fellow called TeeGee when looking at a list of indygames. It looked mechanically similar to an indygame that I am developing, so I decided to download it and try it out to see if I could glean anything.
This game isn’t bad. I actually found it entertaining for a time. But it doesn’t quite make it to recommendation quality.
I see this game as a case of death by a million cuts. The premise is really cool, but a large number of small design mistakes (and maybe one big one) killed it. Some slightly different design decisions, and this game could have been a killer.
I played the demo, so this is what I evaluated.
ATTACK OF THE PARTICLE OVERLOAD!
I start with the interface. Namely, the particles.
A game with this budget, or lack thereof, can be generally expected to have an amateurish visual look. Magi is no exception. I cannot blame the game for the quality of its art. How that art is used, however, is another matter.
Magi makes very heavy use of particle effects. As a budget method of including something flashy, this usually works well. And as a purely aesthetic display, they’re not bad. But graphics in games aren’t just about beauty; they also need to impart information in a smooth and intuitive way. Ideally, the player should know what is going on with no training at all. It should be so obvious that the player can’t imagine it meaning anything else. In the case of spell effects, this means that a spell should be represented by an effect that intuitively indicates what it is doing. In this area, Magi has some problems.
For example, a healing enchantment is represented as a field of small, erratically moving red dots spread out in a large area around the mage. Unfortuantely, there really is no intuitive connection between erratically moving red dots and healing. Some sort of entity which is obviously transferring ‘healing energy’ in a smooth, friendly way would have made more sense.
The ‘shield’, which absorbs attacks fired by the enemy mage, is represented by a floating, shiny blue sphere that sits several meters in front of the mage. Once again, this blue sphere’s function is not obvious. Either the sphere should have been around the mage, or the shield should have formed some sort of gently curved, hemispherical wall in front of the mage.
Each mage holds a staff which ends in a large gem. Little energy streams are constantly flying into this gem. While I understand now that this indicates the mage gathering energy for whatever he is about to do, this effect should have been removed. It is always there; it does not impart information; it just clutters the screen.
In general, the particle effects are too generous. They tend to cover a lot of area. This causes comprehension problems when many spells are in effect at the same time, because the particles overlap and it becomes difficult to tell what is going on. I’ve been extracting information from confusing game visuals for my entire life, but even with some practice I was having a lot of trouble decoding really complex situations in Magi.
I considered the idea that decoding the situation was an intentionally-designed challenge. I hope not. Usually “I lost because I couldn’t figure out what was going on” is not gratifying to a player. Providing incomplete information is a very valid way of increasing strategic depth in a game (consider the fog of war in classic RTS games). There is, however, a different between incomplete information and annoyingly confusing information.
CHANNELS
Magi uses the interesting concept of ‘channels’. A channel represents a more highly charged state in a certain spell class. It makes spells more powerful and allows access to more powerful spells. It is analagous to research in classic RTS games.
This is actually a really good idea. It sets up the classic dilemma between planning for the future, and rushing to action now.
Unfortunately, the way it is expressed is counterintuitive. The word “channel” doesn’t really indicate what the channels are doing.
I suggest a better way of expressing this exact same game element. Place a diagram of the wizard’s staff on the interface. The staff should have slots for gems on it. When a ‘channel’ is added, express it as ‘adding a gem’ or ‘summoning a gem’ to the staff. This more physical representation of the same game element would make the properties of the channels more obvious: you can have more than one of each type, you cannot lose them, and they have a powering-up effect.
INTERFACE
Now we move on to the panel interface itself. I really liked the ‘spell queue’ idea. This was quite well executed, and it makes the game more of a strategic instead of hand-eye-coordination challenge.
One current problem is that if you already have something like a shield, queuing another shield will simply lock your queue until the first shield is destroyed. The first shield should either be replaced, or the shield spell should vanish if it is redundant.
The interface itself uses particles. For example, to particles circle indicate certain spell buttons. Here we have a problem with game-versus-interface delineation. The game itself is already swimming with particles. In this case, particle effects should have been exclusive to the gameplay itself. Events on the interface should have been indicated in other ways.
Another major improvement in the interface could have been made with some text output. Text is usually a bad idea because it is hard to absorb in large volumes. For limited purposes, however, it can be effective. For example, Baldur’s Gate had a command-line like list of info lines that would scroll up, indicating game events. If a character died, you would get “Bob: Death”. If someone cast a spell, you got “Bob: Magic Missile”. This type of output would have been very useful in Magi, since many spell effects are not obviously, tightly quantified into obvious effects happening at obvious times.
The sound was well done in most cases. I especially appreciated the “ding!” noise shields make when they go down. Even though it really makes little sense, it makes it obvious when you’ve lost your shield – even if it is covered in particle effects from other spells.
ATTACK OF THE TUTORIAL INFORMATION OVERLOAD!
Small games like this thrive on their ease of use. Even more so than AAA games with eight-figure budgets, a game like Magi needs to be playable within a few seconds of starting by a naive user.
Creator TeeGee was kind enough to provide a tutorial for us. The problem is that it gives far too much information at once – many times more than a player can reasonably be expected to assimilate in one burst. In this case, we get a full description of all 5 innate character attributes forced on us. We are then treated to a full explanation of every aspect of the interface. I was scared that I missed something important.
Luckily, most of that information didn’t matter. The tutorial should have glossed over the character attributes and gotten the player into battle faster. Simply drop the player in a battle with a simple default character, and tell him to push a button. Then, as he plays the match, slowly meter out information, instead of blasting it all right at the start.
(I made this same info overload mistake when I designed Elemental Conflict and it killed the game. I think we all do it once.)
The game also lacks tooltips. Help is available simply by right-clicking on any part of the interface, which is awesome. What is not good is that I had to find this out by accident, since it was never indicated.
STRATEGIC DEPTH
As far as I could see, Magi holds strategic depth somewhere on the line with 3D 4x4x4 tic-tac-toe. This isn’t bad, but it isn’t great either.
I think that a lot of game design is about creating a game with as many strategic options as possible, but with as little learning curve as possible. Games like Chess and Go are great examples of this: from a very small rule set emerge countless different strategies. These games are still being explored, centuries after their introduction. Since the challenge of Magi is based on strategic decisions and not hand-eye coordination, it needs to do well in this area. It needs to create a lot of complex, interwoven strategies.
Unfortunately, strategically the game is rather simple. It is not that hard to come up with a close-to-optimal strategy for any situation, and there are really only a few strategies anyways. Most moves have a blindingly obvious counter. Winning becomes not about your grand strategic decisions, but just about doing micro-optimizations on the one macro-strategy which works in your current situation.
What we need are more vastly different strategies. A “rush” strategy. A “builder” strategy. A “turtle” strategy. A “beastmaster” strategy. And every variation and in-between on these and many others.
GET MOVING
Magi’s creator, TeeGee, could have vastly expanded the strategic solution space with the simple, intuitive addition of the ability for the mages and their creations to move around in their halves of the arena. Most people would hae expected this in the first place, and it is a very standard thing to have in top-down games, so it would not have significantly affected the learning curve. The strategic possibilities created by monsters who can move meaningfully, shields which are placed in a specific location, and other targeted spells would be massive. It seems like an obvious design decision which was abandoned due to implementation difficulties.
GOOD STUFF
Magi isn’t bad. The premise, while not shockingly original, has a ton of potential. With some relatively minor design changes, this game could really be an awesome indy. Unfortunately, as it stands, it’s clearly in the middle of the pack. I really hope TeeGee keeps up with the game design, I’d love to see what he comes up with after the lessons he learned on this one.