Prototyping In Game Development!

In game development, prototypes are hugely beneficial. Essentially they are a test an idea or a concept, in a very simple rudimentary form, ideal for showing whether an idea has merit or will actually work. These can come in different forms: In a typical small piece of a program, with basic code to represent the idea or in a physical form like a paper prototype used to communicate the idea of the game before anything has been coded. (BORYSOWICH, 2007)

There are also different purposes of Prototypes, some of which are used in games in different ways:

• Proof of concept/Concept Prototype - A high level prototype or overall vision, this in games is usually represented by the 'core game loop'
• Feasibility Prototype - This is used to compare and contrast different solutions for specific situations, this is more relevant to technical approaches to the game as opposed to the design. For example: Comparing the feasibility of different lighting systems.
• Horizontal Prototype - More commonly used as a way to define the function of various buttons, menus etc, can be visualised in a paper prototype. 
• Vertical Prototype - A stripped down but working, complete system. Ready to implemented, usually data orientated. So something like a character inventory system that works, ready to be migrated to the main game.
• Benchmark - A 'Visual' prototype, used for a projects art direction, materials and texturing. A small sample scene to demonstrate the potential look of a project

Why prototype?

A prototype is used for the purpose of finding the correct solution to a problem, to whether an idea will work or not. Without prototyping developers will be going in blind attempting to make a full game project with preconceived ideas on how things will work without actually knowing if it will. Prototyping is essential, especially if you are an indie developer looking to come up with experimental gameplay. Prototyping and experimentation goes hand in hand.

In a development cycle it is useful initially as a way to figure out all the core game mechanics in a controlled environment, without focusing on non-important elements. This is used to implement the 'core game loop' which I talk about here Core Game Loops, which is the highest level game mechanic which the player will be repeating through most of the game. In FPS games for example that may be running around and shooting enemies. When that basic feature is implemented and feels good to play then the next feature is worked on and prototyped. This iterative process is whats needed to construct a game.



The developers behind 'World Of Goo' created the initial game using rapid prototyping techniques they honed in the Experimental Gameplay Project. (2009) World Of Goo (2008) was originally a small game called 'Tower Of Goo' which was created by one person 'Kyle Gabler' during the experiment. After the experiment Tower Of Goo received huge praise and around 100,000 downloads, so development began on a full game using the same core concept.

Other uses

Prototypes are also useful in game pitches, where a playable prototype is used as a way for possible investors to judge whether they want to support a project or not, this can be seen on Indie-fund.com where they ask for a playable prototype to show the game's unique qualities.

Game-jams are a similar concept of building up a core game concept very quickly, quite often popular games in game-jams can go on to be released as full games down the line. This is the same situation for Sigtrap's SubLevelZero (2015), which started of itself as a game-jam project.


Sources:

1. Experimental Gameplay Project (2009) [Webpage] Available from: http://experimentalgameplay.com/ [Accessed 31/10/16]
2. GRAY, K. GABLER, K. SHODHAN, S. KUCIC, M. (2005) Gamasutra - How To Prototype A Game In Under 7 Days [Webpage] Available from: http://www.gamasutra.com/view/feature/130848/how_to_prototype_a_game_in_under_7_.php [Accessed 31/10/16]
3. Sigtrap Games (2016) [Webpage] Available from: http://www.sigtrapgames.com/sublevelzero/ [Accessed 31/10/16]
4. 2D BOY (2008) World Of Goo [CD] PC. Mastertronic Group.
5. SIGTRAP GAMES (2015) SubLevel Zero [Online Steam] PC. Sigtrap games.
6. Prototyping at Hyperspeed (2015) Available from: http://gram.gs/gramlog/prototyping-at-hyperspeed/ [Accessed: 24/10/16].
7. BORYSOWICH, C. (2007) Prototyping: Types of Prototypes [Webpage] Available from: http://it.toolbox.com/blogs/enterprise-solutions/prototyping-types-of-prototypes-14927 [Accessed: 09/11/2016]

How are indie games made? Software and production methods

Like the actual formation of an indie studio the process of making them also differs slightly between studios as they make different types of games. For some smaller developers, a lot of the process is experimentation and tinkering with the project in spare time while moving to larger groups there could be more of a solid project structure in place. However, that isn't to say that there isn't something in common with all projects; certain things like project management methodologies, source control and file management are crucial to the successful running of a game project.

Game development is just like normal software development. Both require regular testing for usability and bug fixing, only games are more tailored for a specific experience of play as opposed to having a practical function. Also games include a much more artistic component; through extensive use of images, sound and graphics game development invests a lot more time on developing these assets.

Indie game development

Different studios work on different types of games, in indie dev this is more likely to come from the developers own background, previous strengths in certain software among other things. This results in the use of different software or techniques. 2D games are more likely to require pixel art for example and will use an engine that is more optimized for 2d levels like Unity or Game Maker, whereas 3d graphic intensive games are more likely to use game engines like Cryengine or Unreal 4. Some may even use their own custom engines for specific uses if they have a programmer on the team that can create it.
A lot of the tools used in development also depends on the teams budget, some engines and asset creation tools are free, making it perfect for starting out but teams that have more money behind them may have access to industry standard software like the Autodesk suite or Photoshop. (Francis, 2012)

Here is a list of commonly used programs in indie development, separated into engines and asset creation tools with a little bit of a description on each software's best uses:

A handful of the engines used in game development. (Pixel Prospector, 2014)

Game Engines

• Game Maker - A 2d game editor used must commonly for creating 2d, retro feeling games
• Construct 2 - A 2d game engine which can be used to create games for mobile or web
• RPG Maker - A 2d top down, grid based engine used for creating classic RPG style games
• Unity 5 - A 2d/3d general game engine that is most commonly used for mobile game development, very scalable
• Unreal 4 - A 3d engine that features an intuitive visual scripting system, also is building on features for 2d games and VR
• CryEngine - A high end 3d games engine for the most graphically intensive of games, includes a lot of high end features like real time GI lighting and translucency

Asset Creation Software

• Gimp - A free image editing software, an alternative to photoshop with layer functions and pixel editing tools
• Blender - A free 3d modelling and animation suite
• Tiled Editor - A free, intuitive 2d tilemap editor with export functions into other programs
• Autodesk 3ds max/Maya - Industry standard premium 3d software for creating models and animations
• Adobe Creative Suite (Photoshop, Illustrator, After Effects etc) - Industry standard premium software for image editing, creating vector graphics and game fx. 
• ZBrush - A premium 3d sculpting package, used in games for creating high detail models which can then be crunched down to a low poly 3d model using a process called baking

Project management methodologies

As I have mentioned before in my reflection on our game art final major project 'Guiding Sprites' on of the things that could have helped development along was a solid project management methodology. For development to go smoothly in most cases some type of methodology should be used, for example: Agile Scrum or Waterfall.

Agile v Waterfall (Segue Technologies, 2013)

Waterfall as a method means a linear progression in the project from concept and design then into production then into testing and debug at the end. Waterfall typically doesn't allow for much user feedback during the development cycle and usually works better when a solid game design is in place (for example, a sequel in a pre-established franchise) for newer, experimental concepts it might not be as suitable.

Alternatively, Agile works by having shorter development 'Sprints' which focus on an iterative product, focusing on releasing a packaged executable frequently and then using feedback from the previous cycle to feed the next sprint. This is a lot less risky to use on games with more newer concepts and is more commonly found in indie game development. An example of this kind of development can be seen in Minecraft, where a new playable version is released on a frequent basis with new features in each released build. (Segue Technologies, 2013)

Ideas for my game development

Moving forward I'm thinking it might be best to stick to my strengths in using Unreal Engine as I have a much better understanding of it compared to any other engine allowing me to get things done faster. However, I'm thinking as some practise trying out simple game concepts it might be beneficial to attempt some simple prototyping in Game Maker or Unity, if only for the sole purpose of representing ideas and help my understanding. I have a little previous experience using Unity so I may be able to navigate my way around the code again.
When it comes to software I am very accustomed to using the Adobe Suite and Autodesk suite as I have been using autodesk for around 3 years while I've been using the Adobe package since I was in school, so I am able to navigate through the software quite quickly using shortcuts. The problem with this software though is if we wanted to release a game after university for money using the assets we have created in with 3ds Max then we wouldn't be able to as the student license does not cover any commercial enterprises.
Some research will have to be done in that area in order to see if there might be a way we can continue using Autodesk, if not then we will have to raise fund for the full software or use free software as an alternative.

For project management, some implementation of Agile is preferred as it encourages an iterative project and a focus on keeping the game in a playable state. This kind of workflow is helped with source control, which is built around the concept of iteration. Waterfall would require too much of a commitment and might be more risky for us as we are not as well versed in actual game development, Agile would work better as it allows us to actually course correct and implement outside feedback on our games during the development.

Sources:

1. PIXEL PROSPECTOR – The Big List Of Game Making Tools (2014) Big-list-game-engines. [Online Image] Available from: http://www.pixelprospector.com/the-big-list-of-game-making-tools/ [Accessed 31/10/16]
2. SEGUE TECHNOLOGIES – Waterfall vs. Agile: Which is the Right Development Methodology for Your Project? (2013) Diagram. [Online Image] Available from: http://www.seguetech.com/waterfall-vs-agile-methodology/ [Accessed 31/10/16]
3. FRANCIS, T. (2012) PC Gamer - The Indies Guide To Game-Making [Article] Available from: http://www.pcgamer.com/the-indies-guide-to-game-making/ [Accessed 31/10/16]
4. PREISZ, E. (2012) Gamasutra - Waterfall Development Done Right [Article] Available from: http://www.gamasutra.com/view/feature/181992/waterfall_game_development_done_.php [Accessed 31/10/16]
5. KEITH, C. (2007) GDC Vault - Agile Game Development [Presentation] Available from: http://www.gdcvault.com/play/638/Agile-Game [Accessed 31/10/16]
6. GALANAKIS, R. (2014) Gamasutra - Agile Game Development Is Hard [Article] Available from:  http://www.gamasutra.com/blogs/RobGalanakis/20140219/211185/Agile_Game_Development_is_Hard.php [Accessed 31/10/16]
7. MCGUIRE, R. (2006) Gamasutra - Paper Burns: Game Design With Agile Methodologies  [Article] Available from: 
http://www.gamasutra.com/view/feature/131151/paper_burns_game_design_with_.php [Accessed 31/10/16]

Indie Developer Research Part 2 - How are indie dev companies built, and advice gained from Gamecity

Gamecity Festival (2016)

I needed to look into how indie game studios are started and how the teams are structured. For this, I headed to the Gamecity Festival; an arts festival where indie developers can go to to show their game to the public. National Video Game Arcade (2016) While there I talked to quite a few developers, all of which have different ways they have gotten into creating indie games, and this affects how each team's roles are split up into different areas.
Humblegrove is a team that is composed of two people with a background in Illustration, which serves their games art style. ZeroFiftyOne creates games on his own but has a background in computing: Button Frenzy (2016) Whilst developers like Small Impact (2016) have a larger team of around seven, including people who have been in industry for a while mixed with a few recent graduates. (Black Death)

29 by Humblegrove (Released early 2017)

From talking to these developers I have learnt that it is common for indie devs to crossover roles to what's needed to be done. As the games get larger so does the team and there is more of a requirement to specialise a little bit more. Small Impact despite being a slightly larger indie studio still has some crossover in terms of skillsets.

Most of the reason these studios seem to work so well is that each game they make plays to their skills. Humblegrove's game 29 (2016) is a good example of that because of it's gorgeous graphical art style. Because of the small size of the teams, each individual's skill or personality is reflected in how the studio operates and how the overall game looks and feels.

All The Delicate Duplicates

I also gained some other really great advice during the day which could be beneficial to me. When I asked developers what advice could they give to new indie studios a number of them said the same thing: Market the games as much as you create them. While talking about our FMP a number of them said it needs to be shown, even if it might be incomplete, as it gets people interested in possibly helping out with the rest of the development. A producer of the game All The Delicate Duplicates (To be released) gave me plenty of advice for things I should do, one of which is attending events with our games on a frequent basis. They are crucial for spreading knowledge of your game aswell as gaining valuable feedback about your game. Another point she mentioned was that of funding avenues and getting publishers, which will require some sort of business model to be prepared in advance along with a playable prototype and a game design document. I also heard this from another developer National Insecurities (2016) who also added about being careful with choice of publishers and be sure to shop around even when a deal looks certain.

My Observations

For our indie studio to work well it must do these things:

• Have a strong unique point which sets it's games apart from others on the market, whether through art style, game mechanics etc
• Marketing - All team members should have some sort of entrepreneurial quality to get their games out there , this is one of the biggest reasons indie games tend to fail is because people don't know about their games even if they might be great.
• Enjoy the process of making the games
• Have some sort of financial support system in place (I will be covering options for this in a future post down the line)

This following diagram I found on Gamasutra (2016) suggests a line of thought for deciding whether to start an indie game studio. After talking to developers at Gamecity I noticed that the decisions in this diagram are all thought about very carefully by developers and they come up with their own solutions to each stage.

Now if I were to approach this diagram with the idea of creating simple arcade-like mobile games I probably won't get as much creative mileage as I would from making the kind of games I enjoy, which are adventure games and narrative driven games. I thought before that making a game like that had to be really long and take a while to develop but I received some recommendations about games I should look, about small contained narrative games which can work up to a larger project down the line. I was told about a number of games like Thirty Flights of Loving (2012) and Gravity Bone (2008) by Blendogames, these games are very short but contain a clear story that is told very efficiently, the narrow scope allows the developer to really hone in on what matters most in the game.

I think as development goes forward I will concentrate on making more experimental gameplay of limited scope like this with a concept behind it as opposed to more arcade-like games. This should make an easier transition into my goal of doing more ambitious adventure style games later on down the line.

Sources:

1. NATIONAL VIDEO GAME ARCADE (2016) NVA Patrons. [Online Image] Available from: http://gamecity.org/patrons/ [Accessed 07/11/16]
2. HUMBLEGROVE 29 ITCH.IO (2016) 29 Screenshot. [Online Image] Available from: https://humblegrove.itch.io/29 [Accessed 07/11/16]
3. GAMASUTRA (2016) Starting An Indie. [Online Image] Available from: http://www.gamasutra.com/blogs/JeremyLam/20160414/270383/So_you_want_to_start_an_indie_studio.php [Accessed 07/11/16]
4. ALL THE DELICATE DUPLICATES (2016) Screenshot. [Online Image] Available from: http://allthedelicateduplicat.es/ [Accessed 07/11/16]
5. HUMBLEGROVE (2017) 29 [Online] PC. London/Tokyo: Humblegrove
6. DREAMING METHODS and MEZ BREEZE DESIGN (Release date to be confirmed) All The Delicate Duplicates [Online] PC. Dreaming Methods and Mez Breeze Design.
7. NATIONAL INSECURITIES (2016) Itch.Io - Disorient On The Murder Express [Webpage] Available from: https://nationalinsecurities.itch.io/disorient-on-the-murder-express [Accessed 07/11/16]
8. WILSON, B. (2016) Ben Wilson Portfolio [Webpage] Available from: http://www.ben-wilson.co.uk/portfolio/category/game-dev/ [Accessed 07/11/16]
9. PETLENKO, A. (2016) Gamasutra - Starting your own Game Development Studio One Year On [Webpage] Available from: http://www.gamasutra.com/blogs/AlexPetlenko/20160307/267328/Starting_Your_Own_Game_Development_Studio__One_Year_On.php [Accessed 07/11/16]  
10. MADSEN, R. (2014) Gamasutra - Starting an Indie Game Studio Part 1 [Webpage] Available from: http://www.gamasutra.com/blogs/RobertMadsen/20140731/222331/Starting_an_Indie_Game_Studio_Part_1.php [Accessed 07/11/16]
11. SMALL IMPACT GAMES (2016) GameCity Festival 2016 - Surviving Survival: Building a Community In Early Access [Online video] Available from: https://www.youtube.com/watch?v=FOtsHaZfM4Q [Accessed 07/11/16]
12. MARSH, D. (2008) Gamasutra - Nine paths to Indie Game Greatness [Webpage] Available from: http://www.gamasutra.com/view/feature/131952/nine_paths_to_indie_game_greatness.php?print=1 [Accessed 07/11/16]  
13. CHUNG, B. (2016) BLENDO games [Website] Available from: http://blendogames.com/ [Accessed 07/11/16]  
14. BLENDO GAMES (2012) Thirty Flights of Loving [Online] PC. Blendo Games.
15. BLENDO GAMES (2008) Gravity Bone [Online] PC. Blendo Games.

Indie Developer Research Part 1 - What is an Indie Developer?

To further clarify what I need to do going forward I need to wind it back a little, looking into what an indie game developer actually is and as importantly what it isn't. This blog will serve as a bit of an investigation into how indie companies work and what makes them successful, picking out some examples now and again.

What is an indie developer?

This is a tough one to answer! Indie games have always suffered from this weird sort of identity crisis. Indie games have historical been small hobbyist developers, working in their own time.

This was until around 2008 with games like Braid, World Of Goo and Minecraft achieving massive success. These games changed the perception of what could be done with indie development and shifted it's meaning from typically meaning bedroom developer.

Minecraft shifted cultural perceptions of indie gaming when it was released, and made people aware of the fact that it could be a commercially viable option as opposed to working under publishers.

Originally indie meant 'Independent from Publishers' but now it has grown to include all sorts of categorisations. However, a lot of people class Journey for the PS3 to be Indie, but ThatGameCompany was under a publishing deal with Sony and partnership with Sony Santa Monica for that game. An indie game could include meaning a small team, but nowadays it is possible to see indie developers with larger team sizes. It could also mean big budgets as proven by games like The Witness, which was all money reinvested by Jonathan from the development of Braid.

There is still quite a lot of debate on what is a good definition of an indie game. A good example I found on Gamasutra (Gril, 2008) refers to the fact that an indie game is mostly about trying to present something brand new and innovative. This is a game conceived of by the developers, and not passed down by other means like a producer or investor.

According to this, Indie can refer to 'Independent thought' rather than just restricting the meaning to meaning away from mainstream publishers. With this distinction games like Journey and Child Of Light can fall into this category along with games like Hellblade with it's AAA budget.

Hellblade - Developers Ninja Theory class this as a 'Independent AAA production'

So because indie games can encompass a lot of different things, where do I focus my research? To find out the kind of games I will develop I need to research examples of the kind of games I want to make, finding out about how the teams behind those games are structured, and what kind of roles do they have within them.

In my next post I will start to break down some games that I would like to make, and figure out how different development teams are built up.

Sources:

1. YOUTUBE Ninja Theory (2016) Hellblade: Senua’s Sacrifice – Senua Trailer. [Online Image] Available from: https://i.ytimg.com/vi/hL2RhY2vJes/maxresdefault.jpg [Accessed 27/10/16]
2. NINJA THEORY (Release date to be confirmed) Hellblade: Senua’s Sacrifice [Online] Playstation 4. Ninja Theory, Ltd.
3. GRIL, J. (2008) The State Of Indie Gaming [Webpage] Gamasutra. Available from: http://www.gamasutra.com/view/feature/3640/the_state_of_indie_gaming.php [Accessed 27/10/16]
4. THATGAMECOMPANY (2012) Journey [Online] Playstation 3. Los Angeles, CA: Sony Computer Entertainment
5. MOJANG AB (2011) Minecraft [Online] PC. Stockholm. Microsoft Studios. 
6. MINECRAFT FORUM (2012) Minecraft Classic! + Link to Play! [Online Image] Available from: http://www.minecraftforum.net/forums/minecraft-discussion/discussion/173387-minecraft-classic-link-to-play [Accessed 27/10/16]
7. GILBERT, R. (2014) What is an indie developer? [Weblog] Grumpy Gamer Blog. 18th April. Available from: http://grumpygamer.com/what_is_an_indie [Accessed 27/10/16]
8. BLOW, J. ANDERSON, E. ANTONIO, L. BEL, S. CASTAÑO, I. SMITH, A. SPANYOL, O. (2016) [Weblog] The Witness Dev Blog. Available from: http://the-witness.net/news/ [Accessed 20/10/2016].

Meeting 1 w Mike Pickton - Starting my research

As part of my masters I am required to write out a summary of the meetings I have with tutors each week; writing down feedback and setting an agenda and outcomes for the next week. This is to get an idea of my progress and hopefully course correct along the way as I need it. So this could be extremely helpful.

In my first meeting with Mike Pickton we discussed the direction of my research. At the moment I have summarised my work in the FMP, provided some thoughts on it, as well as continuing and providing some research on prototyping but more specifically to how prototyping should involving creating an engaging core game loop. But before I get to more work on that I need to answer some other questions first. Mike suggested splitting my research up into a few areas, which will allow me to add things relevant to each and saves perhaps unrelated things being jumbled up into one blog post.

The focus right now is to find out more about indie developers, their structure, how they work so I can use this information to come up with solution to what I need to be working on.

Below is a list of all the feedback I received, with the key three areas receiving a blog post each then others following on from that:

Feedback

Indie development

• What is an indie developer?
• Find games similar to ones I like and research them, break them down
• How is a indie dev team structured?
• What are the roles involved in an indie studio?
• Research people to find out more about their roles
• Dev blogs, GDC talks and Gamasutra for information on indie development relevant to the areas I find interesting

Technique

• How do indie developers create their games, kind of related to roles.
• Investigate what techniques or processes are involved
• What engines or software do these studios use?

Prototyping - More of an offshoot of technique but more specific to how I will be starting off my projects

• What is a prototype?
• Why do we prototype?
• When do you stop prototyping?

Objectives

• A blog post on each key area with my posts expanding on certain interesting points of research
• Measure some of the scope of games, density etc.. effect on team size, include some research into team roles of companies of different sizes
• Outcomes - diagrams, flowcharts of how indie companies work and some of their main processes

Next weeks agenda

• How to transition into starting the experimental prototyping stage
• Aim to begin practical work

Game Design! - Core game loops and rapid prototyping

A fresh start this week, finally getting into some actual work. Today I began designing and prototyping a small game. Beforehand though I dived into some research on good practices just so I know what kind of things to focus on. The first thing I looked at is the idea of core game loops.

Core Game Loop of Super Mario, the main part being the running and jumping along map. - By Ethan Stanaway https://prezi.com/gyqljrywdmzu/super-mario-bros-core-game-loops-and-reward-structures/

Core game loops are at the centre of every game you could think of. It is essentially the action you will be repeating all the time while playing the game. So essentially while prototyping for a game the best thing to do is prototype the core game loop, iterate it, refine it and perfect it because if it's not fun or at least doesn't have potential then it's not worth continuing. This makes prototyping a very good indicator on whether a game idea has any value or not.

Using this knowledge I aim to create a simple game, where I will focus on making an interesting core game loop. This should be more in the form of something interesting to play with like a toy, and when that is perfected I can add win/lose situations, scoring and other little bits which make the game feel like a whole.

I'm going to approach this as I would a gamejam, giving myself a couple of days to complete the game, if I can't make it interesting in that time then it's not worth pursuing with the idea. Below is a simple process I will be going through:

• Get game idea/theme, extrapolate themes and possible meanings and explore ideas
• Create 'paper' prototype - I will be doing this a bit different, I have my Lego Serious Play set with me in the labs so I will be creating a physical prototype of the mechanics using that, keeps things very fun and intuitive and saves me cutting up paper.
• Write down basic game loop and begin to create base code in UE4
• Refine basic gameplay and test, iterate and test again, doing small course correcting as needed

This first attempt I'm not expecting to be anything special as I'm just looking to get more of a feel for rapid prototyping in UE4 but this will still be an excellent learning process. The aim here is to fail fats and fail hard before the cool concepts to start to emerge.

Sources:

1. Tips and Lessons leanred from 7500+ hours of solo game development. Part 1: Prototyping - GameDev Reddit (2016) Available at: https://www.reddit.com/r/gamedev/comments/426148/tips_and_lessons_learned_from_7500_hours_of_solo/ [Accessed: 24/10/16].
2. GRAY, K. GABLER, K. SHODAN, S. KUCIC, M. (2005) How to Prototype a Game in Under 7 Days - Gamasutra. Available at: http://www.gamasutra.com/view/feature/130848/how_to_prototype_a_game_in_under_7_.php [Accessed: 24/10/16].
3. LLOPIS, N. (2010) Prototyping: You’re (Probably) Doing It Wrong - Games From Within. Available at: http://gamesfromwithin.com/prototyping-youre-probably-doing-it-wrong [Accessed: 24/10/16].
4. ZURKO, N. (2015) Getting The Most Out Of Your Video Game Prototype. Available at: https://www.nyfa.edu/student-resources/getting-the-most-out-of-your-prototype-game/ [Accessed: 24/10/16].
5. STANAWAY, E. (2013) Super mario bros core game loops and reward structures. [Online Image] Available at: https://prezi.com/gyqljrywdmzu/super-mario-bros-core-game-loops-and-reward-structures/ [Accessed: 24/10/16].

Original Masters Proposal

Here is my original proposal for my masters research, for my tutors to see. My Masters plan has changed quite considerably since I written this so it is quite outdated now as my project is more focused on game development, this project proposal before it quite vague and mixed in it's goals.

Project proposal

I wish to pursue a game art based study, with a focus on creating interactive experiences, improving technical skill within UE4 and developing an eye for game design. This will follow on from my previous studies at DMU where I have studied game art design and it will use some of my background in general games development that I learnt back in college, allowing me use skills from both areas.

The main theme of my investigation will involve myself looking at creating mini gaming experiences using Unreal Engine 4 with a focus on telling story through the environment, as part of my experimentation this could include using emerging technologies like virtual reality to create an even more immersive piece of entertainment for people to interact with. A series of products will be created, combining art and game design sensibilities, but will call for a high level of polish on both fronts in order to create a full experience for the players. In order to create these projects with the level of polish I want I will have to learn how to streamline my workflow, learn the game development pipeline more in depth and learn project management methodologies e.g. Agile Scrum.

The final project will be a joint venture with fellow student, Amber Jamieson, where we will prototype and develop a small game. During this project I will be creating the base game design and handle the technical side of the project developing a playable prototype while Amber will focus on the art direction and asset creation. This will work towards our goal of developing an indie game studio, where we will have to use a broad range of skills in order to make a stand in the market.

Research resources:

http://www.techradar.com/news/gaming/the-witness-and-firewatch-are-the-sorts-of-slow-paced-first-person-experience-vr-needs-1314873

https://www.youtube.com/watch?v=bNqg9gCckOk&list=LLXh_4ywP0sn04NpETiP_UMw&index=62 UE4 - Ocean Exploration prototype Youtube

http://formfiftyfive.com/2013/12/interview-with-ken-wong-artist-designer-of-monument-valley/

Some thoughts on Guiding Sprites, important notes about planning a gamedev project

Hi there, as you know earlier this year as my last project for my game art course at De Montfort University I created a puzzle adventure game with Amber Jamieson and Hazrat Bilal called Guiding Sprites. For those who don't know, there is a week by week post on this blog on the development, but for a quick taste of what we created here is a little youtube teaser:

As I head into my masters degree focusing more on general game development it was advised to me by my tutor that it might be a good idea to cast my mind back and see what I can learn from the experience, seeing as it was our first complex game development project. Guiding Sprites was massively ambitious for the time that we had during the FMP, and was actually planned as a whole game with just a vertical slice created just for the FMP time frame. We would then use the vertical slice as a way to pitch the game to possible investors in order to fund the rest of the development. As I said that was the plan, and sometimes the plans don't always work out.

Because of the timeframe we had a lot of issues during the development of the vertical slice. The main problem is that gameplay and art constantly got in the way of each other and we had to sacrifice a lot of features, this also led to slowdowns throughout the project which in turn led to the shifting of plans. Usually in game development a game design or prototype is made before art assets are ready to go, but because of the time we had on the project we just had to push ahead regardless and work. A lot of this could be down to our relative inexperience aswell, at the time we weren't really knowledgeable on how the game development project management actually works, if we had some sort of source control or project management system in place it would have gone a lot better.

We saw the game as being almost like a short novel, with quite a short playtime but despite that the environments and interactions on the way would be quite complex, in the 20 week time frame we had for the FMP that definitely wasn't possible, but creating a demo-like section of that we thought could have been. An estimate that we come up with is that if we continued the game through to completion it would take around 2-3 years. If we were to continue that during our masters now, my feeling is that the same problems will carry on, because we jumped into the deep end and need some other experience and skills first before we would be able to do a large project like that justice.

I am still proud of what we managed to do during the project, we were the first students to design and create a playable game of this kind, but moving on we need to build on what worked and what didn't. This mainly involves learning new planning techniques or adopting some kind of pipeline to make the game development process 100x as efficient as what it was during FMP.

Moving on

What do we do next to avoid the same issues? The source of the problems we had can be put down to conflicting gameplay and art, but that is also something that results from the planning of the project. The scope, the included features, even the art style have a certain budget on time depending on their complexity. Gameplay needs to be done before art as opposed to starting both at the same time otherwise there will be a wait on the gameplay to have a playable section before assets can go in. Juggling assets between people using hard drives also slows down development; as only one person can work in engine at a time (mainly myself) work would have to be split between importing in assets and actually fleshing out the game. To counter this issue proper naming conventions and source control must be managed, which is the industry practise.

Also a more defined approach to the roles within the team, this is usually helped when source control is used as then it takes the burden away from the 'engine person' to setup their imported assets correctly like animations and materials. This just makes everything a bit easier and means that there is no confusion about each person's role in the team. Having someone who jumps between working in UE4, then going to concepting, then back to modelling isn't very efficient unless it's more planned out. It is better to have someone on the team who has those dedicated skills for each area, depending on scope. This isn't necessarily the perfect way to do it, but for me and Amber it works a lot better.

Another thing to make it more efficient and take away some of the potential issues is using a proper naming convention and file structure. This became a major problem later in the project where the asset list was building up and things needed to go in, but I was unsure what was what because I could see different naming conventions in use. I found this fantastic guide for making UE4 projects more consistent created by Michael Allar https://github.com/Allar/ue4-style-guide, it basically covers every single asset type within unreal and provides a prefix for them, aswell as correct suffixes for textures and the correct folder structures within unreal. Having a massive document like this is hugely beneficial and takes time away from making trivial decisions about naming things, removing most issues that we got before due to not being able to find certain files. (Allar, 2016)

Seriously, if you are working in UE4 consider using this document as a base to plan with, it makes everything 10x easier, also if you are working on a marketplace item they will expect this kind of naming convention to be used.

Mainly then, to improve in our next projects we need better planning. Better project structure. To be wary of scope and a bit of foresight to the effects of what adding or changing something in the project can do for time. Below are the main points and some things I will be looking at using properly over my next few projects:

• Practise project management methodologies - Things like Agile, Scrum or waterfall can really help a project move forward, and makes it easier to plan new things and work around possible hurdles.
• Source Control - Git or Perforce, something to make sure that all the people in the team can contribute to the project at the same time without having to wait on someone all the time for a certain piece of work to be done in engine. Perforce is preferred as files can be 'Checked Out' so they can't be edited by anybody else currently using the engine file.
• Naming conventions - A lifesaver, saves so much hassle and grief when a lot of files are being moved around or added. If everything is where it's supposed to be it makes the level design job a lot easier.
• Keeping an eye on scope - this is more something which can be avoided with proper project management, as well as being generally critical of how long things would take - you get more of an idea of this as you do more projects.

Generally though a lot of this can be improved through working on a lot of smaller projects and getting better at game dev. It's not easy, but maybe taking a step back and making some smaller games can help focus efforts on the process, which could be scaled up later when they are ready for larger projects. That is essentially my next goal: To create a load of really small, experimental projects in which all these skills could be practised and honed, before moving on to bigger things again. 

Then maybe further down the line we could come back to Guiding Sprites and make the rest as a completely planned and polished effort... as a possibility. 

Sources:

1. ALLAR, M. (2016) Github - UE4 Style Guide [Webpage] Github. Available from: https://github.com/Allar/ue4-style-guide [Accessed 21/10/16]

2. JAMES BRODERICK DESIGN (2016) Guiding Sprites - FMP Trailer [Online video] Available from: https://www.youtube.com/watch?v=Cy_ud2AIDUw [Accessed 21/10/16]

Jam Slabwich

Over the summer I have been working on bits and pieces although not much has really been in a form that I can really show; Ideas, concepts, brainstorming for random things etc. But I have made progress with a couple of things, mainly involving playing around with Unreal. :)

During the summer I have been chasing down different concepts for games I want to make, drawing out diagrams of play mechanics, learning about all sorts of things from 4 layer narrative structure to how developers build certain types of games. One person I ended up watching a lot of material of was Jonathan Blow, the developer behind games such as Braid and The Witness. (Blow, 2016) He has a lot of talks online about a whole range of things about game development and have been trying to take a lot this knowledge. It's the dev blog of The Witness though where I found some interesting things I wanted to tryout and work on, that I could apply to future games...

Slabs

Jonathan created a little greyboxing tool dubbed 'Slabs' for use in prototyping puzzles in The Witness and blocking out the world. it essentially works by giving you cubes in which you can drag one side at a time without moving any other part of the cube, almost like Push/Pull in Sketchup or something, and this works locally to the slab object so you will never get any weird skewing of the mesh.

This was later adapted by one of the game's artists Eric A Anderson on his next game Obduction. (Cyan Worlds, 2016) Where a similar system was implemented into UE4. I was interested in a possible use for my own walking-simulator type game ideas I had at the time so I sent him an email asking about how it works and he came back with really helpful information. I also asked him how tools like this differ from using things like BSP in production, with BSP being quite dated and not allowing a lot of flexibility and control. Slabs is simple in how it works but it doesn't need much else.

After that I wanted to see if I could make this into a tool I could use for the ideas I'm working on, allowing me to potentially prototype even quicker. So I went to work creating a blueprint prototype in UE4 and I created a short video of it in action:

I shared the video and people were quite enthusiastic about what it could do despite it's simple nature. There were a suggestions for adding in support for different meshes, instanced static meshes, uniform scaling. Cool stuff that could work on this, but for some of this I would need to delve into C++, something that I haven't really done before. Also if I add custom mesh support and all these other functions it becomes less of a individual greyboxing tool and more of a new mode that allows you to scale any mesh in that way, very similar to what Epic have already implemented in the VR editor, so I would need to rethink how I would approach the system unless I have the blueprintable slabs then a C++ component which features a full toolset for all static meshes.

I spent a bit of time fixing a problem with the pivot, which always needs to be at the center of the slab. Fixing this issue taken a lot longer than I thought but now that's it's fixed using slabs is a lot more intuitive.

So that is one thing I have been working on, I will come back to Slabs soonish as soon as I have a clear plan of what I am doing for my masters, I will be hopefully testing out some slabs stuff soon as I need it for future projects.

Top down grid based game

This is something I was working on when I couldn't get slabs to work, a simple grid based movement system. I was thinking about classic RPGs and their movement systems and wanted something like that in unreal but represented in 3d. A little experiment that I could build on at a later time.

UE4 Megajam

So a bunch of us taken part in the UE4 Megajam last week! Myself, Amber Jamieson, Zhane James-Marshall and Dominic Mathuse. AKA The Trash Pandas! (Amber's idea) The theme was 'Settle The Score' so we interpreted that in a owing someone money kind of way so 'Split The Bill!' was created.



You can view the submission post HERE! You can download the game and see what you think.


"Split The Bill is a monetary puzzle game where you have to settle the bill at the end of a meal. The goal is to make sure everybody has paid their correct share while trying not to make anybody unhappy with the contributions. You can’t please everybody! But you have to try your best. Or you can play dirty and try and pocket leftover change for yourself." 

The game is a bit incomplete and the third level is completely unfinished but as our first attempt at a game jam I thought we did quite well and we were quite ambitious with the actual design. The plan going forward is to take part in a load more game jams, trying to get faster and more experimental with the designs.


Those are the biggest things I have done recently, there should be some more experimental pieces soon as I move onto creating a series of rapid game prototypes.

Sources:

1. BLOW, J. (2014) Jonathan Blow's Home Page. [Webpage] Available from: http://number-none.com/blow/ [Accessed 20/10/2016].

2. BLOW, J. ANDERSON, E. ANTONIO, L. BEL, S. CASTAÑO, I. SMITH, A. SPANYOL, O. (2016) [Weblog] The Witness Dev Blog. Available from: http://the-witness.net/news/ [Accessed 20/10/2016].

3. THEKLA, INC. (2016) The Witness. [Online] Playstation 4. Thekla, Inc.

4. CYAN WORLDS INC. (2016) Obduction. [Online] PC. Cyan Worlds Inc.

5. BRODERICK, J 'Jbroderick'. (2016) Epic Megajam Submission Thread - Post #180. [Online forum post] Epic Games. Available from: https://forums.unrealengine.com/showthread.php?124973-Epic-MegaJam-Submission-Thread&p=608922&viewfull=1#post608922 [Accessed 20/10/2016].

6. JAMES BRODERICK DESIGN (2016) UE4 Top Down Grid-Based Movement Prototype. [Online video] Available from https://www.youtube.com/watch?v=kaE__ouyHMU [Accessed 20/10/2016].

7. JAMES BRODERICK DESIGN (2016) UE4 Slabs - Blueprint version prototype [Online video] Available from https://www.youtube.com/watch?v=gnQ7FVs15zk [Accessed 20/10/2016].

8. JAMES BRODERICK DESIGN (2016) UE4 Slabs - Pivot centering, other mesh support and volumes [Online video] Available from https://www.youtube.com/watch?v=HFuwIoybckE [Accessed 20/10/2016].

A bit of a break, masters degree and recognising the obvious.

Hey all!

I'm back from (another) long break from my blog writing that I keep promising to keep up with. Sometimes I just find it easier to post smaller updates on Twitter and get things out there quicker, the only thing is with that is that it's usually too concise to actually go into any serious, meaningful reflection about my work.

Hopefully now I should have more of a reason to continually update this blog into the future, as I have committed to studying a masters degree at DMU.

The masters degree isn't in Game Art like I have been studying for the last 3 years. The university does a course called 'Independent Study' which essentially allows us to tackle whatever subject we want as a form of personal research, within reason. So there is a lot of potential to really expand on what I want to do an make something beyond game art before I jump into industry.

Originally my plan for my study on the masters consisted of making a series of smaller polished projects, all somewhat unrelated but requiring me to make a lot of environments, dealing with technical aspects and game design. Some of these projects may have also dealt with VR as an experimentation. All of this before moving on to create a game at the end with Amber Jamieson onboard as the artistic side of the project. 

These projects were heavily ambitious and didn't leave me a lot of room for experimentation, so I changed my focus slightly. I began to realize recently that I really enjoy a lot of different things rather than just environments and strictly artistic roles did not suit me. After a bit of work on my own stuff during the holidays (I will cover those things in another post) I started to think a technical artist was more within my reach rather than aiming at some kind of environment artist/game artist role. I get bored of doing one thing quite easily, and I would rather work on games where I can have a bit more of a creative crossover to other areas.

I started to work technical art into what I was doing during my masters, but still focusing towards making a game as an end goal. The idea being that the technical art skills I will learn over the year will help with making the final game be as good as it can be. Creating tools and pipelines and anything else that could help with that goal.

We had a presentation yesterday where we had to show our concept for what our masters study project will be. My new focus was: Can an Indie development studio be started from uni? As it turns out the way I phrased my question gave out the wrong idea of the scope of my work, it implied that I would be investigating a load of different things which may not be relevant to me at all. The main point being that it would require me to search for an argument to the point that making a studio from uni is possible. However, that would take away from the main goal I have at the end of the masters which is to actually make a game.

So what do I do? The tutors made a lot of recommendations on how I should actually word the proposal. One idea was to simply add 'How' in front of it so the answer to 'How can an indie developer studio be started from uni?' would be emphasised more on taking steps to making that a reality.

What now?

The other main thing that was brought up can be evidenced by the changed banner at the top of this blog. Instead of Game Artist or Technical Artist you may notice it says Game Developer now. I have kind of just recognised and accepted the obvious that I am more a game developer than anything else and most of my creative thinking goes towards making game experiences rather than focusing on a very particular area. I have my strengths on the technical side of things, but that is something I should build up as a way to develop my own games rather than focusing solely on the technical artist role.

This is something I have battling with for a bit, and the reason I had issues with the presentation. Instead of trying to balance two different roles coming out of uni I should focus on the one which interests me the most and put all my eggs in one basket. I have an interest in the game making process, this can be seen throughout projects like Guiding Sprites and Off The Map, and the technical things are just part of the things that I do.

Moving forward I will be experimenting a lot more with game design, project planning and anything else that is important in the world of small scale game development. After another long talk with Mike we came to an agreement that a lot more needs to be done to figure out what kind of 'indie dev' do we want to work for? A small team of 4 or 5? Or a mid-sized developer? A bit of an investigation into what they do differently and then tailoring my masters work toward achieving that kind of position. So that means a lot of networking over the next few months!

So get ready for a lot of really fun game-dev stuff on here from now on, I'm pulling no punches! I'll be making another post shortly about my recent game jam entry 'Split The Bill! for the UE4 Megajam event, a game-jam run by Epic Games where we had a week to create a short game. (Paschall, 2016)

I will also do a little bit of a write up on a small tool-set I'm working on called 'UE4 Slabs'

I have included my presentation for viewing here: Project Proposal Prsentation

See you next time,
James


Sources:

1. JAMIESON, A [Weblog]. Amber Jamieson Game Artist Blog. Available from: http://amberjamieson.wixsite.com/gameartblog [Accessed 19/10/16].

2. PASCHALL, A (2016) Epic Megajam 2016 Announced! [Weblog] Unreal Engine. September 8th. Available from: https://www.unrealengine.com/blog/epic-megajam-2016-announced [Accessed 19/10/16].