Email Questions to the SIPTG Podcast For Steam Giveaways!

Just a short friendly remainder that I still do the weekly podcast about all things video games with Mike, Graham and Steve. We cover what we have been playing, video game news, upcoming games and answer email questions. There is a permanent link to the site on the right and you can always subscribe to the Should I Play This Game Podcast on iTunes.

In attempt to entice some more emails Mike is giving away Amnesia: Machine For Pigs, Jazzpunk and Risk of Rain via Steam.  So get your emails in! You can reach us here, we always love hearing from listeners and will read and answer absolutely anything! Got a video game related question? Email us. Got a non-game related question? Email us. Do you just want to tell Steve he is a terrible person and Super Smash Bros. is real fighting game? You know what to do.

Aside from that Graham recorded an interview during PAX Australia with developer Robert Weirdt about their upcoming game Metal Dead Encore which you should also check out.

We are also planning to do a special end of year wrap up including our Game of the Year lists so stay tuned for that. That’s it for now, we hope to hear from you guys and gals!


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.


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!

Should I Play This Game Podcast

I’m a big fan of the guys at Giant Bomb, I’ve read and watched the hilarious yet informative stuff they have been making for years, even since the old Gamespot days.  My favourite weekly feature is without question the Giant Bombcast which you can find on their site and on iTunes. Over a month ago while browsing the forums I came across a thread asking about people in Melbourne interested in doing a podcast about video games. Sign me up! I enjoy podcasts, I listen to them while I’m working on my game or when I’m playing a game that has some down time, like Hearthstone.  Michael organises, hosts and edits the podcast, while Graham, Steve and I just show up and talk about anything remotely related to games. We have managed to record two episodes and we even have a website where you can listen to episode one. Like right now. Apologies if the audio quality is a bit average, we are looking into proper audio equipment sometime down the track (except for Graham, he has a nice mic). After episode two we will be taking a few weeks off and then we will return. In the meantime send in your questions via email (they can be about anything) and we will answer them near the end of each podcast. Oh I forgot to mention that Steve, our resident fighting game expert, thinks that Super Smash is a game for babies.