Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Devlog 0: How I Got Started

    [03.05.20]
    - Aaron Maus

  • Beans

    (I had forgotten about the subtitle ha!)

    This was a game I made for a jam at the start of this whole endeavor. It was a cross between a visual novel and a puzzle game, where dialog is driven by a puzzle mechanic.

    • Budget: Nice and low.
    • Timeframe: The plan was for a fairly small game, so this was a pro.
    • Technical expertise: Nothing particularly challenging!
    • Familiarity: A little on the low side, as I am not a puzzle aficionado.
    • Flexibility: Not a sticking point with the scope so low to begin with.
    • Desire: Without a strong vision and solid prototype it was tough to want to go on.
    • Vision: I didn't really know what I wanted when I started, and by the end all I knew was that it wasn't it.
    • Is it actually a game: Nope. Not at all. Completely unfun. A friend said to me after playing, "I'm happy you made this puzzle mechanic because now we know it doesn't work."
    • Audience: The niche seems to have a decent base.
    • Competition: The genre isn't dominated in the same way others are, so not too bad.
    • Originality: Original but in a bad way.
    • Improvement: In theory yes, in practice no.
    • Pricing: I think the price would have been right on target.

    This is a great example of why RAPID prototyping is great. The novel puzzle mechanic I created was hopelessly bad. I would have had to make another, and then another and another until I got something that worked.

    Synth Hack

    (The picture in picture is of me tuning the monotron to find next code)

    This was a proof-of-concept prototype I built. It's a complicated lock-picking / safe-cracking game using an external musical device (I played using a Korg monotron DUO, but anything works).

    • Budget: Very small. Excellent.
    • Timeframe: Also small!
    • Technical expertise: Potentially a sticking point, as I had made the prototype for one specific sound source and it would need to be generalized.
    • Familiarity: While I have a surprising amount of experience manipulating audio data, this was still pretty new territory.
    • Flexibility: Difficult to measure without having a clear idea of how a larger game would be made.
    • Desire: I thought it was a really cool concept, but it never pulled on me strongly to expand on the concept.
    • Vision: I had a pretty clear idea of the experience and the prototype confirmed it, but I couldn't see it as a full game.
    • Is it actually a game: Yes, the game was fun!
    • Audience: Most likely very small for a weird alternative control scheme game.
    • Competition: Not a lot.
    • Originality: Too niche.
    • Improvement: It's hard to say with something genre defying.
    • Pricing: I think the price point would have been reasonable for the scope of the full game.

    The two biggest sticking points were that I didn't know how I would expand the demo concept to become a larger full on game, and that the potential audience for a weird alt-control scheme was probably very small.

    Fully Simulated Fencing

    (It was somehow clunkier than it looks, which is a feat)

    This was the original working title that would later become Riposte!, the game I am currently building. I made the prototype on a plane flight based on a pretty stupid idea. The original was a QWOP-esque sword fighting game. It was brutally hard to control in the first prototype (on purpose), but when I made a second version on a whim it turned out to be pretty great!

    • Budget: Delightfully small.
    • Timeframe: The scope started out pretty small, and eventually got even smaller.
    • Technical expertise: I had no experience making multiplayer games.
    • Familiarity: When my friends and I all find the time to sit down together in person all we do is play these types of games.
    • Flexibility: Very flexible. As a party fighting game I could cut the scope 90% and still have a small but satisfying game.
    • Desire: I love playing these types of games and making my own was a big motivator.
    • Vision: I'm counting this as a negative because my original vision was hazy and took several iterations and pivots to get to a good place.
    • Is it actually a game: The first prototype, not so much. The second version was where I knew I had something.
    • Audience: Respectable.
    • Competition: There aren't a ton and most aren't new.
    • Originality: Strong! I have a lot of unique hooks!
    • Improvement: Also pretty good. I knew what issues I had with similar games and at least some idea of how to improve.
    • Pricing: I was confident I could keep the timeframe small enough that a modest price would be okay.

    This is the game I ended up making. The main points in favor were the small scope and flexibility, which turned out to be crucial when it came time to pivot and scale back. In my next post I will dig into the concept of pivoting and what I specifically did.

Comments

comments powered by Disqus