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]