Six Months Of No Blog Updates!?
Yes, it’s been forever since I last updated this blog. With a relatively small team of busy developers who all attend some school or another, it’s hard to find time during the school year to blog about recent updates. I can assure you, however, that we did not put the project on hold while we were busy earning grades. Instead, we used our limited time to come up with an interface we decided we liked.
Sources of Inspiration
You hardly ever walk a road alone. Innovation is merely a keyword used to say that something has never quite been presented in some way before – not that no one has ever thought of the idea. When we first began drawing concepts of what we wanted the Zems Interface to look like, we started checking out other similar projects, namely Elements and Shadow Era, for inspiration.
Out of the two we used for reference, I have to say I liked the interface for Elements the best. As you can see from the image, Elements is very minimalist, showing the user only essential information. Everything else, such as descriptions, better art detail, etc. is shown when the user hovers over the appropriate element.
In addition, Elements makes this interface fit on a screen no larger than 900 x 600, which means players with older or smaller screens can still play the game. For browser-based games, this is a vital component of good design, since you want to keep everything above the fold (viewable to the user without making them have to scroll down the page to see everything).
One issue we had with the design of the Elements Interface is the fact that our game was more complex. Elements is a rather simple game based on bringing your opponent’s life to zero through means of attack. Zems focuses on multiple win conditions based on shrine capture and neutralization, which is much more akin to board games than a traditional fantasy card game. Thus, our main problem was the fact that we needed to convey more information in our interface than Elements, but without sacrificing a portion of our user base by requiring a larger resolution or forcing players to have to scroll down a page.
Our second major source of inspiration came from Shadow Era, an iPhone app produced by Kyle Pool and Wulven Studios. As you can see on the right, the Shadow Era interface is even more minimalist than Elements’ interface, although the specific details (card text, numbers, etc.) is hard to read. Shadow Era remedies this problem by having the screen zoom in whenever an element is clicked, so for example, clicking on any card in your hand causes the screen to zoom in to your entire hand, allowing you to see every card in your hand in detail.
I’m not saying this interface concept doesn’t work in Shadow Era, because it does. It just takes some getting used to, while for Zems we would like new users to pick up the game without needing to get used to the interface.
The First Concept
Our first concept revolved around two main concepts: emulating the real-world card game interface and utilizing pop-ups as a way to convey detailed information.
As you can see, the playing field looks very similar to what a real-world trading card player is accustomed to seeing. In fact, this interface is identical to what our floors looked like when playtesting the game, minus the circles in the center of the field representing the eight shrines.
Of course, there are some obvious problems with this interface. How would new users know what phase of the turn they are currently in? What are the exact resource counts, such as number of cards left in the deck? These are all obviously more important than having a familiar interface, and while it seems silly to have even coded this, we wanted to document our progress in designing the interface (as well as be able to include it in this blog post), so we did.
You can find the coded version of the interface online here: http://www.zems.com/proto/v1
The interface runs on a game loop developed by Sleepless Software, who we sought to commission due to their extensive node.js experience. After we ditched this interface concept, the deal fell through, unfortunately.
For our next interface concept, we decided to come up with an interface that was not as dependent on emulating the real-world experience.
The Second Concept
When we first began conceptualizing ideas for the second installment of the interface, we decided to look at the interface of Magic Online, a desktop application emulating the Magic TCG experience. We originally considered looking at Magic Online’s interface when coming up with ideas for the first concept, but we felt that a desktop application had too many advantages web-based games did not (mainly full-screen capability), so we avoided it. After we scrapped our first concept, we decided to take a look at Magic’s interface in order to see how they handled the conversion between real-world card game to virtual simulation.
As you can see, Magic Online features a dedicated area for showing the particular details of a card. In addition, the interface doesn’t attempt to hide much from the user – the cards on the field are simply shrunk-down versions of their life-sized versions. While this may work for Magic since long-time users will be able to recognize a card, both by picture and overall text structure, we felt that using shrunk-down versions of the actual cards (which we used in our first concept) was not a good idea.
One thing you’ll notice about the Magic Online interface is that it uses different background textures to separate the various areas of the field. We felt this was not particularly appealing (if not downright ugly), so we decided the best way to isolate separate field elements was through the use of horizontal lines as simple, obvious dividers. The Magic Online interface as a whole felt rather crude and poorly conceived, although it did give us a starting point for our second interface concept.
As you can see, we combined elements from Magic Online and Elements in our second interface. The large card to the left represents the area we dedicated to showing card details – the idea is that when a player clicks on a card (represented by a thumbnail on the field), the larger version with all its details is shown on the left.
Besides having a dedicated area for card detail, we also increased the amount of numbers the player would see. We placed number counters on the deck and graveyard (deck is on the left, graveyard on the right), as well as numbers on the resource counters on the bottom so both players have accurate resource counts. We also made an administrative decision to reduce the total number of shrines in the game to seven, since the previous number (eight) was an even number and even numbers allow the possibility of even splits (4 shrines for each player), indicating a tie.
After developing this interface, we realized that the detailed versions of our cards were now too large for the reduced-size interface we were aiming for following the first concept. In addition, we felt that an unnecessarily large amount of space was being allotted to showing the details of a card, when we could just use a draggable pop-up to accomplish the same thing.
With these aspects in mind, we decided to create a third, and hopefully final, concept that took these factors into account.
You can find the coded version of our second interface here: http://www.zems.com/proto/v2/
The Third Concept
We felt our second concept captured a lot of the idea we wanted fairly well, so we based the third concept on the second one. In addition, we did more playtesting and reduced the scope of the game in order to help minimalize the interface even further. For example, instead of having ten possible resources, we reduced the maximum amount of different player resources to two. One of the reasons we did this is because we felt that a deck composed of cards from every category or type was not something we wanted to see in play. In Elements these decks are called “Rainbow Decks,” and these types of decks have come to dominate the metagame due to the fact that they account for nearly everything. We want players to create decks that specialize on a few strategies, instead of creating decks designed to handle every possible situation.
We also removed the ability to physically see the opponent’s deck and graveyard, since a player only needs to know how many cards are in them. We don’t intend for this game to allow players to bring cards to the field from the opponent’s deck or graveyard, since that concept is unnecessarily complicated when we already have a rather complex game.
The biggest change we made to the interface is the addition of a chat/logging area. What was previously a dedicated space for showing a detailed card has now been replaced by a chat system that will allow both players to talk to each other, as well as display in-game events. We feel that a card game can become quickly convoluted if there are not at least two ways to see events happen, such as both on the screen as game actions and in text via the game log.
The game phases are now clearly marked on the interface, which we frankly forgot to include in the second interface. Above the chat area is a menu showing vital game information such as the number of resources both players have and cards in each player’s hand, deck, and graveyard.
The coded version of this interface can be found here: http://www.zems.com/proto/v3/
We are far from done. After creating our first concept, we have yet to really test out our concept in practice, but we feel that what we’ve come up with is a very stable concept that will minimize the amount of tweaks and edits needed once we perform actual testing. Overall, we were surprised in the amount of time and effort we spent (4 months) on coming up with an interface that both works for our game, and yet is different from the interfaces of other online card games out there, but we feel that the time was well spent and we are excited to begin working on getting the actual game development.