Tag Archives: playtest

Playtesting UnderMiner v1.1

What This Version Looks Like

Players control a drill that can be steered in any direction using the left and right arrow keys or the a and d keys. The ship moves forward automatically and does not stop at any time. Players steer the drill through a finite area of dirt blocks looking for gold and fuel. Picking up gold contributes to an experience meter needed to level-up. When they reached the requisite gold cache, players automatically level up, which increases their fuel capacity, fully refills the fuel meter, and dynamically expands the map size. Collecting fuel blocks refilled their fuel meter by a little bit. Leveling up fully refilled their meter and increased their overall fuel capacity. There were now two different types of dirt on the map that are effectively the same and just provide cosmetic variety, making the map more visually interesting. There are now magma blocks which drain the fuel when you run into them. Players get gradually faster as they level.

What players didn’t like.

Minor niggles

What they did like

They liked everything. I had to forcibly remove some people from my laptop so I could continue working on the game because they kept replaying the game, trying for a higher score. I have watched people play copies of my game during classes instead of paying attention to the instructor. I think it’s at a good point and will be turning in this version for a grade, though I plan on continueing to develop the game under a different title for eventual commercial release.

Playtesting UnderMiner v0.1

What is UnderMiner?

At the most basic, UnderMiner was fairly simple.

The player controlled a drill that they could steer in any direction with the left and right arrow keys. They held the shift key to propel the drill forward, and could only turn the drill while moving. You had a fuel meter that slowly drained as you moved, but not while you didn’t. You dug down into the ground from the surface, collected gold, and went back up to the surface before you ran out of fuel. While on the surface, you could upgrade your ship granting a larger fuel capacity so you could in turn drill for a longer time and gather more gold in order to level up more etc.

What was liked

People were mildly entertained by the tunneling around.

What wasn’t liked

People didn’t like that they had to go back up to the surface to Upgrade the ship and refuel their fuel. They also wanted more stuff to dig through.

What I Did

For the next version of the game, I planned to implement on-the-fly upgrading and more variety in the map of blocks to mine through, along with minor graphical updates.

Playtesting TowerOffense v2

New Since Last Version

I had implemented a signpost system in order to govern the movement of units indirectly. The way this worked was fairly simple in concept. Signposts were placed in various predetermined points around the map. Each signpost could be faced in up to all 4 of the cardinal directions, and when a unit comes to a signpost, it would continue on in the direction the signpost was facing. So if a unit going north came to a sign pointing west, it would turn and go west until it ran into a signpost that told it otherwise.

Play would then be about strategically manipulating the path of the units via the signposts in order to avoid death, destroy enemy units, and complete mission based objectives unique to the story map.

What people liked

People really liked the concept when it was described to them, and they liked it when they sat down and started fiddling with the signs and watching the units go off in various directions

What people didn’t like

The game was still pretty boring, with people losing interest after a couple minutes.

What I did.

Ultimately, I decided that salvaging the project in the time remaining in the term was a task with diminishing returns. I instead went with a simpler-arcade concept instead called UnderMiner.

Playtesting TowerOffense

While I don’t have the actual game up to playtest standards, I was able to sit down with a chess board and random game pieces and explain my game concept to people. I did this before I started actually building the game in order to ascertain a few things first; 1) whether the concept was simple enough to execute within my given time frame, and 2) whether people thought it would be sophisticated enough to keep them interested, given its needed simplicity in execution.


The concept was thus: A Defense of the Ancients-style game approached form the Tower Defense angle instead of form the Real-Time Strategy angle. Instead of focusing on the hero units and controlling them RTS-style, you’d be focusing on the base and towers, micromanaging them Tower-Defense style.


People were interested in this take on the MOBA genre, and thought it had merit. They were general intrigued to see how I handled it, and thought the idea neat. It was pointed out that there would probably be some issues in keeping the player interested in anything beyond their corner of the game map, and that if I wasn’t going to have heroes going out and farming I was going to need some other form of resource acquisition.


Several things were suggested to solve these two problems.

  • Some form of territory acquisition, wherein the goal was not specifically to defeat the opponent’s base but instead take over the board via control points of some sort.
  • Gathering resources in a style similar to Plants Versus Zombies, where resources would randomly appear about the map and the player would need to actively keep an eye out for them and click on them to gather.
  • Having to manually build and maintain the towers, making you continually check all the lanes and perform routine upkeep on all your structures.
  • Having a type of unit, not a hero, that you could send out to explore the map, uncovering it fog-of-war style, revealing resource points and new lanes to send units down and build towers next to.

Of these ideas I decided the simplest to mock up would be the Plants vs Zombies style click-to-grab resources and have begun on implementing that at present time. If it doesn’t work out, or even if it does, I may look at some of the other suggestions and have a go at how they work out as well.

Playtesting Gathers No Moss ~ Maze Edition

For the next go, I got rid of the traditional controls and instead had you manipulate the pitch, roll, and yaw of the stage itself, leaving the movement of the boulder to gravity as you jostled about the level. I then added a 3d maze that you would manipulate to get the ball through. The coins were still present, but now just served as a signpost of how far you’d got, as if you fell out you restarted at the last checkpoint.


So, there was now more to the game. It still had that relaxed feel, but you were now actually doing something semi-challenging, with risk and reward and chance of failure. It was a more engaging game and with a little work could make a decent time-filler.


The art. Now that people weren’t complaining about lack of things to do, the fact that the game didn’t look as good as early Nintendo 64 games was beginning to be a detriment. While I was familiar with 3DSMax and Blender, they frustrate me and I couldn’t work well with them at the time. Add to that that, in addition to any advanced modeling I might have to do, I would also need to create nice-ish textures and bump maps, and I was looking at a problem.


It was suggested that I move to a sprite-based game, as pixel art, if done right, was relatively easy to produce and could look rather nice if the appropriate amount of effort was afforded. At this point, I scrapped the rolling boulder and began brainstorming 2d sprite-based games.

Playtesting Gathers No Moss

The first new idea I started for a solo project was a Boulder with a smiling tiki face that you could roll around an island and collect gold coins. I booted up unity and had that concept more or less finished after a day, though it looked a bit rough around the edges, all the functionality was there; boulder, coins, island.


It was nice and simple. You rolled around the island, picking up coins which were layed out in a path. The music was light breezy and unity’s swaying trees and rippling grass really added to the feeling of the sandy secluded palm-tree island. The coins were nice and shiny and particle effects made nice touches when you grabbed them. The game gave off a nice relaxed feeling.


There wasn’t anything else to do. The game was too simple. After you’d gathered all the coins, that was it. There wasn’t much point in continuing to roll around the island.


Add more to the game. At this point there wasn’t much to it.

Playtesting Knight to E7 ~ the Tower Defense

Our game was at one point a tower defense, not unlike the Zombie Bowling mode of Plants vs Zombies. You picked and sent out chess pieces instead of walnuts, and incoming enemy pieces streamed at you from across the field.


Players enjoyed the chess theme, as before. They also enjoyed the fact that you picked one side, black or white, and stuck with it instead of switching sides.

Playtesters also enjoyed that each of the pieces had their own distinct movement patterns as they traveled across the board towards enemies.


Players didn’t like the speed of the game. With the chess theme came a preconception about slow-paced, or at least stilted paced, strategy and tactics. This type of game had neither.


It was suggested that the enemy pieces be slowed down and move incrementally. The Knight movement pattern was also confusing to players. It was suggested that we put guide arrows out for all the pieces to show where they would go. This would help clear up and confusion about all pieces, not just the Knight.

Playtesting Knight to E7

For awhile the main concept of the title I was working on, Knight to E7, was thus; you, as a lone knight on neither the black or white sides, would go across a randomly generated board, hacking and slashing your way through a maze full of enemies Gauntlet style. You could attack both white and black pieces, and would gain benefits against a color by attacking it more, effectively making the other color your allies. There were special bonuses for attacking whatever color was your ally, giving an incentive to attack both colors instead of focusing on just one.

We asked a group of players (students at DigiPen) to test this concept.


Players enjoyed the Chess theme. It was more cohesive than the random shapes we’d had previously and added a lot of preconcepted depth to our enemies and world in the players’ minds.

Players really liked the ability to effectively pick a side, gaining bonuses against the opposing faction. It gave them motivation to help out allied pieces and attack enemies as they moved through the maze instead of just sneaking around. THey liked that the more you attacked your enemies, the better you got against them.


Players didn’t like the fact that you had to attack your allies to heal. One playtester went so far as to die on purpose when she found out that that was something you had to do to survive. She and two of the other 7 playtesters turned the demo into a survival mode competition; ‘how long can I survive before I die?’

While we implemented the chess theme for ease of model production and animation reasons, players came to the table with a lot of preconceptions about what the game would be about given the chess theme and were somewhat confused when these didn’t follow through.


It was suggested that we incorporate the option to stick with a color and not have to switch and turn on your allies.

Playtesting Karma

Our original game for this term was a standard Diablo-style hack ‘n’ slash, but with a karma system that was implemented in a similar manner to the duel-color system of Ikaruga. The main character could switch between being black and white and would receive benefits and detriments against enemies of corresponding and opposing colors, again like Ikaruga, but applied to a Diablo-style game.

We set about playtesting this simple concept. We had the main character as a circle in our demo and all the enemies were squares of varying size. The player could click their way around a large flat map that had random enemies spawning at random points. We were, at this point, just testing the core click-to-attack and change karma alignment.


The players we tested this with (being my brother and a couple of his friends) liked the idea at first. They enjoyed clicking to attack things and got into the groove of meandering around the board killing things.  Enemies came in waves from random locations. Each wave was made of one solid color of enemy, so the players only had to switch karma every now and then and continue attacking.

They enjoyed the simple two button interface (left click to move/attack, right click to switch karma).

Some of them said that they would like more to be in the game world, but understood that we were just testing the mechanics at this point.


After a good couple rounds of feedback, we adjusted the demo to generate enemies of random color instead of waves of enemies of a solid color. The demo was now throwing black and white enemies randomly at all times.

Players grew frustrated as they continued to have to rapidly switch back and forth between karmas, which interrupted their hack ‘n’ slash enjoyment they had before.


They suggested sticking with the waves of enemies, or at the very least having a ‘less random’ dispersement of enemy coloration. Otherwise, they thought the concept was pretty solid.