Virion – Asset Post

For Virion I mainly focused on Level/Board Design and Aesthetic elements of the game, as well as some place holder work on the Instructions.

One of the first things I did for Virion was board designs. I came up with a multitude of board designs for potential use in game, each with a unique aspect that was an attempt to set the levels apart and to prevent any of my levels from being too “generic”.

One of the first levels I made was Chasm, the level that playtesters played during the first playtesting session.


Many of the playtesters liked Chasm, and I think it allowed many of Virion’s core mechanics to be showcased very well during play. Chasm is a level that forces conflict very early in the game, mainly through the use of spawn location and the blanked out islands running through the centre of the level. The location of these islands creates an invisible line which marks “my side” and “your side”,  which creates an interesting battlefield, especially through the use of reverse symmetry.


This is an ugly picture detailing the various areas in the level. As you can see, the space in Areas 1A and 1B is limited, and as this is a territory control game, players will be wanting to expand outwards to capture more territory and control more space. Units in Areas 1A and 1B will be forced to move over the line if they want to expand, effectively breaching the other team’s Area 2. If the (inexperienced) player wants to move the Trojan out, they will be drawn to the “mid” corners of Areas 2A and 2B as that is the location of the most free territory. This will provide an attractive target for the other team, a target which they will be willing to move pieces in through the centre of the levleto capture. Both of these scenarios create conflict, and force the players to plan their moves carefully but aggressively to capture as much territory as they can to win the game.

Another level I created, “Duo”, for another playtest was based off of the idea of a tutor, and features a split across the middle. This creates two separate battles on each side of the map.


This level was interesting to design. The decision to have two Trojans in the centre of the map facing off against each other was one derived from feedback saying that the Trojan was the most useless unit during the middle and end of the game in Chasm. I wanted to make it so the Trojan was a unit not confined by its spawn point but also immediately relevant/in the fight. I gave the Trojan three escape points so it could never be trapped, though using those escape points would usually lead to the other Trojan gaining control of the centre of the map.

Having each side separated from each other made me worry slightly, as I was afraid that matches would end in a stalemate and a conclusion would be nigh impossible to achieve. Upon a suggestion from our team’s programmer to open the back so units can pass to the other side that problem was mostly bypassed. In the games I saw where this map was played, conflict was prolonged but a stalemate never occurred.

I also made 4 other maps for Virion, though those did not appear in either playtest and are not finalised so I will not talk about them in this post.

Another role of mine was to create the Spyware model, an easy job thanks to the concepts of one of our team members and previous experience with 3D Modelling.

The spyware was a unit designed to look fast and dangerous, befitting of it’s role in Virion. It is comprised of a single sphere located in the centre of the model, two sharp pincer-like objects at the front and three small cubes floating at it’s back.


Modelling the unit was easy enough, as was rigging and skinning the model for animations (which we weren’t sure about having at the time).

Eventually the spyware unit’s rotation was altered, so now it looks like this.


Kind of like a rabbit, which fits the Spyware’s “fast” role a bit more.

I was also responsible for particle effects, not all of which had been implemented for the playtest. It’s hard to show all the particle effects exactly how they act in a screenshot, but my best attempt was made to make all effects fit their roles. I also gave blue particle effects a greenish tint (partially visible in Hit effect, takes place at different times from when screen was taken for most of the others) and the orange a red tint to make them more distinguishable on the game board.

Hit – Explosion outwards symbolising destruction of enemy unit.

Cap Unclaimed – Stream of blue or red going downwards to signify the player capturing the unclaimed tile for the first time.

Respawn – Rising blue or red coming out from the spawn tile, beneath the unit.

Move – Blue or Red trailing units as they move.

Cap claimed –  A carpet effect which is meant to cover the claimed tile as it converts.


I also created the placeholder instructions screen, something I tried to make as brief and to-the-point as possible, but also easy to understand. I think I did a moderate job, as most people who read them were able to play the game without issue. I did miss out on some crucial elements such as holding to win, which was a pretty bad mistake considering it’s how you win. Keyboard controls were left out, another mistake which came from me not thinking about the possibility that people might not be playing with controllers.


Virion Post-Mortem

Virion is a game that took me by surprise. When we first started coming  up with ideas for what it could possibly be we had made a game that was overly complicated and not exactly a friendly experience for players. With that said, it was kind of weird how an idea for a game that was so confusing and difficult could turn into something that turned out as well as it did.

From here on, I’m going to refer to the pre-tuned version of Virion as E.V., or Early Virion for the sake of simplicity.

When we first started brainstorming ideas for what Early Virion could be, it felt like we were attempting to think of a game with too many mechanics but not enough space, if that makes sense. Players would gain Action Points for performing certain actions, things which would determine how many things they were able to do per turn. Units would have health, something which created awkward contention around the areas which granted players AP. Some units had over the top abilities, things that seemed to have no real place in a strategy game. In short, it kind of felt like we were making Early Virion a really really awkward fighting game as opposed to the strategy/tactics territory game we wanted it to be.

Luckily though, we underwent a process which allowed us to refine our idea, strip the excess mechanics off of our game and give us the game we ended up creating.

What Went Right?

A massive contributing factor to Virion’s end result was the process of project tuning. It helped us strip all the “fat” from our game so we would be left with something that was less, but still more. We were forced to ask ourselves why we chose to take the path we did with Early Virion and also analyse and question parts of our game we thought we were fine with. We were going to attempt to create a game that was fine in terms of scope, but still too big for our core idea. Our units had no meaning or symbolism at the time justifying how confusing or over-the-top we were trying to make E.V., and as the game’s territory is comprised of Hexagons there was no real symbolism to that either. Our Units weren’t soldiers trying to capture land or defeat an enemy in defence of their kingdom, and our territory wasn’t signifying anything. It felt too simple to have so many extra things like health, action points and control points tacked on.

Prior to the initiation of development for Virion we assigned roles to each of our team members, with no one person focusing on a specific role. We were able to tell each other what we could and couldn’t do which allowed us to assign roles accordingly and prevent any major roadblocks in terms of ability. Where we lacked we were willing to learn, and we would ask for each other’s help if we thought we needed it. The members of our team were also skilled in their areas of expertise. This allowed the development of Virion to go smoothly, with minimal setbacks occurring.

What could have Improved?

Our biggest issue from the brainstorming stage to just before the final playtesting session was definitely communication. While development of Virion did go smoothly, we barely talked or conferred on anything aside from class time or the occasional Facebook post. We had a total of 2 Skype meetings which proved to be immensely helpful in terms of having tasks set and concerns/questions discussed, but a lot more could have been gained from bi or tri-weekly meetings instead of the two we did have over the multiple weeks of development.

Virion turned out as well as it did because of good project planning, documentation and each of the team members working to make the project as success. While it may have run some rough ground in the early stages of planning, the core idea was what allowed us to create the current version of Virion that exists today. Virion was an enjoyable project to work on with a result that has been very rewarding.

Virion and playtesting

So a couple of weeks ago we were given a brief to make a discontinuous game that could be played by two players locally with controllers. For those of you who don’t know what a discontinuous game is, it essentially just means turn-based. Our first idea was confusing, disjointed and as a result kind of difficult to play. We stuck with it for a week before scrapping the idea for something similar, but much more simple and fun. The new idea was a game similar to chess, where two players would face off using 5 different pieces of 3 types, with the goal of using those pieces to capture as much “territory” as they could to win the game. We made a working version of the game in a week, and from the reactions and feedback of the people who came in to playtest, as well as the feedback we’ve had from our tutors, it seems we’ve been successful in creating something that fits the brief and is also very fun.

The playtesting session was very interesting to watch. People were laughing as they played, talking about moves they had made and generally seemed to be having a good time. The overwhelming majority of people who started a game played until either someone had won or a stalemate-like situation had been going on for a long while. Players were able to figure out what to do very easily without aid (some without even reading the instructions) and aside from some very small, minor bugs, the game itself ran smoothly. The feedback we got was also very positive and helpful, and the footage we received of gameplay was for the most part entertaining, and also quite enlightening.

We still have some more work to do on the game so it can only (hopefully) get better, especially now that we have certain knowledge that our game is in fact effective at what we made it to be and people find it enjoyable. The feedback we have received from both our facilitators and playtesters  has also given us a very good idea on which areas to focus on and what to do next.