PixelSense40k

Project Final Report

Kyle Yasinski (1607781)

December 19th, 2013

Project Supervisors: Brian Brookwell & Indratmo

Abstract

Warhammer 40,000 is currently one of the most popular miniature wargames on the planet. Originating in England in the 1980s, it is enjoyed by players worldwide. The game requires much strategy from it's players, forcing them to pit themselves against one another in endless war. The Microsoft PixelSense, is Microsoft's "Touch-Sensitive" tabletop computer, which is known for it's capabilities and ease of use. In combining the two, the author hopes to advance Warhammer 40,000 into the 21st Century by allowing the PixelSense to do all the heavy lifting, like distance measurement, score calculations, and dice-rolling. However, the limitations of the PixelSense, and mistakes on behalf of the author, ultimately prove to hinder the development of such an advanced game.

Introduction and Background

Warhammer 40,000 is a miniatures war game. This means that it involves the players moving miniature figures, representing soldiers, across a mock battlefield in an attempt to complete a certain objective, either holding a position, capturing an ancient relic, or simply wiping the opponent from the face of the galaxy. This is much simpler than it sounds. Each unit has it's own "stat line", where that soldier's defining characteristics are listed, such as their physical strength, how quickly they can move, or how many shots they can take (Glanfield, 2012). The player is in charge of keeping track of this stat line for each of his soldiers, as well as remembering any "special rules" a specific unit may posess. He is in charge of making sure his units do not move too far during their movement phase, who has shot and who hasn't in the shooting phase, and which units may be engaged in hand-to-hand combat with enemy forces during the assault phase. Suffice it to say, this can get very confusing very quickly, with some games requiring an army of over one hundred units.

Not to mention the fact that with over 10 opposing factions to play, each with dozens of unique soldiers that can be fielded on the battlefield, a new player can get very lost, very quickly (Glanfield, 2012).

Fig 1. A squad of Chaos Cultists from Warhammer 40,000 (Source:

The Microsoft PixelSense (originally the Microsoft Surface, before that name was bestowed upon Microsoft's iPad competitor), had it's original version released back in 2007. It is a touch-capable device, mainly intended for use by multiple users in public settings, mainly for information gathering (Fried, 2007). However, the PixelSense can utilize a special printed object, known as a ByteTag. These ByteTags allow the PixelSense to identify an object by reading the hexadecimal value that is printed onto the tag (Microsoft, 2007) .

What if this ByteTag functionality were used for Warhammer 40,000? As such, the PixelSense would not only be able to keep track of where units were currently moving, but would also be able to do any and all calculations on the back-end, without direct input being required by the players. Some attacks in Warhammer 40,000 can require the player to roll 40 dice simultaneously. By utilizing PixelSense, not a single dice would need to be rolled for the users to be able to play the game. All that would be required from them would be to decide where they are moving, and whom they are choosing to attack, thus simplifying the game for users new and old alike.

Objectives

Due to the massive scope involved (not to mention the number of distinct ByteTags that would be required) in order to make sure that every unit of every faction available to the players would be able to function properly with the PixelSense, I decided to massively cut down the scope of this project to a single box of models: the "Dark Vengeance" Starter set (fig 2).

Fig 2: Warhammer 40,000 – Dark Vengeance Starter Set (source:

By trimming the roster down to just the Starter Set, I was able to limit the number of required "units" to be programmed to just 49 Miniatures. It also ensured that the combinations of units for each faction were set, allowing the program to only have to work with two set, unchanging armies. The other benefit of "scoping-down" to just the starter box is that the Starter Box also contains simplified rules as opposed to the main game, and these simplified rules also remove some of the more complex weapons features and character special rules that would otherwise likely become an issue during project development.

Finally, despite the fact that the game would be working only with specified armies and would already be utilizing simplified rules, the final feature of Warhammer 40,000 I would have to remove from my scope is Terrain. Terrain encompasses anything that would be found on the battlefield that is not either a soldier or a vehicle. This may be a strange forest, an old crumbling wall, a dilapidated farmhouse, or a military stronghold. The problem that terrain would have caused for the game would have been that, in Warhammer 40,000, most models are capable of either climing on top of or entering pieces of terrain. If that were capable in the PixelSense version, the table would have lost track of any ByteTags located on or within the terrain pieces, thus rendering any ability to attack, defend, or check range from those points entirely impossible.

Development

The initial task I had to complete was to simply get the PixelSense to recognize each individual model. This was a simple enough task, in that all it required from me was to create an array of different units, sorted by their respective tag value, and have the program reference that unit whenever that specified tag would appear on the PixelSense. I made a simple visualization for the unit that would display an image of that unit, as well as it's name and statistics (Fig 3).


Fig 3: Unit Visualizer running on the Input Simulator in Visual Studio

However, it was here that I first noticed an issue. While on the input simulator in Visual Studio, the program was capable of displaying all 49 units simultaneously, on the PixelSense itself, the imaging device was only capable of displaying around 20 or so tag visualizations simultaneously. This would create an issue for later on, when actual gameplay was being developed, as all of the scenarios in the starter box require upwards of 20 units in order to play. I developed a workaround by "locking" the units in place. When a model was moved to a desired location, the user would then press a button on the tag visualization, "locking" the unit in place. In actuality what is happening is that the tag definition for that model is being removed from the tag visualizer, freeing the visualizer to notice other tags, and creates an identical object to the visualization in its exact position.

In order to properly do movement checking, and in order for the players to be able to visually tell where exactly it is that they are supposed to be moving, Range Circles are drawn which represent the maximum distance that that model is capable of moving. The check to see if the model is still within it's movement range is quite simple: check the distance between the centerpoint of the base of the model and the centerpoint of the range circle. If the distance is shorter than the radius of the range circle, the model is currently located within the circle (Fig 4). If the model is not currently located within it's range circle, an error message is flashed accross the screen.


Fig 4: Models and their Movement Circles and Tag Visualizations

The next step to completion was the formation of squads. Squads had to be easily identifiable as one group, but they also needed to do what is known as coherency checking. What this means is that each model cannot be more than 2" away from any other model within it's squad. The group identification was simple, in that when at least 3 models are placed for a squad, a triangle (in that faction's colours) is drawn between the unit and it's two closest squadmates. As for the coherency checking, that was slightly more difficult. First, the unit which moves or is placed first is not required to be in coherency with anything, as none of it's comrades are currently present on the table. However, a 2" range circle is drawn around him, showing where is fellow units are able to be placed. A new range circle is drawn around each unit, until the final unit in a squad has been placed. At this point, the 2" range circles disappear from the board. If any movement or placement occurs outside the range circle, once again, an error message is flashed on the screen.

Weapons and attacking were the first major stumbling block for the project. Initially, each weapon for each individual unit was hard-coded into the program. However, this lead the unit-creation method to become even more bloated than it already had been. Also, with the sheer amount of weapons being created, (sometimes 4-5 weapons per unit) minor errors and differences between the weapon types would appear, causing logic which would require units of a squad which all own one type of weapon to fire that specific weapon would fail. After fighting with the attack capabilites for weeks on end, I decided to give up on it and start from scratch. The next attempt began with me creating a simple array of all 26 different weapon types, that I would then copy using a simple method that I had created.

However, due to the delays in starting over from scratch with attacking, and some delays involved with squad groups, by this time, it was already time for me to begin my scheduled playtesting. This playtesting would reveal an issue that would almost drag the project to a grinding halt.

Testing Log: Day One

ISSUES

Table recognizing non-existent cross touches when many units on table

When many units on table, window begins to revert to main menu (possibly due to cross-touches)

After initial placement, red cohesion circles not being drawn

able to place unit outside designated movement range.

Whole program crashed when attacking

Weapon select prompt not loading

Movement not drawing proper range circles

BING UNITS

Aside from issues with my code (range circles not being drawn properly, cohesion circles not disappearing, and major issues with my attack logic), the main issue that arose was with the Pixelsense itself. As soon as a certain number of units would be placed upon the table (sometimes as little as 10), the table would begin to behave erratically. This was not noticed in the earlier tag visualizer demo, as there were no button presses or unit placement logic required. The table would begin to see "phantom touches", and believe that touch events were taking place when there was actually nothing aside from the placed units touching the table surface. These "phantom touches" would also tend to deaden whole portions of the screen to the user's touch, and would not allow any tag visualizations to appear at all. By day two, much was the same, save for a few fixes in my code for issues that I had caused:

Testing Log: Day Two

Participants: Alex, Taylor

Units able to move outside of range.

Cohesion Circles now NOT dissapearing after move, occasionally.

Delete back button so Phantom Touches stop interacting with it.

Circles only half-sized

Although some of my fixes had caused some new bugs, the issues of the Phantom Touches and deadened screen still persisted. Unfortunately, shortly after Day Two of testing had begun, so to had Final Exams, which directed my attention away from the project until last Friday. After spending much time trying to find a solution for the deadened screen and the phantom touches, my efforts were all for naught. I held one last testing session last night with my friend and former classmate Steven Lind, a former professional QA tester for Bioware here in Edmonton, and an avid Warhammer 40,000 fan and player. He decided to do his own test writeup, and had the below to say:

As an experienced QA Tester and long-time Warhammer 40,000 player, this software/hardware combo offers the player a new way to approach the game. Warhammer 40,000 is always rife with arguments over distance. This software removes that argument entirely. A unit is either in range to fire at an enemy unit or not. This greatly speeds up the movement phase and shooting phase. The shooting phase similarly benefits as dice are no longer required to figure out what models need to

be removed. In table top 40k, three separate dice rolls are required to determine what models need to be removed. The scores required for these rolls are determined via complex chart look ups. All of these complexities and steps can be removed. This speeds play greatly and lowers the barrier to entry to the hobby.

There were however serious bugs to be overcome. Most of these bugs lay with the hardware. The surface itself has great difficulty picking up more than 20 models. This needs to be overcome as 40k

armies can easily include 100 or more models. If this is fixed, the largest hurdle will be fixed. Also Bing seems to be built into the hardware at such a base level that it often places bing tags beside the models. These tags make the in game tags disappear.The main bug in the software is also partly the fault of the hardware. Distances need to be exactly mapped to real world imperial inch measurements. They currently seem to be scaling slightly wrong. Kyle has stated that this is due to the way the surface specifies/pixel to real world range.

With but a short time left for development, I created a basic scenario, with but a few models, in order to demonstrate what had been completed, as none of the base scenarios within the game would be able to fuction properly.

Conclusion

Many of the issues which arose over the development of this project were my own. The timeline that I set forth at the beginning of the term was quite foolish, such as me leaving but 2 weeks for myself to get the attack functionality down pact, when I had given myself a whole month at the beginning of the term to get simple unit visualizations working. I should have been able to determine that back-loading the project so much would cause it to come into conflict with not only midterms, but major projects in my other courses and final exams as well.

However, the PixelSense in its current form is not at all well suited for a game like Warhammer 40,000. The small size of the table makes games very claustrophobic, and units such as bikes are able to move across almost the entirety of the board in a single turn. The phantom touch issue is a major game breaker, as no game of Warhammer 40,000 takes place with less than 10 units. While in theory the project sounds like a wonderful idea, in practice, it is highly unlikely to produce any fruitful results.

References

Glanfield, Matthew. How to Play Warhammer 40000. Miniwargaming, 2012.

Fried, Ina. Bumps on the road to Microsoft's Surface. Cnet, 2007.

Microsoft. Byte Tags. MSDN, 2007.