About QuestionableQuality (twitter: @CantGetOurName)

Makers of games and other questionable riff raff.

Entries

 
Ludum Dare 37
 
Ludum Dare 36
 
Ludum Dare 35
 
Ludum Dare 34
 
Ludum Dare 33
 
Ludum Dare 32

QuestionableQuality's Trophies

Youtubed!
Awarded by BackslashYoutube
on December 24, 2015

QuestionableQuality's Archive

Síofra: A Post-Mortem

Wednesday, April 20th, 2016 8:12 am

CgW_SLUWsAEFntz

Ludum Dare 34 was my first ever gamejam and in-turn my first ever completed game; working with all of the members of Questionable Quality (four at the time) we made something fun, addictive, and different to the LD35 project: a game. However this time around- Ludum Dare 35- we only had two of our members: myself (the artist) and Matt (the co-director). We had less manpower to get more done. So the question was: what could we do?

P.S. I would recommend playing the game here, as this contains spoilers.

(more…)

Scaring 9 to 5 – Post-Mortem

Tuesday, September 1st, 2015 10:49 am

Play the game here

Initial Design

Our discussion began with ‘Monsters, inc.’. We liked the idea of scaring being the daily grind and removing any horror aspects of the game going down a more ‘Theme Hospital’ route. We then continued the discussion along this path and decided that in place of a hospital we had to start with the classic haunted house. You would collect screams to sell and use the money to buy more scare props to set up in the rooms.

This was all sounding great to us but we started to think it may be a bit out of scope for 72 hours, so we tweaked it to have static props and map, but the player had to manually set off traps while avoiding being seen (he was too adorable to scare and nervous as it was his first job). This would also make the gameplay a little less ‘tower defence’ and make the game feel more dynamic. What could go wrong?

IMG_0492

Final Outcome

Due to poor planning we ended up having to remove the stealth aspect of the game, which meant the player in the world was slightly redundant so we also removed him.

FullSizeRender

What we were left with is a game where victims (teens) look around the house, where you need to scare them to earn points. Using the correct theme to match a victim’s fears will gain extra points and increase their fear level. The points you get are relative to the players fear level (which increase the more you scare them, till they run away) and whether or not you match their fear. When victims have seen all the rooms they will leave, the aim is to have as many points as possible before they all leave.

The Good

Screenshot (4)

  • Visuals – The game makes good use of post processing effects to create a distinctive art style and make the game stand out. An effect we’re very happy with is our funky (scaling) walls, while primarily there to benefit the players’ view of the game, they give the house an organic feel which really brings it to life.
  • Playable Game – Ignoring any quality issues we still produced a playable game that suffered from very few bugs and none that were game breaking. While it’s a small accomplishment we’re always pleased that we were able to produce something that works (compiles, is playable etc.).
  • Social Media – This isn’t quite related to the game we made, but as a fledgling company we are always trying to improve our social media presence. We managed to get a decent number of impressions as well as some new followers (we love you guys, are you reading this? Hello?). In addition to this it’s also more data for us to use to identify the best way to communicate using social media (in this case twitter).
  • New Tools – In this Jam we used two tools for the first time: Mixamo Fuse and ProCore’s Prototype. Both of these ended up providing results we were happy with as neither of us are 3d modellers. While it take a little time to get accustomed to the software it’s always nice to use a jam to experiment with a new set of tools.

The Bad

  • Priorities – We started off well and quickly agreed on the core concept for our game, however from there we didn’t prioritize the task required well to meet an MVP (Minimal Viable Product) or in a manner that would allow us to easily cut content that wasn’t core to our concept. This ended up with us not having a playable game until the final day, at this point we then had to cut other gameplay content leaving the game a little bare and with very little time for testing and tweaking. As we have suspected this has been mentioned in early feedback that both gameplay elements are light and user feedback needs improving.
  • Gameplay – This is pretty a simple one to evaluate, as mentioned above it is too light on gameplay elements and what the game does contain is not well communicated to the player. The initial design felt like it had a lot more substance and potentially we ended up removing the wrong elements from the game in order to get the game done in time.

 

And The Conclusion

Having looked at what we made and all the feedback we have gotten (thanks guys), we’re actually quite disappointed with the result of this jam. We have have discussed internally what we feel we need to change and it seems the consensus is that we need to prioritise gameplay over everything and really double down on it. We’ve seen a few comments along the lines of “looks cool, but I have no idea what I’m doing.”.It’s great that people like the visuals, but we’d rather be seeing “super fun, but looks a bit dodgy.”.

With that in mind we plan to implement some hard rules in our next jam and identify an MVP and then the stretch goals beyond that. The MVP will only have white boxing or primitive/representative art so that we can focus on gameplay. As a studio we’re currently looking for an artist, so potentially resolving that problem may help us better divide and organize the tasks out in jams.

That was a little bit doom and gloom, while we’re disappointed with outcome we still loved the process, and it’s been really awesome to see all the games everyone else has made and special thanks to everyone who played and rated the game (especially all that gave feedback).

 

[cache: storing page]