Testing Readapt With Friends

I’m really glad I decided to set a date to test Readapt with a bunch of friends. Since the game is a local multiplayer game that supports 4 players I knew it would super useful. I managed to polish off the short list of features and fixes I mentioned in an earlier post which I am pretty happy about considering I spent nearly two whole days restructuring major parts of the player scripts.

 

Having said that it was still a mad rush to get what I wanted done, I did finish adding things around midnight the night before the Saturday test session but unexpected bugs persisted. Those bugs included not being able to navigate within the pause menu, missing sound effects and not being able to restart after someone had won. So the morning of the test session I had a small list of bugs (that I knew about) to fix before I had to leave for the testing session which was held at a friend’s house.

 

Conveniently I have a group of friends who all more or less live in the same area which takes about 40 minutes with traffic to drive to, so it made sense to hold the session over there. All up I had 12 testers (including myself), so I decided to hold three 4-player session around 20 minutes long, I would take notes for the first two and play against three others in the last session. After each test group finished playing I would ask my friends to write down what they liked, didn’t like and any suggestions they might have.

Disclaimer I didn’t take any photos so this will be a giant wall of text. Sorry!

Within the first round I realised that the game might be too confusing as my friends spent half of the round figuring out what had randomised and how to leverage what they figured out. This also involved a lot of laughing and screaming at themselves and others, along with a handful of  “Aha!” moments. Early in development I had considered surfacing what had randomised in each round but I thought it would make the game too easy. The feedback I got told me otherwise. While players enjoyed the novelty and variety presented by the game, being confused in a combative and competitive scenario for too long is not fun. I think it was easy for me to take for granted the amount of confusion I would be inflicting on new players. since I know the game inside out.

Prolonged confusion is not a fun state to be in, which is why getting lost is always a bad time and the primary reason why I hate mazes. So I’m thinking of signposting major things that change at the start of each round like weapons, abilities, players, boundaries and environmental objects. I’ll also include an option or a “hardcore” mode where such a feature can be turned off once players become more familiar with the game or want more of a challenge.

Feedback also pointed to some information that was not visually represented well enough. The boundaries that border the screen often have properties but were too thin and not noticeable enough. In addition when players were on one health it was hard to see the player sprite. Another point that came up was that it was hard to tell if players were still alive as there is no death animation, a player simply disappears and a sound effect plays. I think that these issues arose because I developed these aspects on a computer monitor sitting less than a metre away while the game was played on a TV with people sitting a few metres back on a couch. So I’ll have to make visual cues including death animations and who won each round more obvious in future builds.

There were also some balance issues which I found interesting. One weapon is chargeable by holding down the fire button, the charge time is increases projectile size, duration and speed. You can also not choose to charge the weapon at all which fires a small projectile, the problem was that at the time a small projectile would cancel out a fully charged one. Obviously this lead to some serious balance issues as my friends quickly exploited this fact and that I had not implemented a slow rate of fire (as I thought that most players would spend most of their time charging) which lead to everyone shooting all the time. This issue was made so obvious and so quickly that I was a little embarrassed! The AI I coded to use this weapon would pick a random float number between 0 and the maximum charge time, so it would rarely shoot successively without charging at all. Thankfully the solution was rather simple, I’ve added a cooldown period between shots and made larger charged projectiles destroy smaller projectiles but not themselves.

Oh and there were a bunch of bugs on the day too. The ghost ability which lets player move through objects would not restore the player colliders properly, player one’s score showed up on all characters, input for player 3 was broken for one particular modifier which restricted movement to a path and one of axis of movement was incorrectly inverted for player 3 too. Despite this the game was largely playable and most importantly it didn’t freeze or crash and as one of my friends put it “was more stable than Battlefield 4”. I expected some bugs since I added, restructured and fixed so much code that it was pretty likely I would miss things or make mistakes.

Some of my friends suggested power ups to pick up which I am a little on the fence about. From a design standpoint I like how players are on equal footing despite the randomised elements as they are applied equally. Adding power ups would skew this balance but I could use it to encourage players to actively move around instead of hanging back.  I also noticed that some of my friends talked to each other while filling out feedback sheets, which lead to some repeated feedback. So I’ll probably have be a totalitarian dictator and impose silence among testers next time.

There’s more feedback that I could discuss but this post is already super long.  Next time I should also record my friends playing so I could re-watch gameplay footage in my own time. In other news I recorded another episode of the Should I Play This Game Podcast on Sunday, which has our first email ever and benefits from my new mic. I was pretty tired at the time though, so I apologise if I seem off-point or sleepy. The podcast is already up for your listening pleasure so you can download it from the website or find it on iTunes thanks to Mike’s speedy editing. For the next week I’ll be working with the feedback I have gotten so far and I aim to put a build out next week so you guys can finally get around to trying Readapt for yourselves.

 

Advertisements

SIPTG Podcast Is Back!

As promised I would make a short post when then new episode of the Should I Play This Game Podcast is up. You can find us on iTunes, subscribe to the RSS feed or download each episode straight from the site. We also have a Facebook page and a Twitter account that you can follow for regular updates. This episode is our longest yet as we catch up on the last 3 weeks.

Thanks to everyone who has tuned in so far, the audio quality will improve as we look into different solutions to improve it. Audio quality on my end has been a bit dodgy and arguably the worst of the group as I was using an old webcam to record.  The good news is that my new mic arrived (from Amazon because Australian prices are criminally high, even accounting for postage!) so I should be a lot clearer from now on. Expect another episode in a week, you can ask us anything via email and we will answer them near the end of each episode.

Redundant Code Is the Enemy

This will be a pretty short-ish bare-bones post as I up to my neck in cleaning up my code, double checking everything whilst trying to put more stuff in I’ve set myself a few short term deadlines and goals in order to focus my efforts in the near future. Coming up this Saturday (only 4 more days!) I am doing a testing session at a friend’s house (no one lives near me). So far I have 8 victims/volunteers, which hopefully should grow as the day approaches.

While I have had a singleplayer test/practice mode in the game for sometime the game is designed around people playing against people. It’s hard to emulate how a normal person reacts in simple code and some randomised elements don’t effect the AI at all. While I’m not saying it’s not possible, it’s just not feasible because I am not an expert in AI. I know this sounds rather vague and roundabout but hopefully when you do get your hands on the game you will understand what I mean.

So far I am on track despite having to restructure large parts of my scripts. When I started making a prototype build for Readapt I only had two player support and about a half-dozen random modifiers. I also had a specific scripts unhelpfully called “Player” and “Player_2” one for each player, which contained code responsible for movement, weapons, abilities and movement. Suffice to say when you have four players, each with their own unique and massive script troubleshooting code and implementing new content is a pain.

In the last day and a half I have managed to generalise the player script, so each player refers to the same script. This means if code is bad it should show up on all players, instead of being specific to one player. I also divided the player script into smaller scripts, the original player script still contains all code relating to movement, score overlay, hp overlay and collision detection. However, weapon and abilities have their own scripts which again are scripted to work on all 4 players.

So what does this all mean and why did I bother? There is like 30% less code, less redundancy and scripts are better organised. This will mean less time scrolling around in code and actually coding. It means that I only need to implement things once and test them once, instead of four times. Why didn’t I do this from the start you may ask? It had occurred to me earlier when I was prototyping, except my skills in C# and in Unity were even more rudimentary than they are now and were simply not up to the task. I am still learning as I do everything more or less for the first time. At times things can be a bit daunting but I enjoy the process of learning which I find pleasantly addictive.

That’s it for now, I recorded another podcast episode last Sunday and I’ll blog again when it’s up. I’ll probably post about the upcoming testing session afterwards too. I aim to implement the feedback and more content in the following week and if all goes well I’ll put a public build out. I hope the game holds up, doesn’t crash, bug out or catch on fire.

Wish me luck!

Thoughts On A Game Dev Talk, Protodive And A Comic Legend

Phaw, that was a week already? Man that went fast. Contrary to what I said in one of earlier blog posts I couldn’t resist adding a bit more content to my game. I know, I know, it means that I have to push the public test release a little bit back but on the upside it will also give a little more for players to test and give feedback on.

Projectile Trail
I added projectile trails during the week (not to mention other top secret things) which gives a better indication of direction and speed. It took a lot longer than I expected, as drawing dotted lines ( or any lines for that matter) in Unity 3D is not easy and required using a store asset that I bought called Vectrosity.

Aside from my usual business, I managed to attend a “post-mortem” game development talk about Puzzle Retreat which was held in the city. The game is a puzzle game for smart phones, created by Voxel Agents, a local indie developer who are most well known for their Train Conductor games. They shared some interesting insight to what worked and what didn’t, with the added benefit of hindsight. The game is free, revolves around simple rules and includes 60 puzzles, which meant a low barrier to entry and as a result, over 3 million downloads. They also showed off some of the development tools that they built from scratch which enabled them to create new puzzles quickly. One tool even showed order of moves for a solution and report number of possible solutions as the puzzle was being made.

Unfortunately their free to play model, which sold additional puzzle packs for a few dollars, was not attractive enough for most people to convert into paying customers. Another point was made about metric data and how too much non-specific data collecting can be a nightmare to make any sense of. Big budget developers can devote entire an entire division to player metric data collecting and analysis but the sheer scale of that endeavor is too much for most indie developers. Instead player data collected should be on focused and targeted queries.

While the talk wasn’t specific to my efforts (as my game is intended for a different audience and platform) but it was interesting to listen and learn from another game developer. Aside from that I did more legal and business-y research and finalised some paperwork. I have decided that while my game will be firmly attached to my name, it is sensible to setup a small business for tax purposes. I decided to call it “protodive” which means, quite literally: first dive. To me it describes the moment when you jump into something for the first time and the excitement that comes with that. Such a description applies to my current line of “work”, when I play a game, read a book, listen to a piece of music or experience anything new. I am a big fan of the open world RPGs, particularly those crafted by Bethesda Studios and I’m always super giddy on the first play through.GenieIn other news, it was sad to hear of the passing of Robin Williams, I am a big fan of his work (Good Will Hunting is still one of my favourite movies) and I love the hell outta his Genie in Aladdin. I can only offer my condolences to his friends and family. On a related note if you are or know someone who is depressed please seek professional help or talk to someone about it. Depression sucks but always know that others struggle with it and cope with it, more often than not with the help and support of others. 

On happier news, the Should I play This Game Podcast will be returning from our 3 week hiatus. We will be recording a new episode this Sunday night and a new episode will be out soon, which you can find on the website (link on the right) and subscribe to on iTunes. I’ll probably update the blog with a small post when it’s live. Until then I’ll be busy getting my game up to testing standards (I still intend to put it up on IndieDB and the TIGSource forums), you can follow me on Twitter @thephampire and watch this space for future updates.

UI is not Dead Space

User Interface, no doubt a riveting topic for another blog post. Wait don’t leave! UI is rather important. When done poorly the user will struggle against it and when done well the user might not notice it at all. Ultimately UI is a means to convey critical information to the player. This can range from: how much health the player has, direction of threats or simply navigating through menus.

The Dead Space games are a paragon of excellent UI design.  For those unfamilar with the series it’s a third person shooter with a survival horror element and is set in various fictional space ship environments. I highly recommend the first two entries in the series, the third one not so much. So why is the UI so neat you ask? Simply because it is both extremely functional and unobstrusive.

The health bar is built into the spine of the player’s space mining suit, when the player aims a display appears on the weapon showing the ammo level. Even the inventory is immersive, which is projected from the suit as a hologram without pausing time. You can check out in-game screenshots below.

1468865-deadspace2_gc1
Screenshot showing the ammo counter on the weapon, health bar on the spine, the numbers indicate seconds of oxygen left and the semi-circle bar represents energy levels for stasis powers.
inventory_2
Screenshot showing the projected hologram inventory which will move and rotate as the player does. Issac (the player controlled character) will even turn his head to look at it.

Cool huh?

The lead UI designer Dino Ignacio wanted the UI to be diegetic, you can read a great interview with him here. The Dead Space UI is awesome because important information was all told in-game while the game was happening.

I thought this was relevant as I have tried to implement UI in the same spirit. Earlier iterations of my game showed player scores via text at the top of the screen. Now score is represented visually on the player sprite itself.

score ui
Screenshot showing the current scoring system, a corner is filled in white from the bottom left in an anti-clockwise direction, when a player reaches a winning score of five a centre pattern appears, making it obvious who won.

On the other hand I had a pretty clear idea from the start on how I should represent player health  which hollows out the sprite as damage is taken.

From left to right a player with 3 health, 2 health and 1 health. When the player dies the sprite disappears entirely.

The traditional way of displaying health would usually be a health bar at the top of the screen or just above the player sprite. I think my method is a little better in conveying the same information in a less obtrusive fashion. All the player specific information is found on the player itself: health, score (and who won), player number (via the pointer shape) and direction the player is facing.

Anyone who has played video games will tell you that your focus is rather specific and information on the periphery is likely to be ignored. This is especially true in non-turn based action games where the focus is centered on the player being controlled. So I think it makes sense to have all the information visually represented on the player which can be read without taking an eye off the action.

I’ve been busy redoing menus, adding content, getting paper work done, looking into adding trails to projectiles and the usual bug fixing. I also went to a friend’s wedding on the weekend where I got to talk to another developer who recently released their first game. It’s a grid based puzzler called Randy which is available on iOS devices.

That’s about it for this week, a public test build draws ever closer. I’ll finish up adding modifiers for now and add in missing sound effects so you guys can tell me what you think.