GameDev

Ken Levine GDC 2014

Industry Insights – Ken Levine on ‘Narrative Lego’ [GDC 2014]

Posted on by Stoyan Stoyanov

Intro

In this entry to my Industry Insights we’re treated to an interesting theoretical proposal by acclaimed Creative Director/Writer Ken Levine a veteran of the industry known for his work on the critically acclaimed Thief, System Shock and Bioshock series.

As a disclaimer –  I will inject some of my own interpretation and expansion of the ideas, as this is unavoidable. For the full, original, unaltered content refer to the sources, listed at the end.

Summary

The talk exists more as a starting point for a creative discussion on potential future dynamic narrative systems amongst developers, rather than a pitch for a finished design idea. As such, Mr. Levine is very careful to note that this is NOT the design for a specific game, a product pitch or a specific development plan.

So why attempt it?

  • He discovered that the linear model locks you into always going bigger and bigger and outdoing yourself
  • This gets exponentially more costly time and budget wise
  • You work years and years on a project, ship it, people play through the 12 or so hours of content and that’s it gone – there is no continuous engagement
  • Linearity also puts boundaries between developers and the audience
    • For example, conceits such as the iconic “Would you kindly” only work once
  • It also stems from Ken Levine’s inherent love for systemic games – he grew up playing Civilization games & XCOM

The System – What it is

So, what is this magical dynamic narrative system? I will call it the “Passions Project” and the reason why will become clear as it is laid out in the following text.

It is essentially an attempt to start the conversation on the idea of building a player driven replayable narrative gameplay system.

Below follows a breakdown of some of the key pillars of design behind the proposed system, grouped loosely into sections:

Negatives of Linear Narrative

  • Expensive to make – bespoke, setpiece-centric experience
  • Pieces don’t speak to each other
    • Nothing in the beginning of Bioshock: Infinite speaks to the ending – not on a systems level
    • As opposed to something like Civilization where the “player narrative” is heavily dictated and affected meaningfully by their choices throughout
  • Branching exists, but with limited states and interactions
    • Can be very expansive but always inherently limited
  • Doesn’t fully embrace the unique power of games
    • Namely – replayable and player-driven
  • Can only add ON, not add IN
  • There is naturally a lot of really great work out there (Witcher etc.) but he is seeking a fundamentally different approach

The Traditional Approach to AI

One of the common questions that come up from people unfamiliar with the games industry is “when will game AI pass the Turing test” a question that is fundamentally flawed according to Mr. Levine due to the following faults of Game AI:

  • Simulates a person, not a character
  • Everybody on the planet is bad at that
  • A truly robust solution lies beyond any technology or creative horizon
  • Overly ambitious leads to failure
  • Easy to give up and never even try

Physics Wasn’t Built in a Day

  • It began with simple things – 2D circles, rectangles, 3D Spheres, then moved onto ragdolls, cloth, fluids…
  • Gradual improvement.
  • People weren’t expecting perfection from the start, they knew you had to start somewhere.
  • The key was to know not to model everything – instead focusing on a limited set of believable and impactful things.
  • This same logic can be followed for procedural characters – don’t try and model everything.

The Opportunity

The concept and goal is t create a narratively driven narrative system where:

  • narrative elements are non-linear and interact with each other
  • All narrative elements trigger off PLAYER action
  • Such triggers are generally TRANSPARENT to the player

The Passions System

The core idea of this (somewhat unfocused) section of the talk is to give a practical abstract example of how such a system might work in an actual product.

The setup is simple – 4 villages, each with their own tribe. Within those exist numerous generic NPC’s but the key focus is on 5 “Stars”  – or notable major players. The number is purposefully low as we don’t want to overwhelm the player.

Passions

It is with these Stars that the system really starts to take form. Their overall state and opinion of you is affected by what he refers to as “Passions”. These are the defining traits of each of them, which are systematic variables that are a systematic representation of an actual personality.

Each action in the world will influence each of these Passions for every major NPC and as a result, if done well and granular/reactive enough, you’d end up with a mostly dynamic narrative structure.

Or in simpler terms – the first of its kind truly systemic narrative. By ensuring that dialogue and events in the world are tied to them you’d (in theory) end up with nearly infinite narrative opportunities, entirely based on each player’s countless individual choices.

Specifics

I have purposefully avoided diving into the specifics of Mr. Levine’s examples – not only because they are bog standard fantasy fare of orcs, elves and such – but also because I recommend viewing it in detail on your own. However, I believe that the above is a reasonable summary of the core concept and should be enough to decide whether or not the talk is worth your time.

Personal Opinion

This last section doesn’t really contain any additional content but is rather my take on the idea, being primarily a gameplay/systems designer. As Mr. Levine himself admits, he is not a technical man, and as such this is more of an artist’s vision of how it would work. It focuses overtly on the end result and the magical possibility space it affords, rather than on the actual systems of it (as charming as the graphics may be).

That being said, I think it is a very important step forward for the medium and I am glad that it was brought up as a discussion. He is very much right that it is a broken, inherently flawed system – every first iteration of something truly new is. However, only by trying (and ultimately failing) will we ever improve and I believe that this is a very powerful concept that is very much investing the time and effort into.

For investigations like these, I’d look at older systemic games like the clunky RPG series Gothic or even the Nemesis system in the Shadow of Mordor games. I think even those rudimentary implementations show the true power of something like this. Perhaps a truly systemically driven narrative is impossible but I do believe that you can shift the balance heavily towards it – and end up with a truly special product.

As such, I am incredibly interested to see the development in this and wouldn’t mind giving it a shot myself, if I ever one day end up in the position to work in Mr. Levine’s team – as it seems like he would benefit from some help on implementation 😉

Sources

YouTube

Industry Insights – Advice for job applications: level designer edition [Mike Bithell, 2018]

Posted on by Stoyan Stoyanov

Intro

This is going to be a very short and sweet entry to my Industry Insights series in which Mike Bithell of Thomas Was Alone and Quarantine/Subsurface Circular fame goes over his own advice on creating a good level design portfolio, inspired by his recent search for a freelancer on an unannounced project. This is a rare chance for direct and soberingly honest advice that many aspiring developers will benefit greatly from.

Keeping with the spirit of this series, I will do my best to be as brief and concise as possible, hard as that may be for me.

As a disclaimer –  I will inject some of my own interpretation and expansion of the ideas, as this is unavoidable. For the full picture, always refer to the sources, listed at the end.

Summary

  1. Communication skills are number one priority, especially in junior hires. You can learn almost anything if you’re willing to listen, and you can’t be a designer without being able to explain a position and fight your corner (professionally)
    1. So make sure to spell check. Arrange your CV/portfolio clearly. Show that you can get an idea across (in this case, the idea that you’re fantastic). Show that you pay attention by following the instructions (despite asking for email, he still got a fair few DMs, twitter applications etc.)
  2. Show what you did on games, don’t just offer a softography. It is of course impressive if you worked on a game that is known and even liked, but game dev is a team effort, so you need to highlight what you actually did, and the limits of that responsibility.
    1. The strongest candidates take you through their work history by naming projects and then actually bullet pointing “I was responsible for these specific areas of design in these specific parts of the game, or its systems”. That helps the recruiter.
  3. If they haven’t heard of your game, that presents an opportunity. If you’re just starting out and all your work is student or indie projects, then you have an amazing opportunity to walk them through your process. Some great students presented playthrough vids of their levels.
    1. One idea that wasn’t seen but might be worth a day’s work for any students about to start job hunting – make a GMTK style break down video of a level that was designed. Similar to the dungeon mapping ones – show the recruiter. SHOW NOT TELL.
  4. Be incredibly careful about oversharing personal info before work info. They shouldn’t have to get to know you personally before seeing your portfolio, so keep it fresh and professional. This is in your best interest: they might be a jerk who doesn’t like you immediately…
    1. It’s 2018 so if they’re into your work, they will google you and check out twitter to see if you’re an arsehole before getting back to you, but it’s a risky play to put your personality too far ahead of the work you’re hoping to wow a prospective employer with.
  5. One great tip for students is to share analysis of other people’s levels – one of the best portfolios ever seen included, among other things, a 5 page analysis of why and how rocket launchers were placed in Quake maps. Brilliant.
  6. They’re not going to download an executable. They’re not going to download a mod, a map or anything else at the first round of review. a) It’s slow b) I’m doing this on a Mac that doesn’t support your game c) I’m not logging into steam on this work machine. It sucks, but it’s true.
    1. Time is limited, so make it profoundly easy with PDFs (opens on anything these days) and YouTube/embedded videos. Flash intros are, thankfully, much less popular these days, but bear in mind that you have 5 minutes to earn their attention for another 5 before moving on.
  7. Show debug rendered overviews of maps that were made. In a very big pile of applicant, the ones that did it could be counted on one hand. It’s exciting to see level maps and layouts. A sexy gameplay shot is fine, but it’s more a showcase of the environment artist(s) you worked with. Show the unsexy debug view with spawner gizmos and grey boxed layouts. Show that you’re able to build and pace a space. It doesn’t matter if it’s ugly, for a level designer, it’s the meat of what they’re hiring you to do.
  8. The final one – if you don’t get hired for a job it’s almost certainly not because you were shit.
    1. No single application this time around managed all 7 of the above
    2. He was hiring for a genre you have no experience of
    3. You were second best, but there is only one job

Sources

Twitter

Industry Insights – Let’s Be Realistic: A Deep Dive Into How Games Are Selling On Steam [GDC 2018]

Posted on by Stoyan Stoyanov

Intro

This will be a more bite-sized entry to my Industry Insights series in which Mike Rose from More Robots goes over his own research into sales numbers and trends on Steam. The market of Steam has dramatically changed over the past years, going from a once highly-selective curate market to the current “everything goes” open market that even recently approved it’s first hardcore porn game. In this climate, it is more important than ever to get as much insight into trends as possible if you want to have any chances of succeeding as a small developer. Mike Rose does his best to do the research so you don’t have to – giving ballpark figures that should help with estimating development return on launch.

Keeping with the spirit of this series, I will do my best to be as brief and concise as possible, hard as that may be for me.

As a disclaimer –  I will inject some of my own interpretation and expansion of the ideas, as this is unavoidable. For the full picture, always refer to the sources, listed at the end.

Summary

It must be pointed out that Steam sales are notoriously obfuscated and with Valve’s new API (part of their Steam store redesign) this has further become the case (for more information, refer to the excellent NoClip interview with the creator of SteamSpy) requiring additional effort to squeeze out any hopeful bit of data that you can. Hopefully, going forward this will shift as a mentality, given that for most industries relevant numbers are widely available – from books, through records and to movies. For now, we have Mr. Roses’s estimations – as follows:

These estimates are for the “average” Steam game – eliminating outliers like the increasingly prevalent shovelware and asset flips that are drowning the platform.

In February 2018 the “average” game

  • Sells 2,000 copies
  • Has an average price of $12
  • Makes $12,500 in revenue during its first month

So as a rough revenue estimate (keep in mind this is for a successful Steam game) it’s:

  • 1st Year = (1st Month x 2.5) = (1st Week x5)
  • Or, on average, around $30,000 in first year

Now, that’s not a bad sum but considering the quality and caliber of game that must be released on Steam to have any hope of standing out, it quickly becomes a very worrying picture. For comparison, the average US salary is just under $45k. Not great.

An interesting additional insight is that, somewhat counter-intuitively, people are eager to pay more for games. Most likely, this is due to the flood of cheap, low quality games and the subconscious association with the dreaded mobile market. As a result of this, increasing the price of your game to $10 or more might actually help it sell more, due to user perception of quality.

“If they are asking this much, surely it must be better, otherwise they’d be mad?”

“Why do they think they can charge more?” etc.

In conclusion, I’d definitely recommend giving the full talk at least a quick skim, though most of the insights can be gathered from just the numbers. It is an estimate, a rough one at that, but could prove invaluable for any amateur developers out there subsisting on nothing but rationed ramen and stubbornness.

Sources

YouTube

GDC Vault

Industry Insights – 30 Things I Hate About Your Game Pitch [GDC 2017]

Posted on by Stoyan Stoyanov

Intro

This issue of my fledgling Industry Insights series I will have a look at a highly controversial 2017 talk from Brian Upton from Game on the Rails who is going to go over what he believes are some key mistakes and counterproductive things that trip up people who are trying to pitch to a publisher that he learned over his decades of experience. While many might view this advice as highly anachronistic, given today’s market where reductions in software prices and different distribution methods have transformed the landscape – freeing many from the dreaded publisher chains – there is still a lot to be learned from this. It is harsh and aggressive advice that is not for the faint of heart or those of a particularly delicate disposition.

Keeping with the spirit of this series, I will do my best to be as brief and concise as possible, hard as that may be for me.

As a disclaimer –  I will inject some of my own interpretation and expansion of the ideas, as this is unavoidable. For the full picture, always refer to the sources, listed at the end.

Summary

This talk was mostly delivered as a very rapid fire series of 30 “common mistakes” and some additional tips on what NOT to do when pitching to a publisher.

I encourage even novice developers to look into, even if they are far from the pitching stage with a larger publisher (or perhaps discounting the idea in general) – as there is a lot to learn about synthesizing your vision.

As always, take everything with a grain of salt – this is advice and should be treated as such, not gospel. The text is taken straight from the talk, so expect some controversial wording and aggressive phrasing. Without further adieu:

  1. I don’t give a crap about your backstory
    1. Very important. Don’t present 100 pages of lore before the core concept is defined
  2. I don’t give a crap about your inventory system either
    1. Don’t go into needless details. Focus on the core.
  3. I’m not going to design your game for you
    1. Be expected to answer questions and fill in gaps. Don’t leave open ended questions and uncertainties.
  4. Pillars are not hooks!
    1. They are the essence of the game but won’t necessarily pull the player in
  5. You never explained what the player does
    1. Don’t focus only on the story or other auxiliary elements. Games are interactive. You play them. Focus on that first and foremost.
  6. Don’t use realism to excuse bad design
    1. Just. Don’t. For an example look at the dreadful design decisions behind the ill-fated Bravo Team
  7. You don’t need a framing device if it’s not necessary
    1. Stick to the core
  8. Is it really a game, or just a knockoff
    1. Originality isn’t the most important but don’t just ape existing things
  9. You never mentioned your glaringly obvious tech risk
    1. Don’t forget games are technical products with their own unique challenges
  10. Your proof of concept does not prove your concept
    1. Self-explanatory 😛
  11. Having lots of shitty art doesn’t make it less shitty
    1. If you can’t make good art, don’t have any or hire someone. DO NOT use programmer art. That’s the first impression of your product and it just might be the last.
  12. I can’t tell what’s placeholder and what’s not
    1. Explicitly state this
  13. You polished too early
    1. Again, focus your effort on things that matter
  14. Your sample dialogues suck
    1. Again, first impressions are crucial
  15. You’re pandering to the latest tech craze
    1. Don’t
  16. You just pitched a phone game to a console publisher
    1. This is more common than you’d think
  17. You’re making a Gone Home/Minecraft/PUBG ripoff
    1. “Insert latest fad here”
  18. You want us to negotiate a risky IP deal for you
    1. You should be the one negotiating
  19. I know more about your monetization than your mechanics
    1. Games are a business like any other but this is not a business pitch
  20. You have no idea how much money/people/time you need to make this thing
    1. This is notoriously hard to answer and prepare for, comes with time
  21. You don’t have a team
    1. This is crucial, don’t expect the publisher to handle this for you
  22. Your business plan is based on outliers
    1. Again, plan as best you can
  23. You seem like you’d be a huge pain in the ass to work with
    1. This might seem silly but you deal with people, not robots and that relationship is crucial, especially when projects hit crucial stages
  24. You expect me to know who you are
    1. Have a proper intro and be humble
  25. You’re annoyed that I’m asking questions
    1. This is the publisher’s job
  26. We’re trying to watch the pitch on your phone
    1. Come prepared, don’t ruin a great idea at the presentation stage
  27. You brought a laptop but no headphones
    1. Pitching often happens in loud, public venues so come prepared for this
  28. You’re hungover/drunk/high
    1. …
  29. Don’t trash other games/companies/developers
    1. Very important, respect is crucial in this industry, so is humility
  30. You need to take a shower
    1. Again, harsh but something that sadly needs to be said way too often

The Root Questions:

A) Is this game worth making?

B) Can this team make the game?

 

And for a little sprinkle of positivity, several Do’s:

  • Be enthusiastic
  • Be honest
  • Sell your hook
  • Know your scope

Sources

YouTube

GDC Vault

Industry Insights – Classic Game Postmortem: Deus Ex [GDC 2017]

Posted on by Stoyan Stoyanov

Intro

In this article of my Industry Insights series I will be looking at a very exciting 2017 talk from Warren Spector who is going to go over some key development insights from the development of one of gaming’s biggest classics – the original Deus Ex (2000), which incidentally is one of my all time favourite games. He goes over how the whole inspiration behind the game was to have a cohesive thread of meaning interwoven throughout the development. This, while primarily a narrative conceit, is what helped drive the choices in the game and ultimately creating one of the best immersive sims of all time. Keeping with the spirit of this series, I will do my best to be as brief and concise as possible, hard as that may be for me.

As a disclaimer –  I will inject some of my own interpretation and expansion of the ideas, as this is unavoidable. For the full picture, always refer to the sources, listed at the end.

Summary

This talk focuses goes over a lot of key aspects of the development of Deus Ex and its hour long runtime is far too loaded with development gems for me to truly summarize it.

As such, I will focus on the advice given by Warren that could be applied to most developer’s projects. It is broken down loosely into 9 “guiding design questions” (with example answers) as follows:

  1. What’s the core idea?
    1. Elevator pitch
    2. Example from Deus Ex – “The real world role playing game where players tell their own stories”
    3. Doesn’t need to be too descriptive or unique but should contain the core & soul of the game
  2. Why do this game?
    1. Why? – a simple but incredibly difficult question to answer – think of all angles from creative to business ones
    2. Is it gonna be a hit? – artistic expression is great but so is being able to survive
    3. Is it something you burn to make? – game development is hard, really hard so if you’re going to make something you best be sure your heart and soul are really into it otherwise you will easily burn out and creativity will be stifled (for reference, most of the mobile market)
  3. What are the development challenges?
    1. Hard is good, impossible isn’t
    2. It’s good to push to break new ground and do something unique or challenging but it should also be at least remotely feasible. Don’t try and make an MMO with 10 people or tackle a huge technical challenge if you are a fledgling development studio/team
  4. How well-suited to a game is it?
    1. “Doing” is better than “Being”
    2. Think of the verbs and exploration of spaces
    3. What might be an awesome concept in your head might end up better as a book, movie or another kind of more static media format
    4. Games are interactive – use that to its advantage, make games in which it is fun to do things and have spaces that are enjoyable to traverse, explore and interact with
  5. What’s the fantasy?
    1. Is it being a badass? Very charming? Unique situation?
    2. What is going to captivate player’s imaginations
    3. Example from Deus Ex: “You’re a James Bond figure who is equally good at sneaking, fighting and charming”
  6. What are the verbs?
    1. Sneaking, doing, talking, fighting etc.
    2. As popular as walking sims and narrative games are, try and utilize the interactivity of games as a medium to its fullest
  7. Has anyone done this before?
    1. If so – what can you learn from them? Do your research.
    2. If not – What does that tell us? Is it just a bad idea, or was it simply not feasible before due to other factors (technological etc.)
  8. What’s the one thing?
    1. What is the one thing that hasn’t been done before
    2. You need this unique defining feature that will surprise players (personal addendum – it could also be doing something others have done before but doing it better than ever – though this is a bold approach – not every game can be Spiderman [2018])
    3. Example from Deus Ex: unique combination of genres and player freedom
  9. Do you have something to say?
    1. Is there a meaning behind the game, a message?
    2. Deus Ex was heavily loaded with messages about technology, the future of mankind and the power of governments and corporations
    3. (personal addendum) Not every game needs to have a profound message, but having something to say is always important

In conclusion, this is an excellent talk that I HIGHLY recommend watching in full but if you don’t – keep in mind the above list is, as always, one approach to looking at Game Design and is naturally not suited to all development scales and aims. Nevertheless, it is always important to keep asking yourself questions as you design something and when someone with such a pedigree speaks – you listen.

I also recommend the excellent and thought-provoking Deck of Lenses by Jesse Schell – the companion to the equally useful The Art of Game Design book. It is essentially a deck of cards containing various guiding questions that aim to break your design down to bits. If it survives, you have a solid idea 😛

Sources

YouTube

GDC Vault

Industry Insights – 10 Biggest F-ups from Drinkbox Studios [GDC 2016]

Posted on by Stoyan Stoyanov

Intro

In this article of my Industry Insights series I will be looking at a 2016 talk from Drinkbox Studios best known for standout luchador platformer Guacamelee and it’s recently released sequel (both games that I highly recommend!). Keeping with the spirit of this series, I will do my best to be as brief and concise as possible, hard as that may be for me.

As a disclaimer –  I will inject some of my own interpretation and expansion of the ideas, as this is unavoidable. For the full picture, always refer to the sources, listed at the end.

Summary

This talk focuses on their experience as a longtime indie developer. These tips might not necessarily apply to large studios or solo projects but there is a lot to learn here, so without further adieu:

1) Be careful with referrals – make sure you can trust the people you hire, especially “experts”. Be mindful of taxes and bureaucratic overhead.
2) Ensure comfort and Quality of Life in studio – Lack of comfort means notable drop in quality of work done. Studio tried to cheap out on this early on and it had catastrophic consequences.
3) Be careful with launch date announcements – hold back as long as you can to guarantee flexibility. Getting locked into a set date can be extremely tough to get out of, especially for a small team that doesn’t have the marketing budget to afford spreading news of changes.
4) Use a PR company – saves a lot of money in the long run, especially if you are small and/or not well established. They displayed stats that it very quickly pays off and you shouldn’t be scared of the initial cost.
5) Choose your ports wisely – Make sure that the adaptation to a different platform doesn’t ruin the experience. Making a quick extra buck is nice but often times consumer good will and studio reputation is more important.
6) Use at least a day of buffer before events – accounts for emergencies that might come up & feeling fresh is crucial for important events and public appearances. Very important for showing off at expos – a crucial chance for exposure when a small studio.
7) Handle side projects with tact – employees having their own projects on the side can be great for creativity & productivity but keep it open and transparent to avoid them interfering with studio performance.
8) Beware of hidden costs (mostly for smaller devs) – for expos it might end up being cheaper to just outright buy equipment instead of hiring from the event host or third party providers. They showed that after doing the math it ended up being cheaper for them to buy their own TVs and setup for expos than to hire.
9) QA patches thoroughly – even a seemingly small patch can have a huge impact so never skip on QA time, particularly with regards to save data testing. Be mindful of certifications and other headroom for fixes/reverts. In their case, a seemingly small change to chicken mode meant that player saves could be corrupted and the game unbeatable. Pushing a fix through console certs took ages.
10) Stay cool – even with leaks/reviews keep in mind that everyone is just doing their job. Business relationships are very important and as good as it might feel in the moment – anger and outbursts are never the way to go and will just hurt you and your studio long term. Important for when a journalist slips up.

Sources

YouTube

GDC Vault

Industry Insights – Made out of Meat: Health Systems in Video Games [GDC 2016]

Posted on by Stoyan Stoyanov

Intro

In this first article from my new Industry Insights series I will be looking at a 2016 talk from Catacomb Kids creator Tyriq Plummer. Keeping with the spirit of this series, I will do my best to be as brief and concise as possible, hard as that may be for me.

As a disclaimer –  I will inject some of my own interpretation and expansion of the ideas, as this is unavoidable. For the full picture, always refer to the sources, listed at the end.

Summary

The concept of the talk is to have a frank discussion about health systems in video games. One of the first points raised is that if your character can be replaced by a ball, then you’re probably working with a very high level of abstraction.

People are sacks of meat, after all – the author states in a very HK-47-esque twist.

This statement echoes throughout the talk as developers are urged to think of reinforcing a more authentic and engaging player experience – not just with narrative and aesthetic conceits but also through gameplay and mechanics.

Dwarf Fortress is cited as an interesting example – it’s stupidly in depth damage and affliction mechanics making it possible for people to get sick or get crippled and a hundred other cases that enhance its emergent gameplay. This is of course a very extreme example, that while great in that particular case for enhancing player engagement, is obviously not exactly well suited for wide scale application.

A potential middle ground is to have a sectional damage system – splitting the player into “chunks” as to better simulate a living being. An overall health total can result in a death state past a certain margin but getting to that point can happen through multiple different afflictions. Perhaps these could also change gameplay – could you still use a shield if your left arm was lobbed off?

Thing to keep in mind when designing a more engaging or authentic (not realistic!!) health system is to consider how real human beings work. We can recover from small and large ailments but it takes us time (and resources).

Simulation – defines as employing the rules of the game to work with the representation accurately. A balancing act between Abstraction, Simplification and Simulation.

Aftermath – once the damage is done and time has passed, how do you recover from it? Play around with this. Doesn’t have to be as boring or as linear as most “one solution solves all” implementations currently out there

Active healing – do thing, get better. Besides small animations there is rarely waiting in games – especially meaningfully done. Think of resting in D&D or Banner Saga. Try and tie multiple mechanics to it, to transform it into a unique action, rather than an annoying chore.

In summary – be mindful of your character, how they work and how they might hurt. We are but meat, after all.

Sources

YouTube

GDC Vault

Congruence – Jamchester 2017 Creativity & Innovation Award winner!

Posted on by Stoyan Stoyanov

Jamchester_2017

Now that I’ve finally recovered a bit from a crazy sleepless weekend…

So proud to announce that our team Next_Level won the Innovation & Creativity Award at Jamchester 2017 – UK’s biggest professional game jam for our game Congruence(Yes, most people couldn’t remember/pronounce it either)!

 

Next_level team photo

The Next_Level team

 

Super honoured & humbled – cannot believe how far we got in just 48hrs! Huge, huge thanks to my amazing teammates Jeffrey Robbins, Greg Wray and Adam Westbrook for making the magic happen both visuals & code wise! It was an absolute pleasure working with you guys! Designing the world & puzzles for such a unique game was one of the most fun experiences I’ve had as a designer yet and we’re excited to keep working on it – so keep an eye out, might get a much-improved version in the future 😛

Here’s a link to our WIP quick run through the game showing off our unique game – phone interaction that got us the award 🙂

You can also check out more info on our Jamchester devpost page: https://devpost.com/software/congruence-9wq5b0

 

Global Game Jam 2017 – SubEscape

Posted on by Stoyan Stoyanov

The Jam

The first dev entry of my revived 2017 website will be nothing less than our team submission for Global Game Jam 2017. It’s supposed to be the world’s biggest game jam event with over 36,000 jammers in 702 sites this year, so a pretty suitable choice for a first-ever game jam experience. The location I picked was Dundee Makerspace which overall provided a fairly convenient place with plenty of space for our VIVE setup, though the internet left something to be desired. Next year I’m probably going to stick with the Abertay University location. The jam itself lasted from Friday 18 till Sunday 18:00, with games revolving around a single word – in 2017’s case “Waves”. There are also some “optional modifiers” that people can aim for that are supposed to make it harder and more interesting for veteran jammers but we (thankfully) chose to avoid them.

The Team

 

Our chosen team name
The team itself

My team consisted of Michael Greenard, who handled pretty much all the code and had to work two sleepless nights. His heroic efforts will be remembered. Matthew Aitchison who was responsible for the vast majority of the 3D assets in our not-so-intelligently chosen realistic VR art style. Paul Drauz-Brown, who did all of the game’s audio and also had a sleepless streak fighting against UE4 and wwise integration. George Rankin who helped a lot with the design of the game and levels, along with me, Michael and the rest of us (no space for a dedicated designer in these small teams) and also spent the better part of a day obsessing over making a nice door. It did end up a pretty nice door, though. And, lastly, me helping out wherever I could, mainly with design and 3D assets, with some particle work.

The Concept

We took the word waves and… well, to be perfectly honest, I feel like we lost our way a bit with regards to integrating it into our game. We had a lot of ideas about how it could fit in. The concept was simple – a VR Escape The Room style game in a submarine. We had ideas of going deeper into the submarine leading to madness, with waves of distortion. We had ideas of mysterious entities zip[ping by outside the sub. We had ideas of having a “pulse” mechanic – similar to scanning waves in sci-fi games. Sonar. Brain waves. Etc. etc.

The Execution

In the end, as it usually happens, we had to drastically scope down and ended up with having blinking alert lights, creating waves of red light that briefly illuminate your environment as you try and move from room to room before the water gets to you. The puzzles were mostly authored by George, me and Michael, though it was in general a collaborative effort in terms of design. We kept it fairly simply, eliminating a lot of our more extravagant ideas outright (like mine and George’s wacky torpedo-launching puzzle), mostly due to time constraints, programming complexity and the fact that we stupidly chose to go with a very realistic art style, meaning that asset creation was very slow.

Personally, the most I got out of the project was working within such small time constraints, which relally helped me learn how to optimize my workflow. Unfortunately, I wasn’t familiar enough with using UE4 in a VR environment to meaningfully help with coding and seeing as design was shared between multiple people, I chose to focus on 3D assets and particles. The 3D assets in particular were very interesting to me as our artist was using Quixel Suite 2. One quick glance at its smart material system and I was hooked. Even though I am very far from a 3D artists, I quickly dusted off Maya and went back into it after a 1yr+ hiatus. Though it took me a while to get back to speed and I essentially impulse bought and learned Quixel Suite 2 in several hours, by the end I got into a decent groove and made some pretty decent assets. I’m definitely very eager to use it more and would definitely recommend it to anyone interested, it is an incredible piece of software and simply works within Photoshop.

You can find it here

My biggest struggles were working with a brand new team, comprised of people I didn’t know/barely knew, working within such tight time constraints and with minimal sleep and also making sure I had something to contribute to the team. I definitely felt quite bad at the beginning as, after my design contributions, I was tasked with some assets. They took me an insanely long amount of time, most of which was spent remembering the proper pipeline for importing UE4 assets (curse the damn legacy FBX exporter and Maya 2017 defaulting to some completely incompatible version – as well as the in-built “send to xxx” functionality being broken.) and also how to properly combine, unwrap and generally triangulate. Worse still, my very first asset (which was horrendously broken in its first iterations) was a crucial component of the first puzzle – namely the valve that the player needs to find and attach to the first door, in order to proceed. Inefficient modelling, improper mesh combination, bad UV’s, wonky pivot, scaling and orientation – it had it all. Overcoming the shame of it, fixing it and then getting into it more did help me create some semi-decent stuff by the end.

In my desire to help further I also made the game logo and splash (featured at the top of the page), wrote the game submission and made the game trailer. Will definitely work on my After Effects/Vegas skills more in the future, as it is incredibly useful to have in this day and age. I also spent a decent chunk of time looking into Cascade – UE4’s particle system. It’s an archaic mess at first glance, but works very well within its own dated logic. It was admittedly a bit of a shock the first time I saw it – I felt like I was warped back into UDK. Decent documentation and some excellent tutorials helped me somewhat begin to understand it. In the end I made some pretty nice particle effects that sadly couldn’t make it into the final project as we ran out of time. That was mostly since Git completely failed on us as soon as the file sizes got bloated and for the latter half of the project we essentially had only one PC with an up-to-date game version.

Overall, it was an invaluable learning experience and one that I am eager to repeat, though for my next jam I will look more into my own skill set, so that I am better prepared as remembering and figuring out stuff all over again is simply time wasted. Time that the team doesn’t have.

The Result

It’s not the best game in the world and it won’t win any awards but for my first game jam I am quite proud. A VR game with a realistic art style and bloated scope is far from the easiest thing to pull off in such a short time with an amateur team but we gave it our best shot. In the words of one of our team members – it’s better than a lot of VR stuff actually out there on Steam right now. Though that might speak more about the state of the industry and valve’s standards that it does of our aptitude. A special shout out to Michael, our programmer and Matthew, our 3D artist for doing the majority of the work.

Relevant Files

SubEscape Video Demonstration

Game File Repository

Global Game Jam 2017 – Sub Escape Page