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.
This is a very shallow review that lacks genuine insight. For each fault discussed herein, there is no justification. Instead, there is a description of how the writer would have done it differently, and we as readers are evidently supposed to sympathize that the writer’s way is simply better.
Furthermore, many of the gameplay mechanics that are identified as confusing are, to be blunt, not confusing. The writer has imagined that a beginning user with no powers of intuition would be lost amidst a blaze of particle-effected options. The writer appears, then, to criticize more for the sake of finding favorable comparisons to his own work than to provide insight into the design of Magi.
By way of example: Shield spheres, tooltips, and magic channels are not poorly explained, un-clearly associated parts of the design. The very brief opening tutorial has as its purpose the task of explaining how the several elements of the interface affect one another. That tutorial does gloss over the details–the many different spells, the amounts of energy required, the mathematics behind various defensive spells and curses, the leveling system, etc. It shows the player what must be done to succeed over the course of a duel.
The writer also makes reference to exceedingly poor graphics in Magi:
“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.”
I see no indication of this. The graphics are simplistic in the dueling area, which will quickly become laden with magic spells. Significantly greater detail is given to the rest of the interface, with carefully aged and grunged buttons that bear remarkably well-designed icons. By game’s end, the number of spells acquired will be immense, and yet the iconography keeps the player completely grounded in controlling the most crucial aspect of the game.
Furthermore, the particle effects are not amateurish, as implied, nor are they overdone or confusing. The player begins with very few spells, and the effects associated with these may be learned with ease. As the player’s repertoire grows, the new types of effects are learned along the way. Why, I must ask, shouldn’t a glowing magic missile leave a comet-like trail behind it? Why shouldn’t a flying skull projectile billow a dense black and grey smoke? Why shouldn’t a mage, upon strengthening their power in blue, defensive magic display a brief burst of blue rays emanating from their person? And how will a player know what their opponent is doing without all of these effects?
The particle effects chosen for Magi are intuitive after all, but only insofar as one may understand magic. After all, how can we judge whether a healing spell should look like a swirling series of clouds? What is our basis for comparison? All that we may judge upon is whether the game, as a game, provides a unique measure of feedback that pertains in some way to the effect performed. In this example, if a player heals themselves, some sort of phenomena should appear, and it should appear at the moment the spell is cast, and it should remain near the player, and it should remain during the time in which the player’s “health” visibly increases. That is all, and that is what Magi provides.
And I must question the writer’s judgment, as well. Am I to believe, for example, that encapsulating the on-screen mage in a semitransparent bubble for the majority of a match is visually clearer than placing a magical object between the mage and his/her opponent? The writer calls upon the creator of Magi to consider how visual representation affects gameplay, but with this example seems to lose sight of the goal himself. Obscuring the player isn’t the answer.
And I find similar suggestions throughout. It is, for example, apparently quite surprising to the reviewer that spells, etc, do not have mouse-over tooltips, but rather, the user is required to right-click the mouse on interface items. But the reviewer has not considered the central dueling element: timing. One does not have time to hover over an icon, wait for the pop-up tip, and read it. As such, the game’s creator provided a tooltip mechanism (mentioned right away on the setup screen) that pauses the game, giving the player enough time to read and continue at their pleasure. In this case, rather than adhering to the clichéd tooltip mechanism, the creator devises a superior mechanism for the type of game he has made.
The same lack of consideration applies to the recommendation for a scrolling message box, detailing the action of the game. The player does not have time to read messages, and often does not have access to the same number of spells as his/her opponent. The effects clearly diffrentiate each type of spell; adding another “traditionally established” text readout takes away the creative originality of this title with no gain in usability.
My thoughts regarding the author’s opinion of strategic depth in Magi are mixed. The author seems to have forgotten that he reviewed only the demo version of the game, with limited spells and limited opponents. The reviewer should have considered this limitation and softened his comments, but he is correct in stating that the demo has significant limitations in strategic appeal.
On the whole, the reviewer needs to be more open minded, less inclined to judge games based on their adherence to more familiar gameplay mechanisms, less demeaning, vastly more objective, and a bit less eager to consider a review as an opportunity to find the faults with a game. Consider the game as a whole instead; there are many well-executed aspect of gameplay here, and none are mentioned but by way of introducing negative comments. And do not judge a game’s design elements by whether or not you can think of another way to do them. A review is about whether a game’s design works, not a speculation about whether you could design a similar game that works better.
~Tsa05
This isn’t a “review”. This is a game design analysis. It’s not designed to help people decide whether to buy the game. It is designed to help game designers analyze the game to see how it could have been improved.
I wrote it to organize my own thoughts on the matter (I’m considering applying some Magi-inspired idea to something I’m working on) and published it to help TeeGee and others.
I don’t think Magi is bad. But there isn’t much point discussing successes in this context. We learn more from mistakes than successes (as I wrote on the Magi forums). Thus I’ve made no attempt to balance positive and negative comments. I only wrote things as I thought they might be _useful_ to a designer (not a buyer).
“The writer appears, then, to criticize more for the sake of finding favorable comparisons to his own work than to provide insight into the design of Magi.” I have no ‘work’ of my own to compare to.
“In this example, if a player heals themselves, some sort of phenomena should appear, and it should appear at the moment the spell is cast, and it should remain near the player, and it should remain during the time in which the player’s “health” visibly increases. That is all, and that is what Magi provides.” – Note that all these conditions are satisfied by having the mage appear to be covered in flames for the duration of the spell. Obviously, a mage who is on fire does not appear to be “healing”.
Magic doesn’t actually exist, but that doesn’t mean that people won’t intuit information from particles provided. We do have certain notions, from nature or by cultural convention, of what different ‘magic’ effects should look like. i.e. a Magi fireball vaugely resembles a burning, explosive missile, and thus its function is obvious. The healing field doesn’t resemble anything to do with healing.
” In this case, rather than adhering to the clichéd tooltip mechanism, the creator devises a superior mechanism for the type of game he has made.” Magi’s help system works beautifully. My only criticism of it was that I only discovered it by accident after a few minutes of confused clicking.’
“The same lack of consideration applies to the recommendation for a scrolling message box, detailing the action of the game. The player does not have time to read messages” If you can pause the game to read the right click help menu, you can pause it to read the scrolling text box too, a la BG, BG2, and Torment.
Cheers,
Ty
Pretty good assessment. Although, as an experienced gamer, I found the tutorial to be just right because this is a fairly easy game to pick up and play. The core mechanic is relatively simple in that it’s just “build up categories, throw spells from categories, get the order right” and it’s interesting to see how these simple elements can make an enjoyable game when properly utilized.
If it is not a review, why do you include your opinion about the game?
Because it’s a design analysis.
Reviews are for the purchasing public. This is not.