Introduction

First off, I wanted to get it out that this game, “Howloween Hero” was developed by Gossamer Games. While I was part of the development and the core development team, I was not THE developer of the game. At Gossamer Games, we had a core of three members work on Howloween Hero. Thomas Sharpe: Director, Nina DeLucia: Artist, and myself: Programmer. We did not create the entire game ourselves, we bought many assets and contracted out work to some of our friends. I’ll go into more of that in the later bits of the blog.

Now, this postmortem is MY postmortem and so I can only express the thoughts and opinions of myself and what I believe to be the opinions of my colleges. Gossamer may at some point make their own postmortem that I can link out to in the future.

With all that out of the way let’s begin!

Overview

Before getting into the project and what we accomplished and failed on. I want to set the stage for our current experience as a team, and what our goals were in making this game. Before beginning development of Howloween Hero, our team successfully launched one in-house project “Sole” and one client project, “Code Tycoon,” and one grant funded project that was more live-event than game, called “Civil Dialog.” We had also worked on 4 other grant-funded projects that either lost funding, or were currently in production. All of these titles had been developed in Unity, and we had very minimal experience working in anything else. Our previous title Sole had launched on PC, Mac, and Xbox One. Even though we had plans for it to launch on PS4, Switch, and Mobile as well, they had not been developed.

In starting to come up with an idea for a game we wanted to work on, we wanted to not only be able to have commercial success with the game, but we wanted to be able to grow as a studio, diversifying the kinds of games we work on, and expanding our skill set and toolbox. We also wanted whatever game we worked on to be developed quickly. Our previous game, Sole was not only our first game, but it was a student game. Because of this, the game was kind of in “development hell” always getting pushed back, we never knew how long anything would take or how far along we were, what was considered reasonable for release, etc. And the game, while simple in gameplay, was vastly over scoped in terms of different environments, linear/scripted sequences, original dynamic music, different movement systems, unique art style and gameplay, etc. We knew that this game we wanted to be incredibly small scoped and focused on the elements of game dev that we had not been able to work with much previously. These elements were: dialogue, story, 3D animated humanoid characters, character clothing, and physical objects. The final goal, the one that really mattered to us the most was, develop the game in Unreal Engine 4, so that we can learn the engine and use it in the future. These goals coupled with the goal that we wanted a marketable game that could appeal to kids, and release in about 6 months of development, we looked ahead in the calendar and saw Halloween would be just a couple weeks out from our target deadline. Once we hit the idea of a little dog dressed in a ghost costume trick-or-treating for their owner, we were sold.

What Went Right

Buying Art Assets:

One of the things Tom knew right off the bat when we started this project was that we didn’t have enough resources to handmake all the art for the game. With one artist and less 5 months to work on it, it just wasn’t possible. Luckily we were able to find asset packs for almost all of the art in the game. The entire town was already in our library from picking up free assets earlier. We went ahead and snagged the farm pack by the same creator and mixed and matched. When looking for the dog, same thing, we went and found a nice looking dog, bought it, same goes for the animator controller and IK for the front paws. When it came time for Halloween decorations we bought them too, and much of Nina’s time was decorating the environment with them. We had a terrible looking UI, Tom went ahead, found nice UI, bought it, and put it into the game and quickly we had all the assets we needed for the UI, environment, and player character. All of this at a fraction of the cost and time of developing them in-house. That being said, we still had to retexture some assets, and change animations and work on these, but it sped up the initial process.

Character Creator:

Along with buying environmental assets, we knew that we couldn’t have many 3D characters that were animated and different when we had barely any experience. Let alone having facial animations! Instead, our artist focused their time on creating characters in Character Creator, buying or creating their costumes. Developing their personalities through the way they looked. They also found animations on Mixamo and imported them into the engine and fixed them up to work with the Character Creator Skeleton. She also spent time creating preset blend values for the facial expressions so that we could jump between whatever expressions we needed. This was done and we were able to support the 30-something characters that we had in-game! If not for Character Creator, it could have taken the entire development time to work out the correct format, skeleton, and facial rigging pipeline. Even with Character Creator, where comes out-of-the-box, we still spent months refining and updating this process.

In House Dialogue Editor:

Going into development we knew this would be a very dialogue heavy game. We needed initial dialogue, starting quest dialogue, responses that varied based on what item you brought back, as well as dialogue once you finished the quest. During the initial prototypes of the game we were using the UE4 data tables (a csv like structure) to house the dialogue information such as: associated quest, dialogue, required held item, etc. And this workflow was incredibly difficult to tell who the dialogue was for, which dialogue followed, what dialogues would complete the quest or start it. We knew we needed a better solution, and so once again we went to the asset store and picked up the expensive Assent Dialogue and Quest Tool. This tool seemed really good, plus it was promising to us that the developers were working on The Ascent, a top-down shooter that looked extremely professional. However, once it was in the project we spent over a week trying to migrate our old system to use this new dialogue tool. It just didn’t allow us to do things like pick dynamic starting dialogue nodes easily. Everything required a separate blueprint to be made and it was quite challenging to wrangle. However, all was not lost! As I had access to the code, I was able to take bits of it that I liked and create my own dialogue system building on top of Generic Graph. I was able to go through that tutorial and get a basic dialogue graph editor working and integrated into our game in less than two days. This was super beneficial, as we expanded the dialogue system to control what animations the characters played, what time stamps the sequences should go to, custom functions to run before and after the node is passed. I was able to create custom nodes to automatically dynamically pick a random node from it’s children, etc. This was something we developed over the course of development and added to it with whatever we needed at the time. Having this flexibility was super beneficial to the development!

Community Engagement:

When launching the game, we had no fanbase. The only people finding the game were through steam and our announcement tweet that was being promoted with Twitter’s Ads. As the development time was so short, we really didn’t have time to play test the game as you should with people. Many things such as Steam achievements were not tested well. Many things were simple fixes that we wanted to make for a long time, but were just low on our list of priorities and didn’t make the cut. Watching Let’s Plays of the game, and reading comments and reviews really gave us tons of information as to what people were thinking and what problems they had with the game. What was better was that I would actually communicate with them to make sure their issue was fixed, and they were all the more grateful for it! 2 of our 19 reviews actually call out the fact that the developers were fast to fix their issues. And the one creator originally played giving it a 6/10, and after I went in and fixed the issues they had updated it to a 7/10.

When streamers were playing the game, the Gossamer account would occasionally pop in and say hello, maybe drop a couple keys and this was another thing that seemed to really spark a lot of joy in the people playing and their community. It’s listening and being and interacting with the community that I think has brought us much of our success with this title.

Narrative / Writing:

So this comes in two parts, both in terms of the overarching story, world and game design, but also the aspect of specific lines of dialogue. I think we did both of these things well. For starters, the world and overarching story. We specifically spent a LONG time in the beginning of development figuring out the whole story. We roughly knew the beginning and end, however, it was reshaped constantly over time.

Originally there was no Gummi Korn, you were just meant to collect candy for your kid, and we had lots of ideas about how you went to the big house, only to lose all your candy. We talked about putting your candy down, having it stolen, having you spend it all and then the big house is out, etc. But ultimately we wanted to make sure that the antagonist didn’t come off as a bad guy. We didn’t want to force the player to give them candy, and it especially didn’t make sense to give all of it when you could just give them half, after all, you have hundreds of candy. We also came into issues where, if your goal is to get candy for your kid, why not just trick or treat, never go to the big house and return home? What’s the difference between 500 small pieces of candy and one big bar? Especially considering we wanted you to spend candy to get costumes. It wouldn’t make sense to spend the goal of the game to get a costume which doesn’t seem required at all. It just didn’t add up, there were always small issues that came about when changing any number of these things.

Long story short, it seems like a rather simple story, but it went through revision after revision to get that initial setup correct. And we knew that if we had the beginning and end, the middle was just the journey, we had to support the mystery and introduce you to side stories, but it wasn’t critical what happened or how many quests or how long they took. This was the perfect setup, as we were tight on time, so if a quest wasn’t coming together we could scrap it at the last second and still end up with an in-tact game. If we were ahead, we could add another quest and it’s just more content for the player! The next thing that we did was come up with interesting characters, with interesting items that could be considered unique from one another to bring back, we had all temp dialogue for these and just needed the base structure there.

This is where the dialogue comes in. In terms of dialogue this is what we did well. We had the whole game completed and done with temp dialogue. You could play and beat the game up until a week before launch and it would have all been temp dialogue. The important thing was that the structure was there. What we did was, we made a document that said something like “Pirate Kid Start Dialogue :… | Pirate Kid Item X: … | Pirate Kid Item Y: …| Pirate Kid Finish Quest : ….” and we had that setup for every character, we had the current tmp dialogue there with the items you could bring them and everything. Then, we hired our friend to do the writing, and quickly and simply without even needing an engine he was able to see all the characters, what they were all about, what you could bring them and what their goals were. They wrote right in place exactly what they wanted, and within a few nights the script was written. We went to the document, and copied everything and pasted it into the game and voilà.

The genius here is two part. 1: Have the whole structure set with strict requirements and guides. 2: Hire a writer and give them all the strictest requirements and guidelines and allow them to write away, not needing to worry about the engine at all.

Promotional Art:

After we went through and watched some tutorial on how to setup your steam page for success. We learned one incredible lesson: Don’t use a screenshot, in-game assets, or in-house artist for your promotional art, unless their role is specifically in the creation of promotional art. This was crazy for us because we had only really ever marketed one game before, Sole, and that game was on a very limited budget and was our first game where we didn’t quite know what we were doing. The promo art for this game was originally screenshot renders of the characters against a Halloween Purple and we thought it looked fine! Well, we ended up dropping money hiring one of our old friends Jameela Wahlgren to do the promo art for us. And the difference is night and day and can be seen below. No matter where the user comes from, whether it’s Twitter, Facebook, direct link, a random site, or steam itself, the steam page is the final step before purchasing and if the page looks cheap, or unprofessional, or weird, it is likely to deter some customers. That’s why we found it really important to spend some money and get some really nice artwork for our page.

What Went Wrong

iOS Launch:

The biggest issue for us was for sure the iOS launch. It was our vision that this was a mobile first Desktop second game, and of course that didn’t work out. We made sure to build for iOS early, testing on our team’s devices, and we even submitted to Apple a couple weeks early to make sure we passed the review process. After passing we felt pretty good that when the game was finished and good to go we could resubmit and everything would work out smoothly. Well, that was not the case, it turned out we got kind of lucky/unlucky and passed the first time when we should not have! The reason being that it was crashing on iPad, a platform that we didn’t have as easy access to and hadn’t tested. When submitting for iPhone, you are also submitting for iPad, it has to build and deploy to both platforms as per Apple’s requirements. So after testing and making new builds and new tests over and over we couldn’t get it to open on iPad. Halloween came and went and still no iOS launch, and we decided that maybe at this point, it’s better to hold this update and wait until an opportune marketing spot opens. It currently seems that it’s a RAM issue, the iPad model we are testing with is 2 GB RAM. That crashes on start, our co-worker has one that is 4 GB and it makes it to the title screen, but crashes in the main game. Yet we have another iOS device that is 6 GB and that can open and run smoothly. Likely we need to figure out how to compress the texturing of the characters and their clothing into some texture atlas, it’s going to take a lot of work but will be required if we want to also get on Switch.

Characters Freeze Mid-Scene:

One other major thing we wanted to fix before launch was the fact that we have sequences with text and during them, the characters don’t animate while text is on-screen. This looks pretty bad, and we would like for this feature to be built into our dialogue system should we ever use it again. The main issue comes in that we have two different kinds of sequences in the game currently, dialogue driven, and sequence driven. The dialogue driven sequences have animated characters and animations that come from the dialogue, however, the main fault is that it can’t blend camera angles and blending animations and doing things along an animated graph are much harder as things only happen when you progress to the next dialogue node. The sequence driven sequences are done right in the sequencer (gosh that sentence). This means that we can animate the camera, blend animations, play SFX, etc. And in the sequencer we tell it “Now start dialogue!” and “Pause sequence until dialogue tells us to continue!” The problem with this is that we want the camera to pause and no more actions to happen, but we want the character to continue in some kind of idle animation. This does not happen, everything including their animation is frozen and it looks unprofessional.

Sequence Actions At Low FPS:

Now this is a terrible real bad bug. If your computer runs this game at a low FPS, the sequences in this game will just skip frames, and sometimes really important actions just don’t happen. Something like giving the character candy. So it’s possible to get in situations where you did everything in the game, but weren’t rewarded as such, meaning that you can’t 100% the game, this bug is terrible and we may have ways to fix it, but we also just need to heavily optimize to work on lower end platforms as well.

Applying the Lessons

So, as we move forward we are planning on once again changing up the kinds of games that we do, however, regardless of what kinds of games we make we have learned lots about their development and marketing.

Release time:

One thing that really helped us to actually release Howloween Hero and not just sit on it was the external time pressure of releasing by Halloween. The money and time is one thing but something like this really pushing us helped. I think we are going to try and time more of our future projects with external constraint, such as a GDC meeting, a specific sale, a holiday, a platform announcement, another game’s launch etc.

Marketing:

This goes hand-in-hand with the release time, however marketing the game leading up to release and knowing more about Steam’s internal algorithm will help. For this game, the marketing strategy was basically the complete opposite of Sole. For sole, there was a Kickstarter, we went to Boston Festival of Indie Games, Too Many Games, MAG Fest, Pax East, Pax South, GDC, IGF as a finalist for “Best Student Game” 2019, etc. We spent SOO much money and time on events it’s insane. However, because of this, the Sole page was up many years prior to release, and during some of these events we were able to get on the front page of Steam! Unfortunately the game wasn’t released yet, but we did get a number of wishlists! Steam likes games with lots of wishlists and so this surely helped Sole during it’s launch. With Howloween, it was the opposite, we never took the game anywhere or told anyone about it until it was cold announced on Twitter about two weeks prior to launch. We paid some streamers to play it and that was it. It was no time investment in comparison, and money wise it was much less as well, perhaps comparable to one of the events listed above.

The interesting thing here was that Howloween did quite well for having nobody aware of the game, as of right now we have sold approximately 180 copies and it’s been released for one month. It’s peak views happened after the Halloween Sale had concluded and we had gotten our first 10 reviews, giving us a 100% positive rating, and our boosted visibility from release was still active, so we were being seen in the Discovery Queue. Our highest day yielded over 11,000 page visits. This is all in juxtaposition to Sole which had it’s peek viewing at ~6,000 in a day. Sole to date (Oct 2019 - Nov 2021) has sold 499 units on Steam with 84% positive ratings. Yet Sole has people play it less (even though it’s a longer game), and has fewer reviews (even though many more sales). The engagement rate on Howloween is much higher, and that’s just because the game is better polished with better pacing and more interesting gameplay than the artsy walking simulator, however, there is still much to be said about the cost of marketing each game and what we got out of it in terms of sales, wishlists and page views. We did make Howloween Hero with the intention being that it would look like a marketable game that you might want for the holiday. But it did better than I could have expected given the circumstances.

In the future, I believe that we will try to go back to doing a couple big important events, but mostly keeping the count of those on the lower end. We will try to keep up a Steam page and accrue wishlists over a long time before launching at a specific time and date, where we may have also reached out to platforms earlier to ensure marketing visibility. We will run Twitter Ads and market our game to the people, and be responsive to their comments.

UE4:

To get it straight out, we will be using UE4 and 5 in the future. However, we will be using Unity as well. Each engine has it’s pros and cons, but I think the main thing it boils down to is speed and flexibility. You can be much more flexible in Unity, and develop much more quickly. However, Unreal is much better and can better support and promote development if you are making an average styled game. The things you lose in flexibility and development speed are made up for in better engine and game optimization, tools. If you want a game to run well under high-pressure, Unreal’s your engine. If you want simple scripting, a wide community and great flexibility, it’s Unity.

Development Timeline:

One thing I think was super important out of all of this was the timeline. Take Sole, a game worked on part-time for ~5 years. Then take this game which was worked on Part-time for 6 months. You can see obviously that we are much better developers, as we would never have been able to develop this in 6 months if it was our first game we developed. However, you can also see that we removed much of the attempted polish and complexity of our first title.

The point here is that in terms of development costs, every day is money. And as a small studio fighting to stay above water every day, it’s much too costly to develop a game for 5, 4, 3, or even 2 years. Each day that we work on something, we need to be paying for 3 whole positions, programs, contractors, etc. If we can lose some of the scope, some of the polish, some of the nice-to-haves, and release a game 6 months earlier, it’s much more beneficial to do so, and so long as the game is relatively bug free, we can always add in the niceties over time with free updates. I think that in order for us to be able to get to a stable position we need to make not a couple really good games, but a lot of really good games, because the hardest thing to do in this industry is get found, and with each successful release we get more games out to customers, we look more appealing to publishers, and companies begin to notice our company. As financial consultants say, “Never keep all your eggs in one basket.”