davidbaker1095-blog

[davidbaker1095-blog]

Event Review: Game Development Brisbane: The Secrets to Creating an Indie Game Franchise - A Narrative Design Approach

The first Game Development Brisbane presentation for 2018 featured Christy Dena at the event's new location of JMC Academy. Christy is a transmedia expert. She formerly served as the National Chair and Development Coordinator of Games at the SAE Creative Media Institute and is now a Senior Lecturer of Games. Christy writes, designs and directs apps, installations, live games, tabletop games and events.

Today, Christy's presentation focused on how to create multimedia game franchises from the perspectives of indie developers. For Christy, experimentation with multimedia offerings began early in her career when she was writing a novel. She learned about the prospect of chat bots and the potential for designing their personalities. Christy experimented with the idea of creating a chat bot with a personality and knowledge base similar to one of the characters from her novel. So began a journey to find out why players engage with multimedia franchise offerings.

This presentation was of interest to me because, in the past, directors at Australian Game Development Studios had suggested to me that they believed "content as a package" was the way that the industry was heading. That is to say that entertainment would be offered across different forms of media to allow consumers the continuous engagement with content that many crave from their favourite franchises. My hope was that Christy's presentation would provide more insight into how this would be done.

Christy began with giving some context as to how creators can go about establishing franchises and what the current industry consensus is on how best to do so.

There are two general approaches that creators can use to go about creating a franchise. They can attempt to plan out a franchise proactively or they can attempt to expand an existing product into a franchise retrospectively.  Christy suggested that, in the context of indie game development, most creators focus on creating a great individual product first and then attempt to retroactively expand it into a multimedia franchise later if it achieves appropriate levels of success. A good local example of this approach would be HalfBrick's Fruit Ninja franchise. Starting with a massively successful mobile app, the franchise has now expanded into a YouTube Red video series and a movie is in the works.

During the Q & A at the end of the talk, Christy couldn't think of a good example of an IP that was set up proactively to create a multi-media franchise successfully. Even examples of big franchises such as Ubisoft's Assassin's Creed and Square Enix's Final Fantasy series had introduced several instalments before they expanded their brands into the multi-media landscape retroactively. All this means is that successful endeavours at proactive franchise creation are extremely rare.

Aside from the generally favoured approach of retroactive franchise development, Christy raised several other industry consensuses that exist. Generally, tone, themes and style should be maintained across different media. It seems that this is to allow consistency and increase the odds of player satisfaction when moving from one media to another. One technique that creators use a lot at the moment is a "continuity kiss" between different media offerings. An example of a continuity kiss would be where something is mentioned in one media, for example, a planet or species in Star Trek, and then that element is fulfilled in another media, such as a Star Trek game being set on that planet with those species. How is this all kept consistent? According to Christy, Transmedia Bibles are highly recommended by the industry. These bibles act as references for things like tone, themes, style, and product lore.

One thing that the industry does not like at the moment is adaptions. This is because many past adaptions have not been received well by critics or consumers. In the context of video games for example, I can think of many film adaptions that are generally not viewed positively. The Mario Bros movie is a big example. From what I have seen, the recent Assassins Creed movie is another example of an adaption that didn't necessarily hit the mark with critics or consumers. Christy believes that this negative industry perception of adaptions isn't necessarily a healthy one. Just because past examples where implemented unsuccessfully doesn't mean that the concept as a whole is bad.

The biggest thing that differentiates a successful franchise from an unsuccessful one, according to Christy, is how well the creator has been able to think empathetically about the consumer's motivations for engaging with their offerings and implemented their insights into it. One book that is a good resource in understanding this line of thought, according to Christy, is Steven Pressfield's "Nobody Wants to Read Your Sh*t". The idea of empathetically thinking as a creator is also supported by Brian Upton, a designer of the Ghost Recon and Rainbow 6 series.

At the moment the industry mostly focuses on world building when creating multi-media franchises. Christy believes that the focus should instead be on what the franchise promises the player, why they engage with it and what they are thinking. This should be true, for example, when designing any scene for a film or section for a game. What is the player's state of mind going into this sequence? What are their expectations? What have we promised them up until now?

This approach was particularly interesting to me because it generally mirror's methods and philosophies advocated by people like Stephen Covey for how to effectively interact and negotiate with other people generally. If the point of a product is to give a consumer some value, it would be best to understand what value that consumer is looking for and what their state of mind is when you attempt to give it to them. It doesn't matter how well you build your world, if that goes against the expectations and desires of consumers then it would ultimately go against the goal of bringing consumer's into each of your offerings and keeping them there.

The remainder of Christy's presentation outlined several of the reasons why consumers might engage with a given franchise offering.

Generally, there are five consumer motivations that the industry has picked up on. These are: • Personality; • Spectacle; • Novelty; • Social; and; • Nostalgia.

Consumers are drawn to big personalities that they are familiar with. This is especially evident when considering that some of the most highly paid movie actors such as Robert Downey Jr, Adam Sandler and Vin Diesel can pull in many consumers just because of their association with a film. Another way that Personality motivation can manifest is where consumer's engage with a franchise because they really like it's characters.

Spectacle is all about the epicness that big franchises offer. Think about The Lord of the Rings and Transformers. The sight of 100,000 enemies charging at a castle wall, awe inspiring landscapes, giant robots fighting each other and really big explosions are all things that have high spectacle value.

Novelty is the implementation of something new or intriguing. What would happen if a cat was the president for a week?

The social element, something that Christy suggested was the least understood by the industry. Is based around the human desire to do things with others and enjoy doing so.

Nostalgia is something that draws on positive past experiences we have had and makes us want to engage with similar experiences. An example that Christy gave was the avalanche of 8-Bit games that are produced.

Aside from these commonly recognised motivations, Christy has identified a few more that are particularly important to consider when creating multi-media franchises. These are: • Revealing; • Reliving; • Inhabiting; and; • Moulding.

Revealing is about answering the question "What more is there?". It is a representation of why consumers do respond to the world building currently focused on by the industry. Revealing relies on the consumer's desire to relate to different characters, the plot and the environment of a franchise and explore them.

The Reliving motivation, which is similar to the nostalgia motivation, is about reliving the type of activities that we enjoyed in the past again. For example, fans of the First Person Shooter genre often buy into new IPs because they are happy to relive the gameplay that the established FPS mechanics enable. Remakes are often about consuming the same thing again in a slightly different form. A good upcoming example is that Life Is Strange is being adapted into the movie form. The cinematic and linear nature of Life Is Strange lends the franchise to this type of adaption.

The desire to inhabit, and live in, the world of the franchise is often delivered in two different ways. You can export the world of the franchise and place the player into it or you can put elements of the franchise world into the player's world. Examples of exporting include theme park attractions such as the Avatar exhibit and virtual reality experiences where players feel like they are literally inside a representation of the franchise world. Examples of importing include action figures and Augmented Reality experiences. Both of these bring elements of the franchise world into the player's world. It is important to be wary of continuity when engaging with the consumer's motivation to inhabit. Consumers don't generally engage with attempts that have inconsistent tones, themes and styles compared to the original product. Where done well however, taking advantage of the desire to inhabit can be hugely successful. Remember how big Pokemon Go was?

Moulding is the desire of consumers to be able to adjust the narrative or world of a franchise. The best example of Moulding can be seen again in action figures where consumers have the opportunity to re-enact elements of the franchises narrative but also have plenty of opportunity to adjust it and create their own stories. Video games also provide plenty of opportunity to satisfy the moulding motivation.

Finally, Christy described the importance of establishing a franchises values. These are the things that your franchise offers players that should stay the same regardless of the medium of presentation. These are usually key elements of a Transmedia Bible. The examples Christy gave focused on the 2012 game Journey. Some of the design values that Journey has as a product included the concept of pursuing a spiritual life, the desire to be helpful, the desire for mature love and the development of Wisdom. If a Journey offering was offered in a different media, it would need to maintain these values to provide appropriate continuity.

The values of your franchise, as well as how you plan to meet the player motivations of revealing, reliving, inhabiting and moulding can be brainstormed via a resource offered by Christy on traversalspiraltoolkit.com.

To conclude, I think that what I got most out of this presentation was increased appreciation for empathetically designing your franchise offerings to meet player motivations for engaging with your offerings. In regards to my original hopes of better understanding franchise offerings, I feel that I better understand why franchises succeed and fail as well as have a better appreciation of where some types of media offerings can be valuable. As far as the potential of close to 24-7 franchise content goes, I have an appreciation for the necessity, along with the difficulty, of maintaining consistency with the values of the franchise and ensuring that new offerings provide value in line with player motivations when building such offerings.

[davidbaker1095-blog]

Event Review: Game Development Brisbane: The UI Artist’s Survival Kit

This month's Game Development Brisbane presentation was run by Wren Brier. Wren is a senior artist at Well Placed Cactus and previously worked as an artist at Halfbrick on titles such as Jet Pack Joyride. The presentation was focused on overcoming the problems with the linear UI creation process for mobile games. In this case, these problems aren't answered by creating a new high level process but are instead answered by utilising appropriate tools available in packages like Photoshop. As someone without a mobile UI background, I was able to follow along with the presentation using my existing understanding of UI design, Photoshop and problems with traditional linear processes. While I believe a practicing UI artist would have been able to take more from the presentation due to relatability to their own work and contextual understanding, there is certainly value to be taken without that insight. As someone with minimal previous exposure to the work of a UI artist, I did gain contextual understanding which is what I was ultimately looking for.

Initially, Wren outlined the process of UI creation she uses and some of the problems she has discovered with it. Firstly, the UI artist, the designer or both together map out a flowchart of how each scene transitions into the next. This gives an idea of which scenes are required as well as the UI elements required to facilitate the intended transitions. Secondly, a rough sketch is completed for each unique UI state in these scenes in order to get a feeling of the layout and look of those states. These sketches are rough in order to allow for quick adjustments and limited loss of work as the UI's physical design is adjusted to fit the vision of the designer. Thirdly, a wireframe version of the UI is created in Photoshop with more detail including colour to give a better representation of what each state will look like. Once this is finalised more detail is added to each screen asset (e.g. buttons or message boxes) to create something close to the "final version". After this version is finalised, it is replicated in game. One thing I found interesting about this process was that the entire mock-up process was done in Photoshop with only the final versions making their way into the game engine. I suppose that this would most likely be the case because it allows artists to rapidly undertake their role of creating visuals for the game inside the familiar environment of Photoshop without straying into the game engine environment itself as much. I had always assumed that more work would be done in the game engine as it would create a more exact representation of the final product with all elements (including code etc.) in action. This leads me to think that the difference between the final Photoshop mock-up and the in game version, in the visual sense, is usually less than initially presumed.

Two big problems with this process, in application to the mobile app space at least, are that it doesn't easily accommodate for the different screen sizes and resolutions encountered in the mobile space, aptly named "device hell", and it doesn't accommodate the regular changes to the "final version" associated with agile game development methodologies. Wren tackles these issues, and keeps her mock-up quality high, by making sure that here work satisfies 5 criteria. Wren's mock-ups must be:

- Readable; - Changeable; - Relevant; - Testable; and; - Useable.

For the rest of the presentation, Wren outlined and demonstrated several tools available in Photoshop that she uses to meet these criteria.

First up were artboards. This feature allows the artist to have multiple separate canvases next to each other in one file. This feature seems to lend itself towards the Wren's readability criteria as it allows the artist to see different screen states next to each other and should even give an idea of screen transitions.

Next was device preview. This feature allows you to send your mock-ups to a mobile device in real time. This not only allows you to get an impression of what your design actually looks like on the device but it also allows you to see changes instantaneously. This tool looks like it would help in several of Wren's criteria including readability (Is the text size/font/colour actually readable on the device?), changeability,  testability and usability (Are the buttons big enough on the actual screen?).

After that was Proof Setup. Proof setup allows you to see how your mock-up looks in greyscale, to measure the contrast, and what it will look like to people with different types of colour blindness. This tool covers readability again but is mostly helpful for useability. Does the contrast of my UI elements let them stand out as much as I want them to? Can people with colour blindness play my game? All of these questions are certainly worth answering.

This was followed by Smart Objects. Smart Objects where particularly important as they related to every tool after them. When an object on a mock-up is a smart object, it references a source object outside the mock-up rather than being independent. This means that, if the source object was edited, every smart object that references it would change too and therefore wouldn't have to be changed one at a time. It also means that, where usually if an artist shrinks an object in a mock-up and then expands it again the resolution is effected, no such effect occurs for the referencing object. Wren did advise us that it is better not to nest one smart object within another in a mock-up because the inner smart object is known to stop updating itself in that case. Smart objects certainly allow for increased changeability and usability within a set of mock-ups.

Penultimately, Wren discussed Photoshop Libraries. Photoshop Libraries basically act like cloud storage for smart objects as well as things like colours and fonts. This means that you can use stored smart objects across files, across Adobe programs and across devices. Wren recommends putting all smart objects in Photoshop Libraries as it greatly increases potential useability.

Finally, Wren covered Generating Image Assets. This feature allows artists to create image assets as you work by adding file extensions (e.g. .JPG, .PNG, .GIF etc.) to the end of layer names or layer group names. You can also specify different ways the assets will be saved through adding more elements to the layer name. You can scale the asset, change the asset's settings such as alpha values or even specify two different assets to be created from the layer at the same time with differing settings (such as a .PNG at normal size and a .JPG at double size with half alpha level). This feature is great for improving usability and changeability of your smart objects.

At this point Wren's presentation concluded. I'd say this presentation was certainly valuable for a non-UI artist as it helped expose the context of the UI artist's work and the UI artist's principles. It also exposed one to the processes and problems that UI artists face in their work and how these problems are being solved. For a UI artist in the audience, this presentation would be even more valuable as it would provide ideas on how to improve the effectiveness and efficiency of their day to day process and how to better utilise the tools at hand.

[davidbaker1095-blog]

Event Review: Game Technology Brisbane: Introduction to Game Audio Implementation

This month marks the first time I have attended a Game Technology Brisbane meetup. A sister series of the Game Development Brisbane meetups, they usually occur on the same day with Game Tech Brisbane running first and Game Dev Brisbane running immediately afterwards. The difference between the two is that, whilst Game Dev Brisbane seems to focus more holistically on all of the facets of Game Development in general, Game Tech Brisbane focuses on exposing participants to the specific technologies used within game development by different people. In my quest to understand the variety of fields associated with game development, I decided that it was time to expand my event attendance to Game Tech Brisbane events as well.

This month's Game Tech Brisbane presentation was run by Ricardo Pujol, a sound engineer and music composer. Ricardo's talk acted as an introduction to the overarching elements of sound implementation in games before going on to discuss some of the technologies used to achieve it. This presentation was of interest to me because even more than in the case of art asset creation, I had not had much exposure to how sound assets were created and implemented into games. In previous projects, it was the area I simply trusted the experts to deliver the end product without much understanding or interaction on my part. It was a shame because I really enjoy a game with top quality audio and I feel it certainly can be the difference between a good gameplay experience and a great one. Now was the time to reduce my ignorance.

The section of Ricardo's presentation that introduced the elements of sound implementation focused on the ideas of recording, synthesis and post production work.

As a prelude, Ricardo discussed the difference between sound and audio. The difference is that sound is the thing we are trying to create while audio is the wave form representation of sound that we as developers interact with. Sound sounds. Audio does not sound. Sound is what the player experiences and has an expressive component to it that allows us to relate to something or feel something. This difference is subtle but is certainly one that I am glad to understand now as it will help with interacting with, and correctly understanding, sound professionals in the future.

When discussing the idea of recording, Ricardo mostly focused on the area of Foley. Foley involves creatively interacting with  objects and environments in the real world, in front of a mic, to record resulting sounds that can be used as representations later. An example would be where, in films, you had some guy punch a cabbage to create a sound for playing over the choreographed fight scenes later. Foley is all about experimenting with different materials and textures to see what interesting sounds could be created. One tip that Ricardo gave us is that it is often a good idea to record sounds at different distances from the mic as well so that the difference in distance wouldn't have to be totally simulated later. The idea of Foley was certainly interesting to me because of the opportunity to make your game sound unique. In my experience, especially with low budget teams, Foley becomes a last resort because it is just easier and cheaper to download stuff made by others, even if it's not exactly what you wanted. Being conscious of the balance between being economical and being exact that my team's sound experts engage in will surely be helpful in the future.

Seemingly the other side of the coin to Foley, synthesisers are electronic musical instruments that create and modulate sound. Looking at the various representations Ricardo showed us, they pretty much looked like keyboards with a bunch of extra knobs, sliders and buttons above the keys. According to Ricardo, the sound created by synths and Foley are usually pretty different from each other but they can then be combined in heaps of interesting ways.

Post production is where sounds are edited and put together after you have created them with synths and Foley. The mixing of the audio eventually results in the output of a sound file to be used in the game. These files are generally MP3 files, WAV files or OGG files.

After explaining the ideas of recording, synthesisers and post production, Ricardo discussed some of the elements that sound professionals consider when creating sound for games.

Firstly, the platform that the game will be on greatly effects the type of sound that can be used. Things like the reasonable data size of the sounds changes between platform and this restricts the number of sounds that can be created, the appropriate dynamic range of sounds (the difference between how quiet and how load sounds can be) and the quality of sounds (more vs less detailed sounds). Think about the difference between the AAA console games and mobile games. Mobile game sound is often set to mono over stereo, halving the number of tracks in use, because the focus is often on one area in front of the player and they don't need to have the positional awareness associated with stereo or surround sound that we often see in console games. When using mobile phone speakers, the ability to hear all sounds at high dynamic range is often harder because the speakers are too quiet or unclear. The quality of sounds can also be lower in mobile games because users of the casual games prominent in the mobile gaming space aren’t expecting or demanding amazing audio with their games.

Secondly, the type of game effects the sound that should be created as well. Is the game story based where dialogue should be prioritised? Does the game demand a huge variety of unique sound effects? How important is the quality of the music to the experience? Should sound adapt to the different situations in the game? Does the game need high dynamic range such as where horror games have a lot of quieter sounds and atmosphere as well as loud sounds in action orientated segments? These are all questions the sound professionals need to consider to fit the sound created to the game itself.

After hearing all of this content, and gaining a much better understanding of the environment that sound professionals operate in, Ricardo began discussing the different technologies used to integrate sound into games.

There are three main methods of sound integration that Ricardo covered: scripting, plug-ins and middleware. Scripting involves writing some code for your game that specifically controls how the sound in the game works. Scripting is possibly the most powerful and is the most customisable of the three methods because you can basically do anything you can think of with enough coding experience. It is however intimidating to a lot of people because of how technical it is. Plug-ins are software that can be added to existing programs so that you can access new features in that software. In this case, the plug-ins will mostly be for the game engine in use such as Unity or Unreal. Plug-ins can be quite powerful and can offer a wide range of possibilities to your sound integration options but they can also be unstable due to poor implementation or lack of updates to match the software they are adding to. Finally, middleware are third party programs that can be used to create and edit your sound before integrating the results into a game engine. The middleware approach is, according to Ricardo, the favourite among sound professionals because it is relatively powerful and approachable to use.  Middleware offerings such as Wwise and F Mod offer a lot, if not all, of their functionality for free for projects with low revenue so they are a good option for low budget and indie teams.

For the final part of the presentation, Ricardo covered more specific topics of sound integration. These included various ways sounds could be integrated into the changing and uncertain environments of games, the sound integration environment in Unity 3D and a quick introduction of generative sound.

Generally, there are several methods used to integrating sound into the changing and uncertain environment of games. The music, sounds and audio mic can be made to change when game states change. For example, the sound environment during daytime sections of a game might be very different to night time environments. Sounds can be made event dependent. For example, in a musical track, extra drums could be faded in as the players health drops to create a sense of intensity. Random containers can be used to randomise routine sounds like a step sound to establish variance. Sequential containers can be used to do the same thing in a non-randomised way. Blenders can be used to mix the volume of sounds from different sources according to the player's proximity to them. Finally, audio mixers can be used dynamically to change the focus on different parts of the sound and add effects to it.

In regards to the current sound implementation environment in Unity 3D, a basic audio mixer was finally added recently. This along with a platform for effects plug-ins and a "Reverb Zone", makes up the current first party offerings. In Ricardo's opinion, it is still the case that you would need to use scripting, plug-ins or middleware to consolidate Unity's first party offerings in order to create an adequate sound integration environment.

Generative sound is something that Ricardo is very passionate about. Essentially, it uses a plug in (in this case one called Pure Data) to create sounds in real time in game using algorithms. This approach does work in Unity 3D with the "Heavy Uploader" and "Pure Data" plug-ins combined but this can be unstable. The idea of the approach is that you create a tree for your sound logic to follow and, depending on which parts of your scripts are called in the rest of the game's code, you call various effects on your sound such as various levels of modulation. The example Ricardo used was that, in a game were the player holds a lightsabre, the pitch of the lightsabre can be made higher while the player was moving to create the traditional lightsabre swinging sound.

That was the final topic of Ricardo's presentation. I certainly found the overall presentation useful because of how it introduced me to the various stages and methods of sound implementation and how it put this content into a context I was familiar with, in this case Unity. I feel like generally this knowledge will help me in the future both in interacting with my team's sound experts and possibly in my own projects when I experiment with sound.

This was the first of the two presentations I attended this month. My review of the second, a Game Development Brisbane presentation run by Wren Brier, will hopefully be up later this week.

[davidbaker1095-blog]

Event Review: Game Development Brisbane: Lessons Learned from Running my One-Person Studio

It's time for the review of the second (of two) Game Development Brisbane presentations from the 2nd of September. If you are wondering where to find the first one, it can be found here.

The speaker for this presentation was Ben Droste who is the Director and Lead Developer of 100 Stones Interactive. 100 Stones Interactive is a one man studio and this presentation focused on the experiences of development and release of the studio's first game. Prior to establishing 100 Stones Interactive, Ben worked as a Senior Environment Artist and Level Designer at studios like Krome and SEGA as well as others. I had heard about Ben last year due to his involvement in QUT Game Development Club events, which was a club at which I was an executive of at the time. Having not been able to attend those events myself, it was nice to finally put a face to the name.

As mentioned above, this presentation focused on Ben's lessons from the development of Eyes of Ara as a solo developer. Ben decided to create his studio with two criteria in mind. Firstly, he wanted to make the games he wanted to make, rather than games others wanted him to make. Secondly, as a solo developer, the games he would be making had to play to his strengths as a developer. Essentially that meant that the game would be art heavy with minimal requirements for difficult code. After considreing viable genres, Ben decided that the puzzle and exploration genre would suit him best. I found this part of the presentation very relatable because, at the start of the year when the Bees Won't Exist 2.0 project fell through I kicked off the smaller 2 Minute Survival Game solo project. That "I need to make a game that I want to make but works with my strengths" theme certainly structured my early thoughts too. The difference in our required angles of approach was intriguing to me though. In Ben's case, he was coming to it as an Artist/Designer who would have to tackle code and sound whilst in my case, I was coming to it with a programming/production background and having to tackle art and sound. I was interested to hear what the difference in experiences would be.

One of the key strategies Ben pursued to consolidate his areas of inexperience, and to save himself development time, was to make robust use of Unity's asset store. His experience was that, while useful, the asset store was probably more of a starting point than a full replacement of his own work. In his own words, the software offerings were very hit and miss with some working for him and some turning out to be useless. The art assets available, he states, were often "amateurish" or just plain bad. Ben certainly used assets from both the software and art offerings but in the end it often took considerable re-works and adjustments on the assets to make them viable. So, all up, Ben does think that there is some merit to using asset store offerings but that, in the end, it is best to strike a balance between just creating your own stuff and purchasing appropriate assets. Personally, I haven't seriously considered using asset store assets in any of my previous work, mostly because I don't have money to be chucking at them anyway, but, when considering the time it could potentially save, it seems like something worth putting more thought into in the future. I'll just have to be careful to avoid the amateurish and plain bad content Ben alluded to.

A key element to Eyes of Ara's development that Ben discussed was his overall experience with PR. Ben describes the success of his PR efforts as less successful than hoped. As a developer accustomed to working in larger studios, where the PR was handled by others, this was another area Ben was forced to get used to during the course of the project. It represented one of the key requirements that pulled Ben away from actual development and into the environment surrounding it. From the way Ben spoke, it sounded to me like he had engaged in the mental tug of war between, on the one hand, acknowledging the importance of PR and Marketing and trying to do his best to gain solid returns in those areas and, on the other hand, resenting how much investment these actually took and how they took him away from actual development. This is something that all indie studios face, especially where there is no voluntary PR/Marketing guy and, as it was in Ben's case, teams are often left feeling that this is the area that screwed them over in the bigger picture whether in relation to the actual sales volume and financial success of the game or in relation to the end polish of the game (because so much time was taken away from development). It's a shame because PR and Marketing are often some of the things that holds talented indie team's back. This problem, and the problem of over scoping, are things that I want to help solve one day given the opportunity.

This leads me to final topic Ben brought up that I'll discuss which is the idea of time management, work/life balance and scoping. Anyone experienced in the area of game development is unlikely to expect that it would be very easy for a solo developer to have very effective work life balance due to the incredible workload requirements in making a commercial game. In Ben's experience, his work life balance slowly deteriorated over the course of the project up until launch. The reason, in Ben's words, was over scoping. It seems that this is a problem that almost all teams face. Ultimately, it comes down to a big balancing act between what the team can deliver against what the team believes the market expects of their game and the ambitiousness of the project. Too often, what the team plans to create to meet those perceived expectations and the ambitions they have is more than the team can actually handle. I am all for stretching a team so that they deliver a really solid product but usually teams are stretched too far to the point where either horrendous crunch ensues or the team collapses. The funny thing is, from my point of view at least, perceived expectations of the market and project ambitiousness should be easily variable because they are down to individual team perceptions (i.e. what the team thinks the market wants and how ambitious the team is). It should be easy enough for the team to limit its ambitions or consider that maybe the market would accept the game without that huge extra killer feature. Unfortunately that doesn't seem to be the case just yet.

In the end, Ben's experiences ended up providing a whole lot of food for thought on how to go about solo projects and how much of a balancing act some of the key areas of contention are. It also raised some of the big issues the industry has at the moment including the difficulty of marketing/PR for indies and the problem of scope. I hope that you got something out of reading this review, and perhaps the review of the first presentation as well.

[davidbaker1095-blog]

Event Review: Game Development Brisbane: Game Design Document Principles - Simple principles for game development success

It has been a long while since I posted here but today I am back with another Game Development Brisbane presentation review. This time the presentation was made by Richard Roth and focused on explaining a principled approach to game design document creation. Richard has a background in business, mining and defence but has a big focus on his passion for game development and his current project's in that space.

Personally, I really like Game Design Documents. This mostly comes down to the fact that I rely on them heavily both in production/project management undertakings and in programming/development undertakings. I like to have a roadmap ahead of me when getting my head around a project so that I can understand feature specifics and inter-feature interactions. I find it reduces uncertainty and creates the space where I can really dive into the project with a lesser risk of going off track or missing the mark.

Richard admits that he really does not like game design documents but thinks that they are a necessary evil. Without one, he states, your project will fail. The supporting reasons he gives for this assertion focus on the design document's role of reducing scope creep and focusing development direction. I am certainly in agreement with this. In the words of Steven Covey, everything needs a first creation (the plan) before the second creation (the execution) can occur effectively and efficiently.

As the name of the presentation suggests, Richard advocates a principle based approach to creating game development documents. All game development projects are unique and they can vary wildly from one another. Consequently, no template for creating game design documents can possibly work for every given project. That's where principles come in. In Richard's words, a principle centred approach establishes an adaptable and interpretable process that can be applied for any given project. The principles you use themselves are up to you and are mostly a matter of preference for the team. For example, Richard uses the principle of the "Rule of Threes" in creating his Game Design Documents.

The Rule of Threes principle showed itself in several ways in the example document structure Richard presented to us. Richard uses three documents in his game design document process including the prototype design document, the demo design document and the full game design document. Each of these documents are larger than the previous one and allow for the staggering of the game development process over the course of the project. Other examples include where, in lists to be included in the document such as the core mechanic list, influences list and similar games list, three entries were always required. I can see the merit in the Rule of Threes especially as a structuring tool. As Richard said, the rule is already applied in a innumerable amount of ways throughout many different fields. I can see how the resulting familiarity with the Rule of Threes structure would be beneficial in both writing the game design document and for those reading it later.

In considering the principled approach to the game design document creation process, I naturally thought about which principles I would use myself. I think that, as I consider game development to be about creating an experience for the player, I would naturally include some structure in my game design document focusing on how we create that experience from the perspectives of each of the player's effected senses (sight, hearing, touch) (three senses there!) as well as laying out the intended ludic and narrative journeys that the player experiences during the course of the game. Outside of this, I would also use principles such as the Rule of Threes for establishing simplicity and flow in the document's structure.

In conclusion, I found Richard's presentation to be an eye opening experience. When I next create a game design document, I will be sure to apply this methodology to the process (no googled templates required).

This presentation was one of two Game Development Brisbane presentations made on the 2nd of September. I also attended the other, presented by Ben Droste, and plan on putting up review for that talk later this week. If you enjoyed this review, be sure to check it out!

[davidbaker1095-blog]

Movement functionality is in! The player can now move their character around the grid. The top and side border spots are unreachable as they will eventually hold walls. I aim to get walking animations and sounds in by the end of the week. Also, it looks a litter jerky but that is more to do with my laptop not liking the idea of running the scene and recording the screen at the same time.

[davidbaker1095-blog]

2 Minute Survival Game: Week 2 Review

Hi Everyone! Welcome to the second installment of my weekly project reviews on the 2 Minute Survival Game project. This week I got up to some production style work earlier on before setting up the project and version control and getting to work.

As I said in the content I shared at the time, production is the area that I want to build my career on and so it was exciting to get down to work in that area. I feel like that enthusiasm is something that would set my solo project methodologies apart from the a lot of my peers' work. I get the general impression that a lot of people consider the planning, measuring and documentation of production as simply work, and optional work at that. I can see where they are coming from in that, for many, the fun of the project is making a thing and really exercising one's creativity. Production can often be seen as getting in the way of that because it forces you to step back and think about how you will complete the project in a timely, and in commercial projects, cost effective, manner. Especially in the case of non-commercial, passion driven work, why shouldn't you just get stuck in and enjoy the creative process? Well, I would argue that, through investing in production related tasks, you would probably save time in the long run through much more efficient project work and on top of this you would have much more assured understandings and realistic expectations of the project. These benefits are exponentially greater the larger the development team is.

For me this week, my main production related efforts focused on creating the project's feature list and setting up some project management software. The feature list is really important because it forces you to nut out every little thing that will go into the project, as you currently see it, right at the start. The feature list can change overtime, sometimes drastically as big design decisions are made, so you don't have to worry about feeling locked in by this process either. If your feature list includes time estimates, you will also be able to get an understanding of how long the project will take, and how big of an investment it needs to be. If the results aren’t acceptable, it is the perfect time to iterate on the design and potentially increase your manpower and financial resources before you waste the resources you have developing prematurely on a doomed project. While, in my case, the estimated timeline of the Two Minute Survival Game is much longer than I initially planned to take on, I accepted this and now go forward with accurate expectations that I have bought into. Attaining that buy-in is a big step in getting the project up and running well. It's especially important in team environments because the last thing you want is a key team member dropping out later on because the thing is too big and too much work and they never really bought into that. You want all of your team members on the same wave length and the results of production work will help with this.

So, after the feature list, I set up of the project management software. I've heard people say that they think maintaining project management software just adds more work than it’s worth in a project. It's an interesting topic because project management software can usually be set up in a variety of ways and It is becoming increasingly evident to me that you need to set up your project management software in a way that is synergistic with your team and development culture. That means it has to line up with your team's workflows, it has to be intuitive to the team and it has to efficiently provide information to team members that actually helps them. If the system isn't helpful, is frustrating or simply requires time from the team that they are not willing to invest in it then they simply won't use it. If they do use it at that point, it will negatively detract from their experience of the project. In my case, I have translate my feature list into my Hack 'n' Plan project. In Hack 'n' Plan I have been listing tasks I need to do to deliver features, as well as my story point estimates for each task. Summing up these estimates allows me to adjust my original estimate for the feature and observe how that affects the project timeline. After completing the tasks I listed, I went back and logged the actual amount of work completed.

After the project management work was out of the way it was time to get down to business with some development. Naturally, there was some overhead with this too in the form of setting up the unity project and setting up a version control system. Version control is one of those things that is really important to know and use as a software developer but also has a fairly steep learning curve. For me at least it took a long time, and lots of forced practice, to get to where I am with Git because the whole system is quite different from anything else I have worked with and so it was harder for me to understand it intuitively. It's certainly useful though, as I said before, it is great to learn about version control because it is very important for teams. It is also great if your computer blows up.

One advantage I didn't think about which was brought up later was that Git stores a new version of your project in a server every time you commit and push. It's like making a new file every time you save. This is great because, if you ever break your project at any point for whatever reason, you can go back to a point in time where it was safe.

I'm still having problems with my .gitignore file but I asked one of my programming acquaintances about it and they gave me some very helpful advice which I will try to implement next time I interact with my version control system. The problem seems to have mostly come around from a lack of understanding of how the .gitignore works. It's all part of the learning process though and I am excited to get to know how to use it properly.

As for development on the game itself, this week mainly held a focus on implementing some of the fundamental content. This included setting up the grid based environment and placing an instance of the player object on that grid. The grid based environment system was easier to implement than I had expected. Simply watching a first party unity tutorial and utilising the principles outlined was enough. Once this was done, putting in the code to get a player object onto the grid was also fairly straight forward. The thing that took the biggest investment from me this sprint was putting in the front, back, left and right idle animations for the player.  I wanted to implement these things in the spirit of delivering whole features in a sprint rather than part features. Here, the feature was the player instance on the grid. In my mind, the feature wasn't going to be completely until the code, art and sound was implemented. In this case there was no sound associated with the feature so it was just the code and art.

I have a programming and production focused background, and have been looking forward engaging in my less experienced game development disciplines. I understand that, usually, the first step for creating character art is to create some concept art and turnarounds using the information given in the character designs as well as any writing that might help flesh out who the character is supposed to be. I feel like this is a great way to deliver more believable, appropriate, character art. Saying that, I ended up totally skipping this step this time. In hindsight It could have helped me go through the process of defining what a character looks like better beforehand so I may try it next time.

In this case, I got caught up on the fact that I had no idea how I would implement the character art. I know a lot of people use Photoshop to make their animations before importing them into unity. Apart from that I didn't actually know much about what I was going to be doing. I also don't have access to Photoshop because I'm not willing to pay for it, or pirate it. My free  trial of creative cloud was used up last year as well. In the past I had used Gimp for some basic image editing but I didn't know whether you could create pixel art or animations in Gimp.

Internet tutorials came to the rescue again however and I soon knew how to create pixel art sprite sheets in Gimp as well as slice those sprite sheets, create the animations and hook up the animations in Unity. The last of those processes, hooking up the animations, was something I have experience in, in the 3D context, from my Bees Won't Exist work last year. After learning those things, I got so excited that I jumped straight into gimp and started messing around with the pixel art while totally forgetting the concept art/turnaround stage.

It took me a few hours and a few attempts to make a humanoid silhouette I was happy with but after that I was really rolling. Most of the choices as to what the character would look like were made in quick succession as I filled out that silhouette with colour. Eventually it ended up being a pretty ordinary looking guy with a white T-Shirt and Jeans. I decided to run with this as I thought it would work well with what I have in mind for the game's beginning aesthetic. It took me a while to figure out how the characters eyes would look and I perhaps went into too much detail with them because, in game, you can't really see the detail as the character is too small. There was a funny moment when I ended up drawing huge eyes on the character and he looked totally shocked. I may end up using something like that in the game. Maybe his eyes get super wide when something scary happens. It would be subtle and temporary but I feel like it could make a good polish feature and make the character seem more believable.

Once I had figured out the idle starting frame, I put some thought into how the idle animation would actually work. I've ended up just moving his head up and down one pixel every frame and had him blink every fourth cycle. Later on, when I was creating the animation, I ended up making the animation cycle at one frame per second so it looks like he is breathing. After that, the rest was just pushing through similar sprite sheets one by one for the back, left and right side versions. I probably could have just made one side version and flipped it in unity but I figured it was just extra practice with GIMP at this point.

To allow the player to see all sides of the character at this point, I decided it was worth putting in basic controls which change the characters direction of facing in code. This code will be expanded next week for the player movement feature. With all of that work done, I now have an animated player who can start on any point in the grid and will turn on command. Turning seems a little less snappy than I would like but hopefully that can be fixed with tweaking later.

That's it for this week! Looking forwards to next sprint, I will be implementing player movement, including animations and sound. The sound part should be interesting as it is also new to me. I will also be working on some wall and floor art so, by this time next week, I should have an animated player character walking around a room with no windows or doors. That may not sound too exciting but I feel like it's a case of slowly but surely bringing things together.

[davidbaker1095-blog]

Started work on my first ever animations today! The aim of the game was to get idle animations from the four sides of the player character into the build. I used GIMP 2 to create the sprite sheets. Slicing up the sprite sheets, creating the animations and setting up the transitions was all done within Unity. All associated code, mostly setting up controls and changing animation flags, happened in C# in Visual Studio. This is the player character for the 2 Minute Survival Game. He’s just your average person but he’ll will soon be thrown into a do or die situation. I’m using pixel art for this project and this character was drawn on a 64 x 64 pixel grid.

[davidbaker1095-blog]

2 Minute Survival Game: I’m On the Grid

I finally got into some unity development today! What you can see is the grid on which the game will sit on (with some spheres showing me where the nodes are for now). The player object (the red square) now spawns on any pre-defined grid node. This represents maybe one and a half features done. Before the end of the sprint, I want to get some early idle animations in for the player object. It’s not much but its a start! Some of the other things I got up to was the setting up of a Bitbucket repository. Again, I probably could get away with not setting up a repository for this solo project but it’s one of those team orientated things that I just want to get really good at. It’s also good in the event that my laptop catches fire or something. I’m using git bash, the command line tool, rather than a nicer GUI (Graphical User Interface). The reason for that is I usually find git bash stays consistently fast while GUIs such as GitKracken have slowed to a snails pace for me when the project exceeded a certain size in the past. Using something lower level like a command line tool is also better for building a deep understanding of Git in my opinion. Learning about the commands as well as their meanings and use cases is way more effective than pressing a couple of buttons in that regard. I even had the honor of setting up the gitignore file this time around. I say honor because, while a learning curve, the more experienced programmers on the team have taken care of it in the past.

[davidbaker1095-blog]

2 Minute Survival Game: Feature List and Project Management Software

As alluded to in the last week’s review, I started this week by translating the 2 Minute Survival Game’s Design Document into a format more helpful for production purposes. The first of these formats was the feature list.

This feature list is agile orientated with the columns making it up being User Story, Shorthand Feature Name, Story Points and Value.

I’ve gone with the agile route over something more traditional because I like the values agile brings. Things like the focus on having a continually releasable increment is great for me because it forces the dev team (in this case...just me) to aim to fully finish features in a sprint rather than programming for a feature one week and then having the art and sound eventually find their way in weeks later. I also like the fact that agile is usually much more considerate of the pace of development the team is maintaining. Whereas hard and fast milestone dates force the team to crunch violently at the end if they weren’t keeping the predicted pace for whatever reason, agile methodologies, such as scrum, will simply act as a indicator of what realistic milestones might look like. The dev team can of course still work to try to meet deadlines in agile. I feel like this method is better for all stakeholders as everyone gets evidence based updates as production progresses.

To talk a little bit about why I used each column in particular, I find user stories are a great way to frame features from the perspective of the need they are satisfying. This can be formative when implementing the feature and also forces the developer to consider the perspectives of it’s customers and stakeholders. User stories are usually a little long for use on things like Kanban cards however so I like to create a shorthand feature description/name to use as the card titles instead. I went with story points rather than hours because, while I could easily get away with hours in this project as a sole developer, I think this is a good opportunity to get my head around estimating in story points. I’ll then be able to use story points more easily in my next team project. See this cool article to find out why story points are more useful for teams. You’ll see that I converted back to hours in the end but this was mostly to allow me to come up with an early project duration estimate. In a few weeks, I will be able to do this with story points no problem once I have an evidence based work velocity. Finally, value is important to agile methodologies like scrum as it is used to prioritise work so that you are implementing the most valuable content first. Of course, value changes over time. In my case I might decide halfway that I really want music in the game ASAP in which case the value of the music feature will be bumped upwards.

So overall, the 20ish features I’ve come up with for this project will take me around 20 weeks to implement at a super conservative estimate. Given that things take longer than expected and unforeseen tasks take up development time, I’m taking this estimate as realistic for now. 20 weeks is far bigger than the original one to two months I had in mind going in. I think I’m happy to commit to that though as there arn’t really any high stakes associated with this project being short. I think the disconnect between the desire for a one to two month project and the scope of my design came from the fact that it hadn’t really hit me that I would be doing everything myself so I was still running with something closer to a team’s work rate in mind. Even with my conservative estimates, things like sound and art may still blow the story point budget as I find more and more stuff I have to do to bring the games content up to par.

So with this information in mind, I started thinking about translating this content to some project management software. Google sheets probably could have worked just fine but I find the structure and interface of project management software helpful. My restrictions in choice came from the fact that the software would have to be free. In my mind that meant Trello or Hack ‘n’ Plan. I have used Trello more in the past but I usually find it a bit too limited for my liking. Hack ‘n’ Plan is more game development orientated and full featured so I decided to give it a go. Hack ‘n’ Plan is still in beta but I haven't had any major problems with that. I did change a milestone name at one point which didn’t transfer to other references of the milestone but that’s not a deal breaker for me (UPDATE: The changes had carried over a few days later).

Hack ‘n’ Plan comes with two main sections of interest: The game design model and the kanban board.

The design model is a pretty unique view where you can organise “elements” to give a view of the project similar to a design document. In scrum, features are the basic level of project requirement with tasks being a “sub activity” for each feature delivery. As “tasks” are the basic card level in Hack ‘n’ Plan, but you can add tasks to elements, I decided to have each element represent a feature and add the required tasks to each element from there. The above image shows my attempt at translating my feature list to this view as well as some tasks I added to the first element I plan to tackle.

You can also add tasks to milestones. As I won’t necessarily be focusing development around traditional milestones like alpha, beta etc, I plan to use this property to organise tasks according to sprints. In line with scrum, I will aim to finish all of an element’s tasks in one sprint.

Hack ‘n’ Plan has an interesting way of organising it’s Kanban boards around milestones.

This Kanban board holds the tasks I plan to do in my first sprint. I can then view discipline specific tasks for the sprint on their own as well as evidenced by the sidebar in the above screenshot. This last feature is probably more useful to teams than myself when the overall view gets very densely populated but I’m sure I will find a use for it as well. Anyway, this was a bit longer than most of my status shares (beyond the reviews). It’s probably because it revolved around my main professional areas of interest which are project management and production. Did I do a good job here or is it a disaster waiting to happen? Let me know!

[davidbaker1095-blog]

Event Review: Game Development Brisbane: Taking ‘Think of the Children’ from 48 Hour Jam to Full Production

In line with the themes of review and reflection that this blog is regularly turning to, I decided that it would probably be a good idea to write some reviews on select events I attend. This won't be for the super social events like bar socials but certainly workshops, presentations speeches etc are fair game. Hopefully these retrospectives would be helpful to anyone who didn't manage to attend the event and those that are just interested in the contents! These 'reviews' won't include ratings or anything like that but will include some commentary on the areas I found to be of interest.

Onto the review, this presentation was given by Adric Polkinghorne, A Master's Student of Interactive and Visual Design, Tutor of Narrative and Visual Design and Producer/Designer of the upcoming game Think of the Children.

That last role was the focus of this presentation as Adric shared his experiences of bringing Think of the Children from 48 hour game jam people's choice award recipient to full commercial product. I thought this was a particularly interesting topic, not only because I'm keen to hear new ways to break into the industry but also because of the increasing amount of successful games that have entered the market this way. Goat Simulator, Surgeon Simulator and Superhot are all examples of well-known games that originally came out of game jams in recent years as well.

I'll split my discussion of the presentation around the topics of business, conferences and development.

As a business and games double degree graduate, it was of great interest to me to hear Adric cover so much content in regards to the business side of his journey. As his team's producer, Adric has taken the lead in these matters. I was particularly interested in Adric's explanation of his team's interaction with publishers throughout the process. My personal experience with trying to publish games has mostly been of the indie variety where I would personally submit the game to the platform and undertake the tasks necessary for getting it out there. It hadn't occurred to me that publishers were actually viable for the Brisbane development scene (outside of larger companies of course). Adric's team on the other had approached publishers very early on after the game jam. Initially there were some hiccups where publishers couldn't see the end product or focused  on its flaws but the team found a publisher pretty quickly.

Adric put the initial problems down to the fact that the team had potentially thrown the game out to the world too early and without adequate polish. This was another case I have come across in which a developer's experience has been against the suggestions of startup methodologies such as the Lean Startup methodology. In that methodology, the developing team would first put out a minimum viable product, without polish and not necessarily even in a full featured state, which presumably the end product of the game jam would comply with, and then the team would continue building from there using market feedback. This is the approach Adric's team took but they believe it hurt them. In my experience generally, this methodology has seen a lot of resistance from the game development industry and game developers. I'm not sure if it is a general case from creatives and publishers of "Oh my/this product isn't perfect so I can't possibly publish it of show it to the world. It was ruin me!" or if it is something else. Who knows? The Lean Startup methodology is very popular in general software development but not yet for game development. Could it be because audiences expect their entertainment software to be more complete and polished at launch than their utilitarian software? I'm sure it would make for a good research topic.

Anyway, Adric's team had access to funds, marketing expertise and publishing expertise. As Adric puts it, they ended up with a really good deal. They maintained control of the development side of things and their publisher was really helpful. Their motto was "Your First and Last Publisher" with the connotation being that they would teach you all of the tips and tricks of publishing, as well as getting your product selling well so you would not even need a publisher in the future because you would have all of the resources required. I wish I had got their name because in hindsight I would want a publisher like that in the future if I was looking for one.

Another business point that Adric stressed as a big positive was that his team decided that they would pay a third party to implement their online multiplayer for them. This was a big point because it represented a strong sense of what the team could handle and it was decided that it would be better for the product overall if the internal team didn't try to deliver multiplayer on top of the single player campaign and polishing work they were already doing. I was interested to hear more about how this arrangement worked. I'm guessing that, as Adric's team had development control, the third party developer would be simply adding online functionality to existing modes and content. That is just my assumptions though.

Onto conference related points, this presentation was a really great insight into the inner working of presenting at places like PAX. It covered topics like Australian vs US conferences, how to set up to maximise for press coverage and how to negotiate business card resources. In the case of Australian vs US conferences, it turns out that getting a booth at a US version of PAX is way cheaper than the Australian equivalent according to Adric (about $1000 in the US compared to $5000 in Australia) this has to be a demand to supply thing because, the way Adric put it, booth costs plus flights plus accommodation in the US is cheaper than getting an Australian booth. Adric also said that there was a much bigger publisher presence in the US conferences compared to Australian equivalents.  Adric's team had received multiple offers from publishers all up at these conferences and it was interesting to hear that some of the offers were coming from the people that had turned the game down before.

Some of the cool tips Adric suggested in regards to maximising press interaction at these conferences included having a dedicated press play station at the team booth and contacting press ahead of time to organise play times or interviews with them. I thought both these tips were great and I would certainly try to utilise them if I went to conferences like this. My team, apart from myself, got to go showcase Bees Won't Exist at the Game Connect Asia Pacific Student Showcase in Melbourne last year. We were in a student booth rather than on a corporate booth, so it could be more to do with nature of the booth itself, but I don't think anything like this came up at the time.

As for the business cards, Adric's experience is essentially that, if you give your business cards to everyone, you won't have them for the people you want to give them to. Giving players separate content such as brochures with website URLs is a much better idea. You will then be able to give your personal contact details to people that will actually use them such as the aforementioned publishers.

Finally, in game development related points, Adric talked about a couple of interesting topics. In the context of a game jam, Adric explained that his team had gone in trying to win. They looked at previous prize winners and considered what brought those projects across the line. As we have seen, game jams are increasingly producing quite widely known projects so it is well worth building a game that will present well at the end and get some attention. The team also prepared to showcase their game effectively both by bringing a projector and by bringing a large TV. They understood that the crowds ability to see and enjoy the game at the end was very important which I certainly agree with.

In the context of post game jam production, Adric's focus was on the fact that his team had gone through a big learning curve. They had spent a lot of time working out what worked for them and trying to emulate what successful studios did to become successful. One example given was that the team, which initially used Adric himself as the design lead, attempted to move to a "everyone is the designer" approach as employed by Halfbrick. This had to be scaled back a bit eventually because some of the ideas being implemented didn't mesh together very well or with the product vision the team was trying to maintain. They also tried to look for tools that would help their development work rate such as the free MagicaVoxel which helped them cut the time it took to do some parts of the level building by 50% according to the team.

I'm not really sure what I think of the "everyone is the designer" mentality at the moment. On the one hand it lets everyone put ideas out there and have a fairer chance of starting momentum with them but on the other you risk losing a little focus on the design and no one person has oversight over whether or not the design is still consistent with the product vision as Adric's team found out. It might be that a pure version of the methodology is a little idealistic. I've also seen a team I was in try to implement it with one person in charge of the final say. In that case, the "lead designer" essentially became the only designer as some other team members didn't care about contributing to the design, there wasn't really opportunity given to contribute and any suggestions were often tossed aside by the design lead. So in that case the "everyone is a designer" rule was kind of superficial. I would be keen to try it out again in the future if the opportunity came up however because I feel like it is just a matter of setting it up the right way.

That's all I wanted to discuss about the presentation! It was certainly informative and I look forwards to hearing more about the progress of Think of the Children in the future. This talk came about through Game Development Brisbane, A group that usually holds presentations on the first Sunday of each month. You can follow them on Facebook and Twitter for news although they do their event sign ups through Meetup. They are also looking for presenters for the future. They would prefer you to email them if you think you have something worth presenting in relation to game development although I couldn't find their email in the aforementioned channels so I assume that they'll be fine with you contacting them through there.

[davidbaker1095-blog]

2 Minute Survival Game: Week 1 Review

Hi Everyone! This is the first of a series of weekly review posts I plan to write. The point of these posts is to act as an opportunity for the reader to easily catch up on what I've been up to in the past week and to give myself a chance to reflect and potentially find new lessons and takeaways from my experiences. I will return to some content that I posted earlier in the week but there should also be new content that I didn't share at the time whether this be brand new stuff or more details on what I've posted before. I hope that you, as the reader, can take something from these posts as well. To help me in that, feel free to let me know what you think I should be talking about during these posts. They will be sure to evolve over the weeks as I get fully into project work so it's a perfect time for me to make changes you want as well.

This week marked the start of my first post university project. The reasons why I chose to kick off this project were that I wanted to directly invest time in my passions for content creation, I wanted to build my portfolio as a game developer and I wanted to find ways to stretch myself and my skillsets. It was a really great time for me to start because my previous project, Bees Won't Exist, which has been my main project for the past 12 months, finally collapsed under the weight of the artificial barriers and lack of personal interest that key team members were feeling. I then had a large project shaped hole in my life. Bees Won't Exist had partially become a chore because of artificial issues, such as people, including myself, doggedly avoiding work where we didn't want to do it and then didn't want to do too much work on the project generally less we destroy our social lives and work life balance. Looking back, this was a pretty unhealthy state to be in. Game development should be fun and, personally, I should want to get up and delve into that creative environment which was not the case. I was locking myself into Scrum Master and QA roles without the desire to actually create the content. So one of my aims with this project was to have fun creatively and fully jump into all areas of the project.

As to what the project would be, all I knew initially was that the game would be super small. One of the biggest lessons I learned last year was that over scoping (i.e. making your project bigger than the team can reasonably deliver) is a killer of projects, and if not the whole project then at least the happiness of developers. I think it's great to dream big and be ambitious but you can't deliver what you don't have resources to deliver whether that be through a lack of people, time or technology. Ultimately, I decided that I wanted the player to be able to finish the experience in around 2 minutes. Some people would call that restriction arbitrary but I find it a good way of measuring an amount of content that I felt comfortable committing to.

This is the point at which the brainstorm I shared this week came in. The brainstorm acted as a vehicle in which I could start noting criteria I wanted the project to satisfy and then put down ideas and constraints as they came to me. This was great because as the process panned out, I ended up thinking about what types of games I wanted to make at a high level which brought me to why I am a developer in the first place.

The short version is that I believe that interactive entertainment is the next great form of expression and I want to help push further into that potential than anyone else has done before. I don't think that interactive entertainment will reach its peak in my lifetime because I feel that will only happen once interactive entertainment occurs in virtual reality indistinguishable from our own. We are a long way off that for now but maybe I'll be surprised. I feel like, given acceptance of that, It is still very possible to pre-establish some of the methodologies and techniques that will be used to make the best games at that time. So in short I want to help find the way to make interactive experiences of the highest quality, not compared to what we have already seen but what there will be full stop. To bring this down to what I am doing now, did it ever cross my mind that this new project would meet that goal necessarily? No. This is still a really early project in my career but I think it should be formative at least.

Anyway, what I ran with from that thought line during my brainstorming was that some of the best experiences I have come across were in the form of narratives. They had compelling beginnings, middles and ends. There is a problem with narratives in that they can stretch out a game as you try to set up each narrative stage properly and earn strong pay offs. I thought I'd try to tackle this though while still keeping the game short. One way I would like to do this is through limiting the number of narrative stages to something like Beginning -> Problem -> Climax -> Resolution. The other option Apart from a narrative focused experience, the other option I had for structuring the game was to try to establish a strong game loop and then a strong meta loop. I do want to make this type of game eventually, because I feel it is certainly a strong model. For this project though I had already became intrigued with the idea of a really short narrative game before I had fleshed out the possibilities for the second structure.

The next questions I tackled were around genre, art style and sound. I probably spent less time thinking about these then I could have, possibly a sign of my inexperience, but in the end I came up with answers pretty quickly. I had started thinking about the horror genre pretty early and this lead onto the theme of survival. I liked that because I thought there was an interesting juxtaposition between the boundary of a really short game and the theme of survival. Survival narratives are usually drawn out over a period of tougher and tougher odds because that steady rising of tension, and maybe even the drain of holding on can lead to a stronger payoff at the end. A 2 minute survival game wouldn't have that luxury and, if it was narrative based, I would have to execute really well in order to make it work. That kind of really strong execution on a really small amount of content is far more appealing to me than trying to effectively execute on a lot of content to a passable state. It allows for quicker production times with greater room for iteration and improvement as well. The choice of art style was mostly directed by my lack of art experience. I knew the art would have to be minimalistic in order to not overstretch myself and maintain a higher level of quality. I liked the idea of pixel art because that can be really simple or really complex and still be beautiful with a whole area of grey in-between. The choice of the survival genre along with the art style of pixel art seemed like it would be an interesting combination as well. As for sound, I wanted the games music and sound effects to add to the intensity of the experience, especially later on, and I wanted it to drive the urgency of each decision.

In order to keep the narrative interactive, I decided that I wanted to allow for the effect of choices on how the narrative turned out which effectively required a branching narrative. It took me a solid amount of time to work out how I was going to do that and keep the number of branches reasonable, as evidenced by the maths on the brainstorm, but in the end I decided that having three possible states in each narrative stage (death, advantage and disadvantage) would allow for about 10 states overall which is a level of content I would be happy to tackle. Allowing the player to die at any given stage of the narrative, and restart instantly, allowed for a kind of gameplay loop as well. And so the outline of the experience came into being. The player would start at the beginning of the narrative and then make choices according to their situations in order to try to reach the next stage. At each stage they would either die, gain an advantage for the next stage or gain a disadvantage for the next stage.  In order to keep each decision short I decided I would experiment with manually limiting the amount of time that the player would have to make a choice at each stage. Not making a choice in time would be counted as a choice and could potentially disadvantage the player. I think that something like building music could be a great vehicle for telling the player they only have so much time to make a choice without force feeding them through a timer.

All of that content and decision making came out of the initial brainstorming. After writing all of that, I realise that this post is going to be HUGE if I maintain the same content to activity reflection ratio. For the rest of the post, and probably future posts, I will try to keep it more succinct and cut out the unnecessary stuff I'm leaving the existing stuff in though because I think it was a really important part of the design process for me on this project. Going in I didn't have much but motivation. Going out I had a loose game design. Let me know if you totally agree with that plan or think it's fine as is.

Next came the creation of a lot of the design document. It's currently sitting around 12 pages. I probably didn't need to make it quite that big but it did help me flesh out all of the elements of the game. One of the sections of the document, the "Typical Player Experience" section, ended up being a great piece of material for sharing at the time. The first part of it was shared through social media to gauge the response of my network and I managed to get some feedback from various comments.

The feedback was fairly positive. I'm not sure whether this is from my network being nice to me or whether the content actually stands up. I'm assuming it's a mix of both. When I handed the paragraph to people to read, I never got a blank expression or obvious disinterest. It is probably what I would expect to get from someone after telling them an above average campfire horror story. I'm fairly happy with that at this stage although I will be sure not to settle. Online, one comment discussed the fact that it is important to grab the reader's attention early and that the piece I posted had done that to an extent given that it represented the start of the game. Another said the game would be good in Virtual Reality. I thought that last comment was interesting because, in the piece I posted, I hadn't alluded to the 2D pixel art style I had planned, and the comment suggested that they had envisioned it in fully immersive 3D. This is probably down to the fact that text leaves a lot to the imagination but I was interested to see that the game could be so easily imagined in that way. Perhaps there's room for a VR version in the future? In any case, It showed me a new side to the process of using a written typical player experience and how powerful it could be for drawing insights.

Finally for this week, I managed to engage in a discussion with a sound orientated peer of mine about the 2 minute survival game. One of the interesting things he said to me was that, as the game starts fairly innocently, he would consider using a different track for the start to the rest of the game in my shoes. The first track would be fairly subdued but as soon as the problem stage started it would become more intense, ominous and urgent. Another suggestion he made was that I use the music to create urgency in the game through speeding it up over time until the point where each decision was made or not made. I think either of these ideas could work if executed well and I will be sure to explore them when I get to implementing the game's sound.

That's it for now! To give you an idea of what I will be tackling next week, I expect to cover things like creating a feature list, setting up project management software and starting to implement fundamental features in a build. Those last two activities should be quite visual so hopefully I will be able to share content as I go and make the week 2 review more interesting to look at.

[davidbaker1095-blog]

2 Minute Survival Game: A Potential Player Starting Experience

After loading up the application, the player find themselves in a small-medium sized room. It looks like a bedroom and the warm lighting make it seem quite cozy. A prompt window appears with the controls outlined. Closing this, the player starts moving around the room. There isn’t any other characters in the room or anything particularly stimulating. The player can hear rain though. As they move near the dark window, it is outlined and an interaction prompt appears (“Open”). As the player hits the button, there is a clap of thunder and the screen is momentarily whited out by lightning. To the player’s shock, the scene comes back into view to show their character has been impaled and lifted off the floor by a menacing looking stinger from the window. As they watch, their character is dragged outwards through the window and the scene fades to black. Within seconds however, the scene reappears with their character back in the position they started in. Same room, same warm lighting and the sound of rain.

[davidbaker1095-blog]

New Project: 2 Minute Survival Game

I spent some time today brainstorming a game project idea. It’s current form is that of a 1-2 minute micro survival experience in which the player gets a couple of chances to interact with their environment to try to survive. Of course the potential for death lurks around every corner and hopefully there will be some replay ability as the player explores the different effects that different choices could make. Even though the game is short there is room for a lot of stuff for me to sink my teeth into, or collaborate with someone on. I’m kind of imagining an aesthetic like Pokemon or Corpse Party. It might be an opportunity for me to try to learn pixel art. Apart from that things like scrolling text boxes, limited AI and something more ambitious like building music is on the cards. That last one in particular will probably be more complex than I'm giving it credit for. Even general sound implementation would be new to me so I am open about how complex that gets. Being someone of a programming and production focused background, the biggest unknowns of the idea right now are the sound and pixel art implementation. I’m excited to learn though and this is a good opportunity to talk to some of my more art and sound focused acquaintances.

[davidbaker1095-blog]

The (Starting) End of the Line. What is this Blog?

Hi Everyone! Welcome to the first post of the blog!

The purpose of this post is for me to explain the purpose of this blog, as I see it currently, and outline the focus of where I am trying to put my project/work efforts at the moment.

So, there are several reasons why I am starting this blog. Firstly, I intend to start engaging in some side projects going forwards.  This blog will help showcase my work for these projects and hopefully also demonstrate my ability to communicate well in the written form, maintain a flow of content and build a brand (in this case the brand is myself as a professional). The topics covered will probably be focused somewhat towards what I think might look good in a portfolio as I intend to use it as evidence of my activities and experience later on. As the name of the blog suggests  this content is also intended to be intriguing and I'll try my best to avoid the tedious. If I'm failing in that, don't be afraid to let me know! Another purpose behind this blog is that I find writing up content like this is very good for reflecting on my situation as I am forced to think about, analyse and articulate what is going on in a three dimensional manner. Time investment in that process could actually help my work in the long term. Heck, writing this whole paragraph required me to reflect on why I am writing in the first place. Is that meta?

In regards to where I am trying to focus my project/work related efforts at the moment, I will almost certainly be engaging in small game development projects in order help me gain more experience and build my portfolio. At the moment I have been significantly involved in three projects and while I thought they were quite good, if not ridiculously impressive, the stony silence from studios I have applied to suggests otherwise. So I need to improve on the portfolio front. A knowledgeable fellow graduate of mine once relayed the saying to me that the first ten projects you engage in will all be trash and never go anywhere so it is best to hurry up and get them out of the way. Taking that advice to heart, I have quite a way to go until I produce something decent. Maybe that is what the studios are thinking about in regards to my portfolio too? Initially, it might be good to do a few super small solo projects and then move onto team stuff. The problem with that is, as an aspiring Producer, I really need to be working with teams to develop my skillsets properly. So, If you are reading this and looking for a project buddy to take on project management and production tasks, let me know!

Apart from game development projects, there are a couple of other project types I am keen to work on. I am interested in crossing the traverse from "mutually exclusive consumerism" to "consumerism + thought leadership". What that means is that I would love to study, analyse and review content I am interested in, and consume, and then communicate my thoughts and findings to others. This could take a couple of forms and it could be around virtually any topic, although I plan to steer way clear of heavy topics like politics, religion etc. In my case, it could easily be around content creation, business, marketing, gamification or game development. I also like the idea of thought leadership for things like film and gaming, as it would let me flesh out my thoughts on those topics and add some productivity to my viewing and playing. I would probably create separate blogs and channels for that though because it would tread a bit too close to the recreational side of the recreational-professional balance for what I have in mind for this space. I also have a stalled project from last year where I was supposed to develop a workshop covering the "Gamification of Teams". I think that finishing development of that workshop (even if it was never delivered in the intended environment), as well as generally reviewing, generating and sharing content on the topic would also be fun and appropriate for this blog.

Wherever I end up going, I am sure it will be a lot of fun, and even more work, and I am excited for that. From what I've brought up above, what caught your interest? Am I already failing in keeping this blog intriguing? What do you think I should cover here? Let me know!