GDS 230: To Market!

Today I have been tasked with marketing a game. Not just any game, mind you, a game that I have already done and it is to be changed to better suit the intended market, the intended market chosen by who would likely enjoy the game as it is. Are you following? let me break it down.

One of the major aspects of being a game developer that we’re learning about over the next few months is how to effectively market and advertise a game for distribution and success (Read “profit”). I’m getting “professional” and turning to the dark side by  disregarding my personal ethics for the moment to analyse what works (the “pop ups’ and “micro-transactions” kind of ethics) In order to save some time in getting into the nuts and bolts of finding a market and giving them something they want, we are to use a game that we’ve already worked on and modify it to better suit that market. That way we have a functional starting point that has already gone through degrees of feedback and play testing. We will first be looking into what kinds of players there are, and then figure out which game we have that is closest to meet the desires of these players and then we are to change or add to the game to better accommodate their interests, specifically to a degree in which they would be willing to pay for the product. Yeah this is THAT level of development.

First step: Research. I’m going to have a good hard look at my list of published games on Itch and start cross referencing their qualities with other games that have made money or been otherwise successful. I then need to identify why they were successful or why they weren’t. What marketing strategies did they employ? etc.

It didn’t take me long to see that the most prolific, current form of publicity is through let’s plays and streaming. The most watched games are ones that elicit strong reactions of fear or frustration. I feel that streamers and lets players have such a built in audience that to not try and make use of that would be a waste of resources. This means I am going to make something that will create a situation for lets players that their audiences are intent on watching.

Looking over my games list, the two that jump out at me as marketable are Office Joust if it were turned into a difficult platformer, and Darkness Dwells if it were given some task and challenge elements.

I found that there are many games that have been extensively streamed without managing to make much money or be significantly downloaded. Most of them are Horror games that are designed to elicit a shock response (commonly but not always “jump scares”) but there are plenty of horror games out there that didn’t do well too, so what’s common among them?

My observations:
Games that do well both through streamers and players are games where the act of playing is the game and also is very simple in it’s interaction. The goal is to ACT as well as possible. Examples are getting over it, minesweeper, slither.io, Five nights at Freddy’s, slenderman, more.

Games themes that generate a lot of stream views and do quite well otherwise are also games where the act is the important part such as FNAF, Alien Isolation, etc. Darkness Dwells could play to streamers if it had some way of using the vision. perhaps like Lights Out.

BELOW IS ALL ABOUT MAKING THE GAME, NOT HOW TO FIND A MARKET

I would absolutely love to make a submission game. “tap the things, leave for a while, come back tap the things, get more things etc” Like dragon story, fairy Kingdom or to a much greater, way more out of scope, idea like Clash of clans or dungeon keeper, but I don’t have access to server space like that and probably never will on my own.

The final result should be a unique twist on the old model of jump scare games. This is not a particularly sophisticated way to elicit a reaction from a player or viewer, but is effective in having the name spread online. Late Night Wanderer (LINK) is an example of this. Five Nights At Freddy’s used jump scares but, more than that, used the impending jump scare as the motivation of the player to do well.

I fully intend to make use of the low hanging fruit for this marketing endeavor as I feel that I have an interesting mechanic that I could use to garner the intended feeling for this type of game that:
– I already have a prototype of (effectively)
– could do quite well on the streamer circuit by nature of the viewership demands
– has the important aspect of the game style already implemented
– is the most mechanic driven out of the games I have in that is has one simple method of interaction.

The aim here is actually to be quite Andy Warhol about this, I’m not trying to make anything original I am trying to make a thing that can do really well and possibly earn me some renown and money. I have no desire here to challenge the system of desire -> demand -> supply, I am looking for monetary and social success.

I will have to move forward by doing research on other games that speak to this audience. One task will be developing a way for it to be fresh for each game. There should be a challenge element that will allow players to play the game and have an experience they can brag about.

Advertisements

Darkness Dwells Post Mortem

Darkness Dwells is a horror game designed in the style of the massive success, Five Nights at Freddy’s series. The team involved four designers with peripheral experience spanning audio, animation, 3d modelling, etc. and had additional input from three animators, to varying degrees.

The point of the project was to design a  game to fit the current market in order to get some sort of profit. The two outcomes aimed to meet were to create a game that would bring in monetary profit or, failing that (for reasons of scope change or technical problems) to produce something popular. The latter would add to our credibility, notoriety and would make publicity for future projects easier.

What went well?

Communication was consistent and meaningful.

All team members strove to have a solid understanding of the game as a concept and the quality of the product we were aiming for. In the periods we didn’t, there was an effort to find out, or we were comfortable to trust elements of the game our team mates as the lack of comprehension didn’t hinder progress.

All changes or decisions shared among the team across all the channels of communication we had in place. Additionally, we would each acknowledge that these decisions had been made which prevented an assumptions from being made. This meant there was no guessing about who was up to date and saved time having to ask for confirmation. This includes the animation contributors, who gave regular updates on their progress, submitting their progress for review in case changes were required. The results of this were highly satisfactory.

In the future I will use this project as an example of good communication. I am already familiar with how bad communication negatively affects a project but this has served as confirmation of the alternative.

Marketing was on point:

Thanks to the diligence of one team member specifically, the game had consistent publicity on the lead up to its release. The team member, Nicholas Duxbury, was part of the team that made “late night wanderer” in a previous term, a game that had some success and also had the attention of internet streamers. We knew that this was something we could play into later. But Nick having the experience of responding and building those interactions with people online meant that he was naturally keeping an eye on that aspect of the production.

I created some custom promotional art to be distributed during production in order to get some interest including four poster-style images. These were met with curiosity and hinted at production value.

DDPromoImage1a.jpgDDPromoImage2a.jpgDDPromoImage3b.jpgDDPromoImage4a.jpg

The first version of the social media channels that were made by the team involved some of the design and production images of the monsters in the game. I felt (and was later confirmed by our course facilitator) that this was giving too much away, removing the mystery of the monsters in the game. Firstly, the monsters were designed to be hidden for the majority of the game, which means that there is an initial fear of the unknown – this is a design point that I have been researching for The Grattenweld Incident, coming out next term – and to show this so soon would diminish that. The second point is that we shouldn’t be suggesting that these monsters were created by us, even though they obviously were, because to the player, the monsters are alive inside the game. To show their construction process early would make them feel “fake.”

And so the art was taken down to be republished in a different format. The game’s public face was going to show off the mystery within the game and to give preview to how it will look and feel to be the character when they decide to play the game.

Since the release, there have been several streamers that said “I have been following [Darkness Dwells/This developer] for a while…” which has clearly demonstrated the necessity for keeping an updated social media presence during production.

I find this duty to be very taxing on my overall process but see that it’s an unavoidable part of production if one wants to maximise their market success. I have been developing my ability to keep an eye on parts of the production process and stages of progress that would be good advertising. I need to build the habit of publicising work on current social media. The key being not so much the content but consistency.

What didn’t go well?

Opening night problems:

The game had a few bugs in it upon release that way damaging the playability of the game within the window of publicity that came with release. However, in the remaining week, Nick put the effort in to fix these bugs making the experience more like we intended and since then, there has been a steady climb in the analytical levels of interest that the game has received. These problems could have been found if we had prepared an intended release version of the game sooner but that would have required more time or cutting more elements, and then, at the time there was no telling how much we could achieve through patching at the time when there were so many other deadlines to meet for each of the team members.

This is characteristic of the “We wish we could push the release”, and we did, but we probably did achieve more knowing that we couldn’t change that, and if we had, it would have taken time away from the other things we had to do.

I now understand that deadlines need to include play testing and fixing. We got lucky that the major bugs were able to be fixed by a member that had a bit of time up their sleeve, but that won’t always be the case and the production time frame needs to reflect that.

What other observations were there?

Some role shuffling:

At the beginning of production we laid out our individual roles but found that those became a bit fluid as we made progress. Some tasks were handed to those that we knew were able to complete them quickly, even though it wasn’t originally their responsibility. I don’t know whether this is a positive of negative workflow to have but it was functional and is probably what allowed us to release a complete game on time.

On the other hand, having set down our individual roles did mean that there was always a true arbiter on each aspect that came up as a problem and there was no in-fighting that may have come from the blurry lines of responsibility. Also, as a mark of the team members attitudes, once we completed the “extra’ tasks we were handed, we knew which position we could settle back into once it was complete.

I feel like this only came about because we have tackled this issue individually over the last year, but it is a production decision that I will try to lay down in all future productions, even if roles do extend to some other people. This reflection is the support I have to back it up if anyone doesn’t understand why.

Scoped back:

This is a good thing to do but a bad thing to need, I think. As the deadline was closing in, we decided that rather than the four nights, we were only going to release the first and use the game as a springboard to a potential full release. The released game is now a demo that has generated interest for a full release which will take a relatively small amount of work as lots of it was done already. The drawback is that we used a chunk of time to make assets that were not required for the release, but now have a place in the “preview trailer” material.

This choice was made out of necessity. This is important because having one night completely working meant that all the systems were functional and the extra levels were largely cosmetic from a production standpoint (allowing for testing and tweaks). It is hard to say if we really over scoped as the game (post pivot) was timed to have more hours to sink into it. At the same time we hadn’t clarified exactly where all of our time was going to be spent over the production.

In short, there were a lot of factors that we weren’t prepared for but it still turned out okay, because we adapted our dynamic and our game.

Conclusions:

Going through this whole sequence has equipped me with the understanding of how the current indie development system goes. I don’t like it, but the necessity for constant social media updates is obvious. It’s also taught me about how I can use knock-on success as one project wraps up and another begins. Designing projects to capture a market can be a useful tool to get publicity for a bigger project later, which is the primary marketing style found among internet streamers.

DDPromoImage1a.jpg

Massive: Reactor – Post Mortem

This post mortem will outline the defining elements that lead to the exhibition version of Massive: Reactor,  an arcade-style game designed by Byte Canvas. By the scheduled public showing, the game still had issues but was mostly functional and well received by the people that played and observed it.

The purpose of the game was to take an existing mass produced input device (as common as a mouse or keyboard up to a game-specific device like the Tony Hawk RIDE board) and design a game that required it to be used in a manner not intended by the designers. This project made use of a Guitar Hero: World Tour drum kit for the Playstation 3.

The team comprised of a designer/general artist and a programmer, with music from an outsourced musician/audio technician. 3 people in total to be credited.

What went well?

The style of the game came together quickly:

From the beginning of the project I was intent on making the prototype of the proposed game before making any further design choices as the idea of using a drum kit in this manner was not something I was familiar with at all (as was the intention of the brief and the design). Once we did that the test was ready. The game was called “Drum Station” at this stage.

Reactor developed a very cohesive style right after the first working version of the game had been developed. Once we had tested the controller and how it felt to use with the game prototype, it was obvious that the actions taking place on screen were not befitting the dramatic actions being used to play the game. Nothing felt worthy of it.

This was the stage I was wanting to get to for this exact reason. I did some art searching, looking for general inspiration on each of the elements  in the game. I found an image of a tech planet that felt like an orbital laser might be set up around.

https://i.pinimg.com/originals/2b/79/78/2b7978e5c9967bc71c7898b979b9f62c.png

I started looking into the old Heavy Metal comics and Judge Dredd for inspiration along with Warhammer 40k, all of which have heavy industrial, futuristic tones and designs throughout. This lead to more changes like dramatic backgrounds and cyberpunk UI and titles.

The change that most reflected the action/feedback consideration, I feel, was the station’s laser and it’s cannon. The original design involved a needle like spike that would zap outward. Looking at it in action without any sound gave me and other observers an internal sound of “pew pew” which didn’t feel big enough for the action of smashing a drum. We needed a “Boom!”. I did some research and found this image-

https://i2.wp.com/i0.kym-cdn.com/photos/images/newsfeed/001/099/826/306.png

The wide bore suggested “boom” so the design was adapted and a fitting sound implemented.

In past projects, I have paid attention to the visual cohesion of projects and how they fit thematically and audibly, but now the physical action of the player will have more consideration during the development of future games. This is a lesson that I have now added to the process that I will take when making games.

What didn’t go well?

Development instructions were not being interpreted to accommodate the whole:

The ability to communicate effectively between the designer and the programmer had many hindrances over the course of the project, due to many separate reasons but most were mechanical such as physically speaking to each other or the language barrier. These were largely overcome as they could be adapted to. However, in retrospect it is evident there was a fundamental difference in the way information was being received between the design notes and implementation requirements and the way they were being implemented. In so much as the documentation that outlined changes and required game functions were largely written to convey a functional goal, but were being implemented literally and only within the parameters of the request. The most effective example of this misinterpretation was evident in the exhibition version of Reactor.

The day before exhibition, the project required an input to allow a return to the main menu. From the design standpoint, hitting the cymbal pads together, twice, seemed to be obscure enough a behavior not to get in the way. When implemented, firstly, the result of the input was not the required function in that is simply restarted the level after a single dual-hit, but that was to do with the language barrier and likely the lack of diligence in confirming the requirement. There was a programmed time period between the game registering each individual hit of the cymbal pads. The other function of the cymbal pads is to change the direction of the main character, which is a function alternated between often. The hit time allowance was long enough that it was quite easy to accidentally restart the level. The game wasn’t tested after the implementation of the feature by the programmer and they had not made the mental consideration of how long the dual hit should take to be performed or whether the function as it was implemented would meet the player requirements to act as a strictly intentional effect.

Though this seems like an attempt at blame, it is simply an observation of a set of issues that are not uncommon in game development. My documentation as designer was written with the expectation that the person reading it would apply the practical application of the function to their understanding of the whole of the project. Similar to a notion of “common sense.”

But each request was being carried out to the specific parameters of the request. Developing a style of writing documentation to deal with this mentality is necessary in that this problem could be met again in the same manner or when working with multiple programmers who are not part of the rest of the project. Consider if one person worked on the direction system and another was given the function implementation description with no knowledge even that the cymbal pads had another use in the game. This would be a likely occurrence. Whether working with one person or many, being the designer who holds the understanding of the ramification to the game and the player means that future documentation should be written with the perfect ideal to what the function must do.

The problem with this may be that in order to be sure that the request does not conflict with other parts of the project may require a deep understanding of the programming as it stands at the point of update. To minimise the impact of this sort of situation, it would be easiest to have feedback from the programmer of what their function actually does as it is implemented. this could be a write up or log system that specifically refers to the numbers/times/functions/etc as they have been put into the game. This is a form of clarification as much as a useful update system for the technical specifications document.

The original team broke off early due to miscommunication:

The original team comprised the whole of Black Canvas, the same group who created the small tower defence game Soul Resource in 2017, plus one more who was rolled into the group. The initial developer had brought the Asteroids style game to the fore and was trying to develop that game. The problem came from the two designers that were working having polar opposite methods of development that formed a divide between the two.

One was intend on building the foundation of the proposed game and making sure that all of the actual input would function and then, through play and testing, start refining how the game could become more fitting for the controller. This person was not willing to plan further than a prototype to test the function of the tools being used as it would be a waste of time and would likely result in trying to force a game that didn’t fit.

The other felt that the desired end result needed to be decided first as a guide for the design process going forward and felt that beginning work on something without having a clear and total product idea would result in a lack of direction, which would get complicated and problematic.

Both had merit, both were missing the design consideration being asked by the brief.

The brief was trying to make the designers consider more than just the device itself, but rather how the device could be modified and how that would affect the game designed for it. One example was to cover the drum pads in flesh rubber and to require the player uses their hands instead of the drum sticks, this would suggest a slapping game of some kind. etc.

This misunderstanding was brought to the attention of the team after a week of correspondence on the development methodology to be used and this forced the final tear between the developers who proceeded to split into two teams. One of the divergents was insulted by the suggestion that they had misinterpreted the brief and the other was not comfortable with proceeding by the method being proposed by the current lead designer.

Looking back, these kinds of clashes would have been common and debilitating to the entire team if the split hadn’t happened as early as it did. The true cause of the friction was probably due to the amount of messenger and text based discussion and team contact that was taking place over face to face. This particular problem has been observed by both of the primary people involved in their previous teamwork and has been documented in the postmortems for them as well. Text based communication always resulted in friction. Remembering that, there was more of an effort to have face to face time for meetings and development, but due to the early need for rapid decision making text based contact was unavoidable and this is where the tensions started and evolved to the stage they did.

Language is a sophisticated thing that is hard pressed to be conveyed my just the words used. As other project were being developed after this period, there has been more of a focus on using voice based communicate when having meetings or making contact and it smoothed much of the decision making. In this particular case, the end products of both teams that resulted from the split are very cool and unique. I think that there would have been a diminished return in the final product had the team tried to force the cooperation as it would have needed to. Having worked on another project that had a team split due to conflicting methods previously, seeing the signs that suggested reparations were going to be more effort than they could pay off allowed the split to happen early in the project which lead to more time to focus on making something within both teams’ time frames and means.

Too many words:

This is one of the first projects I have been involved in that has had time to be polished. Granted that the focus of the design was about player feedback and interaction. The final stages had a “How to play” walk through that was immediately noticeably inefficient and poorly designed.

Each of the controls has a chunk of text describing (in words) the effect and also the context. The context is utterly unnecessary. It took too long to read about an unfamiliar system for such a straightforward game. This over explanation has been observed in other games where i have been in control of this area of presentation.

Moving forward I am going to try the most appropriate methods of briefly describing the controls of games and finding ways to reinforce the described player actions with images or by immediately following up the instructions with a manner for the player to try the instruction and see the result.

GDS230: Out of Controller

Studio 3 begins. Off the bat we’ve been given a task to stretch our sense of interaction with games. Sounds pretty heavy but seems to be another exercise in lateral thinking. I feel like this task is designed to break us students out of our sense of limitation and I’m sure is designed to encourage us to look at our limitations differently when trying to create a game or experience, whatever you want to call it.

OutBoximg.jpg

CIU212: That’s So R’lyeh

Audenticla.jpg

At this stage of my degree we enter the preparation phase of what is to be our capstone project. this is an interdisciplinary project that involves the collaboration of students from different courses to try and achieve a finished, industry-level game. It is ideally designed from the ground up in order to best show off the skills of everyone involved as a product to be released professionally.

Project Management

Cosmic traveller was very much treated as a common goal partnership. Together, Victor and I created a full rundown of the elements we wanted for the final game and wrote, revied and rewrote the FSD as required until we both felt we fully understood each part we intended to make, where in the game it would be implemented and what the purpose of the element was going to be. This allowed us to each make judgment calls on whether or not eh element would serve its intended function, allowing us to cut or refactor other things as we went. The key was that we were in consistent contact and quickly created a habit or doing work, logging work, getting the other team member to review the work so that we were both up to date on the entire development of the project, and planning or making changes where necessary. I understand that this level of solidarity would not be feasible in projects that involved many more people in the production pipeline and that trying to would become unwieldy very quickly, but it was a good experience to have as reference.

Play Testing

We used questionnaires which allowed for ranges of answers and perspectives of the game play experience but with questions we knew were the same amongst multiple testers. Using common questions to allow for common answers to be obvious and quantifiable.

Using non-leading, open questions allowed for us to get data that was formed from personal interaction which was particularly interesting in Cosmic traveller where we had actively tried to create a form of narrative and saw the other people were creating their own story that was similar but not what we were trying to push necessarily. Direct observation of gameplay allowed us to view what they players were doing and in what order. Taking notes AS they played meant that very little was getting left behind and allowed us to develop specific lists of issues and suggestions and we could systematically decide on actionable solutions by directly relating it to the observed behaviour and order from which the occurrence happened.