• Register

Independent game designer and gameplay programmer based in Glasgow, UK

RSS My Blogs  (0 - 10 of 13)

Attention Scottish gaming and gamedev lovers: MEGAbytes Indie Showcase 3 will take place on Saturday 23rd April at the MEGAbytes Retro Gaming Cafe in Glasgow, UK and and we're looking for developers keen to showcase their creations.

Below we've provided some more information about what you can expect at this and upcoming events:

Q. What is the MEGAbytes Indie Showcase?

The showcase aims to bring gamers and developers together by enabling local developers to showcase their creations whilst allowing gamers to playtest and provide feedback.

Q. Do I need to pay to showcase or attend?

No: demonstrating is free and all showcase games are free to try. All feedback is incredibly useful for the developers and we encourage attendees to chat to the developers about their experience.

Q. What do I need to bring and what can you provide?

The minimum you will need to bring is a system to play your game on. In some cases, we may be able to provide a TV or projector but cannot always guarantee this. Let us know in advance if you have any specific requirements so we can try to accommodate.

Q. How far along does my game need to be?

We're particularly keen on games that are mid-development or recently released games as we feel these developers will benefit most. You don't need to have a complete game - a small demo or prototype is fine - but we recommend you get the game to a stage you are comfortable with showing off.

Q. How long does the showcase last?

We typically hold showcases between 12 and 6pm on a Saturday with set-up starting from 11.30am.

Q. How many playtesters can I expect?

The cafe' gets a steady stream of customers throughout the day with a peak mid-afternoon. You will have time for breaks and testing other games on display. We cannot guarantee you will always be busy or everyone will want to play your game.

Q. Will I need to bring or provide any marketing materials?

We may ask for a digital banner/poster for your game and a website link so we can share your information via social media. You don't need to bring any marketing materials on the day - wall space is unavailable - but you are free to bring flyers/handouts if you like.

We encourage you to blog about your attendance before, during and after the event.

Q. How do I register my interest?

If you're keen to demonstrate at the next showcase, please email Clive Lawrence and provide a description of your game and a link to your website. A demo is not required for submission. Depending on level of interest, we may or may not be able to accommodate all applicants during a single showcase but will strive to offer future slots where possible.

If you're interested in attending upcoming showcases, follow Megabytes and The Man Who Flew Away on Twitter for the latest news/updates.

Q. How do I get there?

Below you can find links and directions to MEGAbytes Glasgow:

Facebook: Facebook.com

Twitter: Twitter.com

Map: Here.com


Thanks for reading and if you have any additional queries please get in touch.


Clive Lawrence

The Man Who Flew Away

www.themanwhoflewaway.com

Attention Scottish gaming and gamedev lovers: MEGAbytes Indie Showcase 2 will take place on Saturday 12th December 2015 at the MEGAbytes Retro Gaming Cafe in Glasgow, UK.

The event will take place from 12-6pm and will feature the following developers from Dundee and Glasgow:

(1) Fragmental by Ruffian Games (Greenlight / Blog / Twitter / Facebook / Twitch) - PC/Linux

We're proud to welcome Ruffian Games from Dundee whose previous work includes Crackdown 2 (X360). They will be showcasing their recently-Greenlit title Fragmental. Expect lots of fast-paced multiplayer carnage.

MB2 Fragmental

(2) Observatorium by The Man Who Flew Away (Greenlight / Website / Twitter / Facebook / Indie DB) - PC

The Man Who Flew Away will be returning for the second showcase to demonstrate more of their alpha gameplay from Observatorium: a recently-Greenlit puzzle adventure game coming soon to PC:

MB1 Observatorium

The cafe will be open as normal on the day of the showcase. As before, all showcase games are free to try and all feedback is incredibly useful for the developers. We're expecting it to be quite a busy day at the cafe!

Below you can find links and directions to MEGAbytes Glasgow:

Facebook: Facebook.com

Twitter: Twitter.com

Map: Here.com


In addition to trying some unreleased games, you'll also get a chance to talk to the developers and enjoy all the usual cakes, coffees and retro-gaming treats.


We hope to see you there!

Clive Lawrence

The Man Who Flew Away

www.themanwhoflewaway.com


PS. If you'd like to get involed in future showcases, subscribe to this list on Twitter or drop me a mail.

6/12 Update: Unfortunately, due to unforeseen circumstances, Suminell Studios will be unable to attend the December showcase so TMWFA have stepped in to take their place. We hope to welcome Suminell Studios back with Z-Exemplar sometime during the new year.

Calling all Scottish indie devs: following the success of the first MEGAbytes Indie Showcase on Saturday 17th October - which included Insert Imagination, The Man Who Flew Away and Rhizome Games - we're pleased to announce the second one will happen on Saturday 12th December from 12-6pm and we're looking for a range of new games to present.

Please ping me if you're interested in demonstrating your game - themanwhoflewaway@hotmail.com - and include a link to the game you would intend to show and how far along in development you are. We will prioritise games-in-progress and recently released games as we feel these devs will benefit most.

Based on the first event, we'll be looking for 3 teams/developers to showcase their work but this will really depend on the sort of games you intend to bring and the equipment required.

It's a fantastic opportunity to demonstrate your game for free, chat to fellow developers and get valuable feedback from the MEGAbytes customers and staff.

Below you can find links and directions to MEGAbytes Glasgow:

Facebook: Facebook.com

Twitter: Twitter.com

Map: Here.com


If you can't attend this one, you can still register your interest in upcoming showcases by subscribing to:

Twitter: Twitter.com


If you have any queries get in touch!


Clive Lawrence

The Man Who Flew Away

www.themanwhoflewaway.com

Hi all,

The first official MEGAbytes Indie Showcase will take place this Saturday: 17th October 2015 at the MEGAbytes retro gaming cafe in Glasgow, UK:

The event will take place from 12-6pm and will showcase talent from independent developers from Glasgow and Dundee. Three games will be playable at the first showcase:

(1) Loot Hound by Rhizome Games (Website / Twitter) - PC

(2) Observatorium by The Man Who Flew Away (Website / Twitter / Indie DB) - PC

(3) To-Tum by Insert Imagination (Twitter / Indie DB) - Mobile

Below you can find links and directions to MEGAbytes Glasgow:

Facebook: Facebook.com

Twitter: Twitter.com

Map: Here.com


Please come along and try the games for yourselves! You'll also get a chance to talk to the developers and enjoy all the usual cakes, coffees and treats at MEGAbytes.


We hope to see you there!

Clive Lawrence

The Man Who Flew Away

www.themanwhoflewaway.com

PS. If you'd like to get involed in future showcases, subscribe to this list on Twitter!

Hi all.

Regarding the MEGAbytes showcase - we're looking to host the first event on Saturday 17th October 2015 during the daytime.

Please ping me if you're interested in demonstrating your game and include a link to the game you would intend to show and how far along in development you are. We will prioritise games that are not yet released as we feel these are the devs that would benefit the most. Please also mention the sort of equipment you'd intend to bring so we can accommodate.

We'll probably need to keep the number of devs low (3-4 perhaps) for the first showcase to gauge how things go: this will really depend on the sort of games on display. The plan is to assign the showcase to half of the cafe and keep the other half open for business as usual.


Below you can find links and directions to MEGAbytes Glasgow:

Facebook: Facebook.com

Twitter: Twitter.com

Map: Here.com


If you can't attend this one, you can still register your interest in upcoming showcases by subscribing to:

Twitter: Twitter.com


If you have any queries get in touch!


Clive Lawrence

The Man Who Flew Away

www.themanwhoflewaway.com

Calling all Scottish indie game devs: I'm looking for a list of people who'd be interested in showcasing their work - at various stages of development - in Glasgow city centre. I'm currently in talks with the owners of MEGAbytes retro gaming cafe (map) about the possibility of setting up some one-off or recurring showcases where indie game devs would be able to demonstrate their work to a range of customers.

MEGAbytes logo and links below:

Facebook: Facebook.com

Twitter: Twitter.com

We have still to work out the finer details of these events - such as dates, time-of-day, duration and max number of developers-per-session - but for now we're keen to get a list of interested parties so we can see how best to accommodate. Obviously everyone is welcome to apply but we're particularly keen to gather developers from in and around Scotland. I've started a list on Twitter so please let me know if you'd be interested in joining (or simply subscribe and I can add you as a core member):

Twitter.com

Thanks for reading and don't hesitate to get in touch if you have any questions.

Clive Lawrence

The Man Who Flew Away

Manwhoflewaway.wordpress.com

Welcome to the third in my series of game design tips. In part 2 I focused on prototyping so for part 3 I'll talk about the related process of playtesting. This post is a more generic and expanded version of the one I posted for Observatorium last year.

What is playtesting?

Playtesting is the process of letting other play your game before release. The point of playtesting is to highlight (1) design flaws and (2) major bugs in your game. The process of discovering and fixing these issues should strengthen your product.

When should you start playtesting?

As early as possible! Deciding on what to playtest in the first instance ties in nicely with the topic of prototyping: try to separate your 'design' from your 'wrapper' and produce a small demo that underlines what is new/interesting about your game. Playtesting is all about getting feedback to help direct your efforts so focusing on what's unique will get you off to a good start. Aim for 5-10 minutes of play.

How often should you playtest?

Playtesting should occur at all stages of development. Important milestones such as first playable, vertical slice, alpha etc. are particularly important but it's useful to perform regular playtests - such as fortnightly or monthly - to ensure you're thinking of others as well as yourself at all times. Don't be scared to arrange a playtest if you're stuck on the design of a certain feature: playtests are like experiments that provide useful feedback which fuels future development.

Consider your Target Audience

It's useful to keep your target audience in mind once you start bringing others on board. Keep a note of the name, age and gaming experience of each tester and refer to this when considering what feedback you will/won't address. Addressing all feedback can sometimes be as counter-productive as addressing no feedback whatsoever: trust your instincts and look for trends.

Suggested Phases for Playtesting

Below is a suggested approach to playtesting: the idea being to start small and branch out with each stage - adding more people to the test pool and improving the quality of feedback you'll receive. You can however choose to playtest in any way you like: just be sure to consider the approach that's right for your game.

(1) Test Yourself

This may seem counter-productive but before getting anyone else on board you should test it yourself. It's hard to analyse your game impartially being so close to development but some things you can look out for at this stage are:

  • Aim - does the demo have a goal? Does it provide enough of a challenge or is there an adequate progression in place? If not, subsequent tests may not be very useful to you right now.
  • Showstoppers - anything that seems like a major bug will hamper subsequent playtests and shift the focus from playability to stability. Prioritise glaring bugs that are easily reproduced and fix them. Infrequent critical bugs or any minor issues can wait
  • Tutorials - ask yourself if you have trained the player adequately for the challenges they face. If not - add more details: you're already thinking about design improvements for first time players!

You don't want to spend too long on this phase as you should be testing your game daily as you add new features. This stage is about making sure you're ready for the next step...

(2) Test with Friends

Next, ask close friends to play your game and watch them as they do it. Chances are you will have missed alot of major issues in phase (1) and will need to go back. The point however is to get people outside the development team to play your game and get a useful list of feedback to help you focus. From this point on you'll want to start taking notes and refraining from interacting where possible. The approach I often use is:

  • Observation - let your friend play the game and observe them silently
  • Vocalisation - ask your friend to vocalize their thoughts as they play as much or as little as they like. This gives an insight into their thought process and how they are interpreting the game. Believe it or not what you see them doing and what they tell you they're trying to do may be completely different (!)
  • Notes - make a note of any playability issues they encounter: this will depend on your game design but some examples of things you'll want to look out for are (1) clarity - do they understand the concept, menus and gameplay? (2) flow - are they experiencing the game as you intended? (3) fun - are they enjoying the experience as you intended?

Make a note of bugs but flag them as such - again, you can deal with these later. Do not start the playtest by explaining your game to them: you want them to come at this cold to gauge the usefulness of your prompts.

If your friend gets stuck don't abandon the test (though for all intensive purposes your game is most definitely not ready for market right now) - let them sweat it out for a while. If they still can't progress I find it useful to ask them what they think they're trying to do rather than to help them immediately. The need to ask this question and the response they give you will pave a path towards a solution.

I find it useful to keep a pool of friends close to the development cycle and send them regular builds. Asking your friends to record their playthrough is very useful but If you're unable to observe them it's still useful to ask (1) did you get stuck anywhere? (2) was there anything you didn't understand? etc.

(3) Test with Friends of Friends

Why friends of friends? You'll want to test with someone who isn't worried about hurting your feelings. These tests will also take a bit longer to organize and you'll want to use them wisely so I would suggest fixing as many issues from phase (2) as possible before moving on.

This process is very similar to (2) but you should treat it as much more formal. Imagine these people are part of your target audience. At the end of the playtest, it's useful to have Q+A about the session and anything you're trying to quantify or improve. Some example questions:

  • How useful did you find the tutorials?
  • How intuitive did you find the controls?
  • How helpful did you find the in-game readouts?
  • When would you have stopped playing the game and why?
  • Was there anything that could have been explained better?
  • General thoughts on gameplay?
  • General thoughts on story?
  • How intuitive did you find the menus?
  • Any other comments/suggestions?

This is not a definitive list and you could ask some of these questions at phase (2) also. The point of Q+A is to open a forum for feedback and get an insight into problems/suggestions you may not have even considered yet. Take all feedback into account and consider what changes you could make to improve your game most.

(4) Test with the Public

The final phase is to test with a broad community: either through releasing a demo online or by attending an indie game event. Being able to directly observe your testers or viewing a video of their gameplay session is infinitely more useful than trying to interpret comments on a forum but don't be afraid to ask follow up questions if you don't understand someone's response to a particular section but refrain from interfering with their playthrough.

This phase should be considered hands-off: the core goal is to get a large volume of testers to play your game and expose new issues or underline old issues you haven't quite fixed yet. Be available to fix/bypass any show-stoppers of course but don't interfere too much. Take notes - as always - and feed this back into your development cycle.

Playtesting vs Quality Assurance (QA)

Playtesting should not be confused with QA. Although the QA team is very important, the QA process usually happens at the end of the development cycle. Do consider first-time feedback from the QA team but bear in mind that feedback on deeply-embedded design issues will be harder to address the closer you are to release.

Staying Focused

This seems like a lot of work - and it is - but the point of playtesting is to prevent design issues from snowballing. Some other points to consider:

  • Keep your original goals in mind and how you can tweak your design to achieve them
  • Playtest important milestones - first playable, vertical slice and alpha are especially important
  • Substantial changes to existing mechanics or adding new ones requires more playtesting
  • People unfamiliar with your game are more valuable than previous testers
  • Try not to go round in circles - every fix should move the game forward
  • Try to look for trends - these are undoubtedly the "must fix" items
  • Try to prioritise feedback before proceeding and set reasonable goals for addressing it
  • Don't hide behind fancy art/sound in early demos - you want to expose design flaws
  • Be wary of the audience you are targeting: don't try to make a ‘game for everyone'
  • Quality assurance should not be the sole stage where playtesting occurs
  • Stay positive - take every page of feedback as a sign your game needs more time

Benefits of Playtesting

The benefits of playtesting are similar to benefits of prototyping:

(1) Identifying/Removing Risks - early playtesting can save you time and money and de-risk the later stages of your development cycle. Code is time consuming so you'll want to reduce coder workload where possible. Art and audio are low risk and can change right up until release. Design however feeds into code/art decisions and should be locked down as early as possible. Design issues will propagate the longer they are ignored.

(2) Confidence in your Product - playtesting can give you confidence in what is/isn't working. You may be overly worrying about how you've designed a certain feature but playtesting may reassure you that the chosen implementation is actually the right one; playtesters may instead draw your attention to another area you thought was flawless.

(3) Improving your Experience - every time you perform a playtest with someone new you will undoubtedly see them react to your game in a way you did not anticipate. How you choose to react to such feedback will pave a path towards improving the experience for other first time players. Once you've performed enough playtests and reacted to enough feedback in a positive manner you'll find it less painful to watch subsequent tests.

Conclusion

That's it for part three of my game design tips. I hope this [lengthy] ramble has been useful to you. If you have any thoughts or feedback - or if there's any topic you'd like me to cover - then let me know.

I'm on twitter at @manwhoflewaway

Thanks for reading and good luck with your projects!

Clive Lawrence,

The Man Who Flew Away

Follow Observatorium development here on Indie DB

Welcome to the second in my series of game design tips. In part 1 I focused on tips for getting started; part 2 focuses on prototyping your ideas.

What is Prototyping?

You may have heard a few phrases being tossed around such as 'first playable', 'vertical slice' or 'minimum viable product' but this post focuses on what I consider to be one of the most basic building blocks of game development: prototyping.

The point of prototyping is:

  • To build a working demo that explores an idea for a game, mode, level or mechanic
  • To test any assumptions you made during your ideas/brainstorming phase
  • To discover what is/isn't work and add/remove features where necessary
  • To spend less time worrying about efficiency/presentation and more on design flaws
  • To come to a decision about whether your design is actually any good

Prototyping should not be limited to the start of your development cycle. Any time you write down an untested gameplay idea you intend to work into your design that idea needs to be prototyped.

Assume Failure

The last bullet point is important: the healthiest approach to game development - I find - is to assume failure. I'm not talking about long term failure - the worry that you may never become a successful game dev (don't worry about that: worry about making good games!) - I'm talking about short term failures that should occur naturally as part of your development cycle.

As human beings we make mistakes and as game designers we get overly excited about ideas we write down on paper. The point of prototyping is to prove if those ideas are actually any good. Although we've been making videogames for decades there are no hard and fast rules as to what makes a good game - 'fun' isn't always the core goal of a game dev project and tastes are ever changing - so prototyping is essential.

Choose a Tool for Prototyping

If you're just getting started and haven't decided what engine to build your game with, try to find a package you feel comfortable in using. I love Unity as it's great for rapid prototyping, has a massive support community and is fun-to-use. If you have an idea for a FPS and are familiar with Unreal or Source then use them instead. Don't worry if you end up switching engines after this stage: the point of prototyping is to prove your core idea.

Start Building

The next step is to start building. If you're just getting started on a brand new idea it may be a while before you can properly test your design as you lay down any required systems. If you already have a game-in-progress and are prototyping a new mode/feature you'll have a good base. If you don't know how to build something - learn: or ask a friend to lend you their skills/advice. Don't be afraid to seek help where required!

Decide How Much To Build

An important question to ask yourself is "how much should I build"? My tip is to build as little as possible. This sounds quite lazy and...it really is! Build the smallest possible set of features that prove your game/mode/mechanic is worth building. Don't be afraid if your code/design is quite messy at this stage or if you have to hack certain features together to make them work: you can polish them up as you decide to move forward with your designs and engine-of-chouce. Build enough to convince yourself the idea is worth building and if you plan to extend your idea try to ensure it will work in more than one scenario.

The amount to build really depends on whatever you're trying to prove: if you're working on a brand new idea try focusing on the 'minimum viable product' - that is the smallest set of features that prove what you're trying to build is worth building. If you're building a new mode or feature then get the basic rules/mechanics down and then playtest/refine.

Separate your 'Wrapper' from your 'Design'

This is an important point (particularly for early prototypes) as it forces you to think about what features actually need to be prototyped. Your 'wrapper' encapsulates your aesthetic decisions for your game and is not necessarily important for prototyping. Your 'design' on the other hand encapsulates alot of important flow/function choices that knock onto many areas of your game. A good rule of thumb is to avoid hiding behind fancy artwork/sound for early demos. If you need final artwork/sound to prove your design you aren't necessarily paying enough attention to potential design flaws; additionally, playtest feedback may be clouded as the playtesters focused too much on how fantastic your game looks/sounds. Horror games are a slight exception but even demos like Slender: The Eight Pages prove that you can do alot with very little.

Don't Start at the Beginning

This is not a golden rule (and not applicable to all prototypes) but I find it quite useful to avoid building games from the start. As we build the start of our games we get very bogged down on how we introduce the gameplay, tutorials and story. In reality the first 10 minutes of play are the most important to keep players engaged but you don't necessarily have to start building here. You can polish your introduction right up until release and can use the results of playtesting to better improve the experience for first time players.

Playtest and Refine

Once you have your prototype you'll want to review it yourself and with a group of testers. The process of playtesting is complex and I will cover this in the next article but you should try to convince yourself that the idea you have is worthwhile and free of any major design flaws before pushing a dud idea too far. If you're looking to rapidly prototype a new game idea, try giving yourself some deadlines to work towards - weekly or fortnightly depending on your workload - and try giving your game to new testers in addition to older testers who may have given you some negative feedback to consider.

Benefits of Prototyping

Below I outline some of the major benefits of prototyping early and often:

Identifying Risks - one of the best reasons to prototype is identifying risks in your project - such as e.g. "not fun", "confusing gameplay", "story hard to follow" - early on and try to think of how to resolve them. This can help de-risk later stages of your development cycle and help you make better design decisions. If an idea just isn't working you can shelf it before spending too much time on it.

Happy Accidents - as you build you'll have a lot of happy accidents: features that arise because you accidentally combined a few elements or messed up some code/design setup somewhere. These features may become new game modes of their own or even the foundation of your current game idea.

Confidence in your Product - it's important to have confidence in any idea you are pushing and prototyping can help to underline what is/isn't working. Things that are really working can give you confidence your idea is successful in certain areas. If something isn't working, you may want to spend extra effort trying to fix what failed or make an informed decision about whether or not to cut or replace it.

Conclusion

That's it for part two of my game design tips. I hope this ramble has been useful to you. If you have any thoughts or feedback - or if there's any topic you'd like me to cover - then let me know.

I'm on twitter at @manwhoflewaway

Thanks for reading and good luck with your projects!

Clive Lawrence,

The Man Who Flew Away

Follow Observatorium development here on Indie DB


I've been busy working on my puzzle/adventure game Observatorium over the last few months and have been posting related news articles here. Everything is going well and we're hoping to get a gameplay trailer out soon and start discussing options for community involvement prior to release.

I'd love to post a little more often here on IDB - and my favourite news posts are ones that provide some value to others in the community - so I've decided to start posting general suggestions for game development here on my personal blog. Hopefully the information contained here will be useful: especially if you're new to game design or starting a new project.

For this initial post I'll provide some tips on getting started.

Getting Started

Getting started with a new project and staying focused can be a daunting prospect: you will dedicate hours, weeks and - if you're truly committed - months of your life to finishing your game. However, making a game you feel proud of is rewarding and if you grew up playing games and are passionate about getting involved you shouldn't let anything get in your way.

Getting started with the right mindset is great fuel for seeing your project through to completion. Here's some tips to jump-start your project:

Think About What you Want to Make

This sounds silly but before asking yourself what other people want to play I suggest asking yourself what you want to make. It's easier to commit your spare time to a project you are genuinely passionate about than one you're just grinding away at in the hope of making others happy. So why not ask yourself:

  • Do you have a truly original gameplay idea?
    • Truly original ideas will tend to grab more press attention
    • Competition is ever-increasing - look for niches where possible
    • Original isn't always better - improvements to old ideas are also valid

Antichamber, Fract O.S.C. and Five Nights at Freddy's are just some examples of great original games from the last few years: they all did something unique and with good execution.

  • Is there a type of game or games you enjoy playing? Ask yourself:
    • Why do you enjoy playing those games - is it down to the theme/world/gameplay?
    • Do you have an idea to put an interesting slant on your favourite game or genre?
    • Is there something a game does wrong you feel you could improve on?
    • Can you make something more interesting by adding a new mode or mechanic?
    • Could you merge 2 unrelated genres to create something unique?

Personally I love action, puzzle, adventure and roguelike games and anything with a strange or immersive atmosphere so for Observatorium I chose to focus on a puzzle/adventure experience.

  • Do you have an interesting story that could be told interactively?
    • Everyone loves a good story - if you can pull it off you'll surely get noticed

Frictional Games (Amnesia) and The Astronauts (The Vanishing of Ethan Carter) are particularly good at narrative-driven experiences as are The Full Bright Company (Gone Home) and Telltale Games (Walking Dead). Valve Software and Supergiant Games are very good at weaving narrative elements into their games but with more of a gameplay-driven focus.

Brainstorm

Before you get into the nitty gritty of game development - and the endless amounts of biscuits and coffee you will consume - get a pad of paper and start brainstorming. Work alone or as part of a team. Write down possible:

  • Genres
  • Themes
  • Hooks
  • Modes
  • Mechanics
  • Storylines
  • Events

My number one tip for this stage is to keep your ideas loose and succinct: don't get too attached to anything. The following examples show just how brief you can be:

"Sci-fi horror game"

"Card battle game with weapons and upgrades"

"What if we took something like Papers Please and added multiplayer?"

The aim is to get your ideas flowing and start to home in on the sort of idea you're interested in making. Don't worry about creating an elaborate design document at this stage - you can always flesh this out after you have finished prototyping - but try and get enough information that will allow you to start building.

Prototype

The next stage is to take your favourite idea (or ideas) and start to prototype them. The great thing about being an indie developer in 2015 is we have companies like Unity and Unreal fighting for our attention.

Try and find the package that is right for you: one you feel comfortable in using. Don't worry if you end up switching engines after this stage. The point of prototyping is to prove your game design and not get bogged down on technical restrictions. Additionally, do not hide behind fancy artwork or sound for early demos. If you need final artwork/sound to prove your design you are not focusing fully on possible design flaws.

Focus on building the Minimum Viable Product - that is the smallest set of features that prove what you're trying to build is worth building. Say you're building a puzzle game, the minimum viable product would be a single puzzle from some point in the game. If you're building a first person shooter then your minimum viable product may be a single character with a single gun against a group of enemies in a small level.

I don't recommend building your game from the start: the reason being your tutorials will undoubtedly go through many different revisions and by the mid-to-end of your project you'll have a much better idea of how you want your game to start anyway. Focus on a simple demo that proves your idea and include some simple prompts on-screen where required.

Don't worry about all the ideas you have written down that you aren't implementing just yet - they will become useful later in the development cycle, on another project or may evolve into something you weren't expecting.


Review and Iterate

Once you have your prototype you'll want to review it (1) yourself and (2) with friends or the community. The process of playtesting is complex and I will cover this separately but for basic prototyping you should ask yourself:

  • Do I enjoy the demo?
  • Do my friends and/or the community enjoy the demo?
  • Am I confident that I can push forward with this idea?

If an idea doesn't seem to be working - for some reason it just "doesn't feel right" - don't proceed past this step yet. Tweak your idea where possible - refine and improve what you can - and then get your friends or the community to test the game again. React to feedback and improve what you have. If things still just aren't working, park it for now and move onto something else.

Prototyping is an iterative process. You will most certainly end up changing assumptions you made during the brainstorming step as you realise the game doesn't feel exactly as intended. This is one of the primary reasons for prototyping: identifying risks in your project such as e.g. "not fun", "confusing gameplay", "story hard to follow" - and forcing yourself to think of how to resolve them at an early stage. This can help de-risk later stages of your development cycle and help you make better design decisions.

Don't be afraid to fail. After making a 1 or 2 poor demos you may find that after 3 or 4 iterations you suddenly hit upon something fun and unique. You'll also have alot of happy accidents: features that arise because you accidentally combined a few elements or messed up some code/design setup somewhere. Aim for 5 to 10 minutes that prove your idea and make sure you end up with something you're comfortable to push forward with.

Conclusion

That's it for part one of my game design tips. I hope this ramble has been useful to you. If you have any thoughts or feedback - or if there's any topic you'd like me to cover - then let me know.

I'm on twitter at @manwhoflewaway

Thanks for reading and good luck with your projects!

Clive Lawrence,

The Man Who Flew Away

Follow Observatorium development right here on Indie DB



The Man Who Flew Away is proud to present Observatorium: a puzzle adventure/exploration game currently in development for PC using Unity. The official Indie DB page for the game is now online here - Indiedb.com - so watch that space for the latest news and updates. As a special treat, here's the initial poster for the game (full HD version can be found in my images section):

A reminder to anyone thinking about attending Dare Protoplay 2014 next week - Daretobedigital.com - The Man Who Flew Away will be appearing at Caird Hall in Dundee, UK on Saturday 9th and Sunday 10th August and will be demo-ing Observatorium for the first time. If you are in the area, please come along and give the game a try. Any feedback is greatly appreciated!

Clive Lawrence
The Man Who Flew Away