October 13, 2018
Release day, that's always been the goal, and now it's only 9 days away.
So after ten and a half months, where has all time gone? Originally we thought this would be a quick 4 month project, but now it's two and a half times that long, why?
Part of it is obviously our inexperience making a video game - it took three months just to finish the planning stage for the game, picking the engine, doing level mockups, designing the classes and bosses, doing research on a bunch of social-justice terms and concepts. It was probably a little overkill, but it's been a useful base for the project and I don't regret it.
Three months later, at the end of June, we sent out the first version to testers to get feedback. You could call it a vertical slice, but by that point we had built out most of the core code that the game would be based on. We didn't have all the classes or bosses done, but it was enough that the testers could get a reasonable idea of what the experience would be like and give us suggestions and improvements... and that's when everything fell apart.
Internally we thought the content we gave the testers would be simple to understand and take a minimal amount of experimentation for typical gamers to carve their way through the level and beat the boss. It was supposed to be a bit of trial and error with a handful of abilities, no tutorial except for few lines of text in the help menu to explain the novel spell combo system. This was so far removed from the reactions we got that we had to design a full area for a tutorial, and completely revamp the camera system.
Five weeks later, a week into August, things were finally starting to come together again. It had been a lot of back-and-forth with the testers, but in the meantime we also implemented a save system, redesigned the way the levels were generated so that it took 15 seconds instead of a minute and a half, and completed all the enemy classes. Big steps.
The rest of August was a blur of testing and revisions, especially focused on the UI, and still struggling to get a thumbs-up from the testers about the difficulty level. We'd been slowly pulling levers - adjusting distances, damage amounts, and generally just trying to make it easy enough without making it boring. At this point I was kind of at the end of my wits, because we'd cut so much of the difficulty, but we were still being told it was hard. I assume part of this is just because the gameplay is a little different than typical genres, but there's only so much you can put in a tutorial before it seems patronizing. So we gave up.
On the last day in August we put in an easy mode. Because our gameplay is two-part, the enemies and the bosses, the easy mode basically guts the difficulty of fighting the enemies and lets you focus on boss discovery. It doesn't force you to move fast to avoid aggroing enemies, it doesn't penalize you for ignoring the combo system, and it doesn't throw minibosses at you. Basically it allows you to ruin the experience for yourself, rather than spanking you when you mess up and expecting you to do better. And of course we made it very clear on the menu that we don't recommend it, and it will ruin the intended experience.
By late August we also had all the voice acting done, so September was primarily focused on the scripting and models for the three ending cutscenes in the game. It would probably be a lot easier to just record them, but we wanted to do everything in-engine to avoid doubling the size of the game unnecessarily with a bunch of video files. We also added the Steam achievements, which will be a big deal for some people. You only get those if you play on Normal mode though, no participation trophies.
And October has been a flurry of performance tuning and bug fixing. Still 9 days to go and we'll probably use all of it, but the release date was mostly chosen by the other popular releases this month - trying to avoid getting overshadowed by them. A release on October 12th would have been the best, but in my opinion we weren't going to be quite ready. And the next week had a ton of newsworthy or popular games, especially toward the end of the week, so releasing on the 19th would have been terrible timing.
It's almost time to see if our design decisions were correct, and I'm very excited. It's been a lot of work, and a good learning experience, and I'd be delighted if we sold enough copies by the end of the year to fund another game. I have the title, genre, and general theme of it already worked out, and even though it's a bigger project I think we could finish it by October 2019. We know a lot more about game design now than we did 10 months ago.
Sept 25, 2018
It's interesting to watch features evolve during the development process. Our game has a limited set of mechanics that you mix and match in interesting ways, and originally one of those was supposed to be Event Cards, which would be dealt to you at certain times throughout the game. Each one would pertain to a specific buzzword, and have buffs or debuffs depending on your character.
When we were designing the interface, it just seemed too complicated from a UI perspective and not crucial to the core mechanics. So we had a sidebar that would pop up events every 5 minutes instead, delivering these same buffs, and you could click on it to read about the event.
During the balancing phase we realized that these buffs we had prototyped really didn't add to the balance or feel of the game, so instead of wasting time fully implementing 100 different combinations that impact your character in inconsequential ways, we just dropped the buff concept completely, but still wanted to keep the events. We tossed around the idea of doing an unlockable mural that you could use as a desktop, where each of the 100 events would unlock one square, and if you beat the game the rest would unlock. This seemed okay but again not a perfect or exciting fit.
Then another better concept arrived - we could have minibosses (more powerful versions of the enemies on that floor) spawn every 5 minutes, and each one would have an event attached. This dovetailed much better with the overall design of the game.
Now that we're in the final testing phase this still seems like a nice gameplay feature, but as I look at the events themselves I still have doubts about them. Sure they have interesting facts and messages, but it's a mistake a lot of the SJW games make - overbearing messaging that turns a player off or annoys them.
And although we have a checkbox to disable the event popups while keeping the minibosses themselves, I think we may just remove the event text entirely. We'll probably leave one sarcastic popup as an introduction to the miniboss concept when the player first encounters one, but omit the essays worth of text and research we did on the 100 concepts and buzzwords. While it's interesting, I feel like it interrupts the flow and intrudes on the game a little bit, and that's a disservice to the really good gameplay, creative boss fights, and excellent voice actors.
This doesn't gut the theme of the game by any means, there's still plenty of narrative attached to each boss fight, the theme of each floor, and each of the three endings, and I think players will enjoy those experiences far more than blocks of text, no matter how interesting the information might be. Sometimes you have to cut good content, because no matter how good it is, it just isn't the best fit for this particular experience.
Sad to see it go, but very happy with the state of our game.
July 13, 2018
We've mentioned it on social media several times - but if any of you are wondering why we delayed the game, it's because we decided to forego early access and just launch a full and final product. That pushed us back an extra 4-6 weeks that we were planning to test and polish while getting feedback from the players, but I think this decision will get a better reception. It should be out before the end of July by my estimation. Steam has approved the game, so we can release it whenever the team feels it's ready.
I've been holding off on writing new dev blogs because we're in the final push to complete the game, but an issue came up yesterday that's just too perfect, I have to write a little rant about it.
One of the features we thought would be useful is a player-music jukebox, for anyone who prefers their own music over our soundtrack. It isn't crucial - people could just open up an external audio player - but it seemed like something that would be a quick extra.
How wrong we were.
I've mentioned before that this is our first game and discussed why we chose Unity, and part of that assumption was as an easy framework with a lot of functionality already built-in that just needs to be customized. What we didn't count on in our scheduling was how much customizing and re-coding would be required to fix a lot of basic functionality. Luckily, like in this situation, their asset store can be used to quickly plug gaps that should be default functionality - but it still takes extra time and money.
The first hurdle was allowing the player to select their music directory. Great, simple, that's about 10 to 20 lines of code, no big deal. Except that one of those lines is EditorUtility.OpenFolderPanel - and those of you who have used Unity extensively will already know where this is going. Unity has some code that will only work in the editor you use to build the game, it won't let you build it into a final product. One of these items happens to be their file/folder chooser.
It's a mystery to me why they wouldn't fully implement that for devs, considering it's basic functionality and they're a cross-platform game toolkit. But anyway, I stumble across that tidbit in the docs after our folder-choosing code is already working, and with a quick test I confirm that the docs are right - the game won't even compile with that code in place. Fine. Great. We'll have to work around that. Let's just get the mp3 reading/playing working, and we can replace a line or two of code to fix the folder picking later...
A few doc pages later...
Well, it turns out that Unity doesn't support mp3 playing except on mobile platforms, because mp3 licensing/playback used to cost money. From everything I've read on the subject it seems like those patents expired a couple years ago, but Unity doesn't seem to be in any hurry to enable it on their platform. Maybe there's another license issue blocking it that I'm unaware of, but the dev community consensus seems to be that mp3 playback should be free to implement now without any fees. So that's great - another feature we assumed would be simple to implement just doesn't work. We can't reuse the code we already wrote to play our own soundtrack.
So at this point I'd personally wasted about half a day of research into these two topics. So to avoid wasting that time with no results I head over to the asset store to see if anyone else has solved it. Now if we were only releasing on Windows and Mac there are a few solutions that use the native file/directory interfaces, which is what I wanted, but none had support for Linux (probably because Linux has a few different popular GUI choices that might require unique code). Underlying file access is the same for every platform though, so there are a few packages that support all three platforms using custom Unity interfaces.
And after a few experiences with the asset store I know that whatever option we choose, it's going to take at least half a day to customize or make work properly with our project, it's just the nature of using random code from strangers. Even if it looks pretty on the store it's rarely plug and play, and even if it does work easily you still want to customize the visual elements so that it doesn't look different from the rest of your project. So we picked a folder-chooser and moved on to the mp3 players.
Surprisingly, the choices are extremely slim, but we did find one option that was way over-built for our needs, but it's easy enough to gut the code since we only need the playing functionality. It actually turned out to have the code to read the music from a directory, play, and randomize built in, but by that point we had already built out those functions in our own code, so I decided to just go with our solution and only use the actual music playing code from the addon. Code that we already had written for wav/ogg, if Unity hadn't intentionally handicapped mp3 files.
This is a single-day example of why Unity development, even though it may seem stupidly simple, is not actually so simple unless you're doing a no-effort asset flip. If you want to make a good and fully featured game you're going to contend with multiple areas where you have to write around or fix things that you would expect to be a basic feature of an easy-to-use cross platform development environment. Loading screens for instance do not work asynchronously without a lot of care and work, which defeats the point of loading screens entirely.
And while the asset store can make these deficiencies a little easier, it isn't a magic bullet that you can just plug and play, you still have to spend time testing, fixing, and customizing any solution you buy there as well.
May 09, 2018
We're almost ready to submit our game to Steam - about a week and a half behind the schedule that I mentioned in an earlier post. Three to five of those days were due to technical issues, and that's fine. I wanted to talk a little about the reason for the rest though, because it's due to intentional choices.
You need a trailer before you submit your final store page for Steam approval, and we've had ours storyboarded out - so we knew the visual elements that needed to look complete before we could create and release it. In the case of our game it shows most of the basic systems, meaning we either had to build them all out, or fake them in a realistic looking way. With our tight timeline I was originally planning that we would fake some of the more time consuming elements and then use the next two weeks to implement and polish the game, but as we hit delays I reversed that decision.
I decided that it was better not to waste time faking elements, even if it meant completely blowing the deadline, because it was going to take half the time to fake features as it would to implement the full solution. In the long run this will give us more time to work on the game systems in the two weeks between store page submission and launch - and make sure they're really top notch - because the core will already be done right.
I've also been thinking about the nature of game design lately and realized there are two different approaches, one is much more time and labor intensive than the other. You can either build the game by hand, or (as we're doing) you can build systems that build the game for you. The second approach is smarter in my opinion, because you can have the generation rules use a seed value, and then if you want a static world in the final game you just lock it to a seed that you like. I think I mentioned that we're using that approach in an earlier post - it seemed like a natural choice that would save us time and effort in the long run.
But I hadn't really thought about how much extra time it would have taken to do things the other way. After testing the look and feel of the original design we decided the play space wasn't nearly large enough and ended tripling the area of each level. And instead of having to manually place elements to make it three times larger we just modified a few variables and it generated itself. An hour rather than a day or two of work, and our cubicle items (computers, books, etc) can be truly random rather than a few premade layouts that are repeatedly tiled through the entire building.
We use probabilities of how likely an item is to appear, and relationships between the items to make these random layouts more realistic and appealing. Not everyone has a computer, but everyone has a chair, and if they don't have a computer they probably have books and binders on their desk. And if they have a decorative shelf then they definitely have items on the shelf. So when you're designing your game, unless you're completely sure of every element from the start, you may want to build the system rather than the game. That way you can try it out and tweak it quickly - fast iterative development.
May 01, 2018
Everything was moving along quickly this past week until yesterday, when we tried to replace the placeholder gray character models with animated skin-toned ones. After hours and hours of time wasted troubleshooting and messing with shaders, we eventually decided just to switch the entire project to Linear color mode and rework the colors on the existing content. Over a day worth of work wasted troubleshooting the problem (and then tweaking the settings and colors on existing content so it doesn't look weird) and there are still a few buggy textures to deal with.
The problem that caused all this hassle was Unity's terrible color rendering in Gamma mode. We ran into an issue with Gamma mode before, with a shader that was blowing out the specular highlights on one of our textures, but at the time it was faster just to write our own renderer to fix the issue rather than converting everything for Linear mode. But now we have a new (and more complicated) issue with Unity just totally misrepresenting the colors on three out of the five skin tones we chose as a palette. The tans came out as grays instead, and you would think changing the lighting color would fix it but neither the ambient light nor the sun are the problem!
After looking at a bunch of possible solutions we agreed that it would be faster just to rework our existing content. In Amazing Race terms, we chose the brute force task that we knew could be completed, rather than the skill task which was more uncertain. At least we won't run into any more color issues from this point forward since Linear mode seems much more consistent in the way it represents light and colors. They may look a little off from what you'd expect when you're creating models - it seems like Linear is lighter than Gamma - but it's easy to compensate for that in your workflow.
It's a lot easier to deal with tweaking the shade of a color that didn't come out quite dark enough than it is to figure out why a brown came out as a bluish gray. And hey, at least our ambient lighting colors are tweaked to perfection now that we're using Linear mode... that was totally worth the extra day of work.
April 16, 2018
For the first time since we started the project I'm estimating we have less than a month left, even with generous time allowances for each task. That's longer than I'd like - the original plan was to release into early access at the end of March - but by that point we had only really completed the high level planning and simple models. But I don't regret spending extra time up front even though that's where our time management went "wrong", because the initial project that I brought into this process really evolved and grew as we debated it, researched the topics and analyzed other games' mechanics.
At this point our release timeline is basically predetermined by Steam, it's a month minimum from the time we launch our store page until the "full" (non-early access) release. Steam requires you to have your store page up for a couple weeks before you launch, so we can't just wait until we're finished and then immediately launch the game, and I believe Early Access is also a two week minimum. And we're definitely releasing as Early Access (even though the game will be complete) primarily because this is our first game, and getting balance feedback from the initial players will be very important. But additionally that gives us two chances at publicity on Steam, once from Early Access and a second time when we "release" the game.
Since we haven't done much marketing this will be crucial - the game is going to live or die on word of mouth from the first few weeks. The topic is controversial enough that I think we may get a little coverage as "the bad guys", but I also hope that some reviewers enjoy our gameplay innovations as well. We're not reinventing the wheel, but I think it's a fresh take that mixes a few genres in an appealing way. It will be a little disappointing if everyone overlooks that in their hurry to be outraged.
So if we can get our "Coming soon" store page up on Steam in the next two weeks that will put us on track to launch mid-May, and be out of Early Access at the end of June, one month before the Summer Steam Sale. Hopefully that won't lower our sales too much with people waiting for that. We'll probably do a little (10% ~$1.99) discount, but nothing major since the game will be so new. But I think that waiting to launch after the Steam sale would be much worse, since people spend their saved cash on the big events and then aren't looking for new games while they play through their newly acquired backlog.
We probably could have done more work in March to keep to our schedule, but overall I'm satisfied with the progress we've been making - there's just a lot of feature creep and scope changes when dealing with your first game development project. Normally you might question or regret feature creep and design changes, but in our case they were definitely beneficial to our overall design and make it a far better product for a little extra time spent during the planning and design phases.
I'm trying to hurry this last stage so that we don't totally blow our release window, but I also refuse to launch the game before it's properly finished - you only get one shot at a good impression, especially in an environment where there are typically 25-50 games released on Steam each day. Here's a quick recap of what we've accomplished so far each month:
- Name choice
- Sales numbers research (budget/expected sales)
- Steam Direct research
- Graphics engine choice
- Music selection
- Organizing/culling tons of research notes (setting project scope)
- Tech tree design/redesign
- Modeling software choice
- Voxel pipeline/process
- Social media accounts
- Initial set of office models
- Additional decorative office models
- Legal advice
- Boss ability designs
- Initial set of outdoor models
- Initial Unity level coding
April (until present)
- Completed full set of outdoor models
- Added reflection shader
- Random generation of outdoor and exterior of level areas
- Added water shader
- Player camera controller
- Basic AI added (still needs a ton of work)
- Constructing premades for models to make interior level generation easier
April 12, 2018
A week ago we started with this simple mockup to figure out the scale and dimensions for our campus, and now we have all the exterior areas complete.
After three months of work I think we're finally out of the high-concept phase of this project. There's been a learning curve since we haven't released a Unity game before, but things are going pretty smoothly.
We chose to use a combination of random generation and scripted rules to create a lot of the structures to avoid the tedium of hand-placing a bunch of assets precisely. This also has the added benefit of allowing us to resize the play area as we test the game, easily adjusting it by changing a couple lines of code rather than manually adding or removing a ton of individual game elements. It was a practical decision, but we don't want the style of the city to change every playthrough - so we generated a bunch of possibilities and then hard-coded the best seed number into the game - so that unique city is procedurally generated the same way every time the game runs. The interior of the building is a different story, that will be a fresh layout every single run.
For the sake of time and style we're going with a blocky voxel-based aesthetic, with precise textures for all the assets including buildings and landscape. One unexpected issue was the moire patterns on the city and campus, since they're relatively large and potentially distant areas. The Unity engine was trying to optimize and reduce the quality on things further away, as well as the inevitable antialiasing. Abandoning our clean blocky textures and using a trilinear filter on them made a huge difference. They still look blocky from a distance, and the blurring from the trilinear filter isn't bad even up close unless you've seen the original textures - players likely won't notice even if they explore the campus closely.
Surprisingly this also fixed the blurry mess that Unity was turning our road textures into at a far distance. I'm still not entirely sure how it mangled them so badly, but when the trilinear blur was applied it fixed the pixelated mess, so it isn't really worth looking into for now. Luckily we only had to redesign one texture (the campus buildings themselves), and that fix just involved making the lines wider than one voxel. The thin lines were creating moire patterns even with trilinear filtering applied, but once they were thickened up the problem subsided.
The Unity store is making me very thankful that we decided to go with this engine, because it significantly reduces the hours we have to spend hammering out basic algorithms and shaders. I know there's a certain disdain for buying assets from some gamers, but I think buying algorithms and shaders is just smart business. If it's going to take you multiple days or weeks to write and perfect a complicated algorithm that you can buy on the store for $50-100, don't try to reinvent the wheel.
Don't get me wrong, I think it's bad to just plop an asset into your game with all the default settings, but most assets (like the water shader we're using) are meant to be tweaked and customized to fit your needs. Reflections, transparency, sea foam, and even water color and wave sizes can be changed, and we evaluated each option carefully to get exactly the low-poly style we were looking for to compliment our voxel art.
If you're an indie developer don't let the pride of rolling your own solutions get in the way of success. If your burn rate is $100 a day and an asset is going to take you two days to create (which means it will probably end up taking four, let's be honest), and you can get what you need for $25 on the store, then the choice is simple. Buy it, tweak and customize it (don't let your game turn into a lazy asset flip) and you've saved yourself money, stress, and frustration, and still got the same end result.
And if you don't know your burn rate you need to figure that out immediately, before you do anything else. A lot of your decisions should take it into consideration!
March 27, 2018
As we've designed the boss fights, I've thought a lot about controls, and how much our game needs to train the players. You only have a handful of abilities, but they can be used together in creative ways - sort of like combining or creating your own spells in Magicka. And I wonder to myself how much we should hand-hold the players in their discovery process. Do you just give the players a list of the 5 buttons and tell them to play around with different combinations?
On one hand I don't want to drive players away by making the game too bewildering, but on the other hand the boss fights are supposed to be about discovery and ingenuity - the feeling the player gets when they figure out that Spell A and Spell B do something completely different than combining two of Spell B together. Or that Spell A can be used not only offensively, but as a shield.
I think the important element of this discovery process is conveying very clearly to the player that they're expected to use their head and discover things - because otherwise the moment of revelation is more "oh I wish I'd known that sooner", rather than "I'm a bad-ass for discovering that useful game mechanic".
The other struggle is whether making it a "hardcore" game will alienate too much of the potential player-base. We already settled on Unity to get the widest possible hardware compatibility - is it worth sacrificing a large percentage of those players that want to have their hand held through the experience? Will we even get those players if we sacrifice some of the artistic vision to make it easier for them?
And then I also look at something like Dark Souls that's wildly popular in spite of its difficulty, maybe even because of the difficulty, and think that perhaps there are some things you can't predict before release. Some things you need to just design the way you think is best, and hope that it resonates with the players.
This bothers me a little because I like to take a data-driven approach, and I'm willing to make small sacrifices if it's the difference between a success and a failure. But I think back to a 2015 article written by the Steam Spy creator, talking about audiences. He spoke of each game as an independent sale - suggesting that just because one Roguelike sells well doesn't mean those players are automatically potential buyers for your roguelike.
That sort of concept means targeting a game at all is impossible, and the thing you really need to target is quality. The question is if the 1.3 million gamers he says are looking for a quality experience, are all also experienced gamers. If that potential pool doesn't include many newbies, then hand-holding them through your control scheme is unnecessary, slows down the experience, and causes them to lose interest.
After some thought, I think our game is going to avoid the classic tutorial that I had originally planned on offering the player, and instead just have a minimalist F1 menu with a control diagram. Walking the player through every spell combination would ruin the exploratory experience, so we're already expecting our players to have a modicum of gaming savvy. So they shouldn't need to be told that WASD moves your character, and the 1,2,3 numbers on your abilities indicate the hotkeys.
Hopefully this is the right choice - it's one of a few crucial make or break decisions in this design process. It could be a total disaster if I've miscalculated how experienced the potential players are. Although I'm hoping we appeal to players who enjoyed World Of Warcraft boss fights, and those people should have a decent understanding of how to use their keyboard.
March 20, 2018
One of our biggest focuses lately is the boss fights - trying to design interesting mechanics that are a challenge for players to figure out, but still fun. We're also creating multiple complexity levels for each fight so each of the three playthroughs becomes progressively harder.
Although we had a few interesting ideas to start out, I wanted to research boss fights and really examine how they worked and what made them interesting - and I've come up with a list of aspects:
- Require specific types of damage (other types either do no damage, or reduced damage)
- Positioning (require the player to be close or far away, as well as hazards on the level)
- Movement (require the player to move, or allow the boss to move the player through things like knockback/teleport)
- Timing (certain moments when the boss can be hit or is immune)
- Minions (allowing the boss to summon them, but also allowing them to impact or heal the boss if left unchecked)
- Speed (both the speed of the fighters, and elements like interrupts where you're actually stopped)
If we add these elements to a small handful of base abilities it gives us a huge creative palate for designing interesting and dynamic boss fights. Our game is pretty ambitious with 13 different bosses, one for each level, but I'm confident they'll all seem distinct and interesting in their own right.
March 07, 2018
I haven't seen many developers talk about legal issues, but it's crucial to handle properly if you want a real business and not just a hobby. In our case it was even more important because of the harassment element that we discussed in the first blog post, but even for a typical developer creating a company can allow you to expense your costs for equipment and software, and save money on your taxes.
The attorney can also advise you on copyright issues, and having an actual company like an LLC can protect your team from being personally liable if your company does unwittingly violate a copyright and get sued. For such a small cost it's something any developer should consider, and it's always good to have a lawyer or two on speed-dial rather than having to frantically search for one when you're already in trouble.
What was that old adage? "An ounce of prevention is worth a pound of cure"?
February 27, 2018
I'm not quite ready to share the character models yet - they're still a work in progress - but here are a few of the props for our randomly-generated office spaces:
As I mentioned last week, we're using Qubicle to design these, and they export into really nice low-poly OBJ meshes. The best part is that we don't have to worry about grouping textures, the program does that automatically based on what you have visible in the scene. So we can easily export one OBJ and texture for all the small items on the desk, another for the cubicle walls themselves, etc.
As long as we keep the groupings logical and the texture sizes below 2048x2048 it should be compatible with almost every system, and hopefully will minimize texture loading and draw calls. We can always finely-tune optimization later, but good planning at the start saves time redoing work later.
The models are 1/4" to one voxel scale, which is a little bit of overkill for things like the cubicle walls, but it gives us the granular control we need for textures like the keyboard and pictures on the desk. And keeping everything the same scale just makes it easier for everyone, and prevents scaling issues or confusion when using the models in Blender or Unity.
February 20, 2018
The last few days have been much more productive than last week. Finally set up a YouTube/Google account and registered the website with Google webmaster/postmaster. Also had to make a few tweaks to the site to make it more mobile-friendly so Google will rank it better (and just for ease of use in general, if anyone actually reads these posts on a tablet or phone).
We've also finished testing the software, and it looks like we'll be able to use Qubicle to create most of the game items with voxels and export into game models, rather than modeling and texturing separately. Hopefully saving a little time and effort!
We did also try Magica Voxel, but the interface is harder to use, it has more limited model size, and most importantly it exports model meshes that are far less optimized. It seems like Magica Voxel treats each voxel color as a separate entity, rather than just another color in the final exported texture. So if you model Superman, the "S" on his chest will be multiple different meshes, one for each color, instead of a 2D logo.
Looking at the textures, I'm guessing this is because Qubicle exports a full image as a texture, while Magica Voxel just uses a color palette as the texture and applies the proper color to each mesh. Once we get further in the process I'll probably run some stress tests to confirm my suppositions with hard data - but my assumption is that a piece of voxel art like this laptop would be far less efficient if every key was a separate mesh with a single color.
February 16, 2018
This week has been slow going, feels like I only got 2-3 days work done in the past 6 days. I've done a fair amount of writing and design, but it still isn't actually complete and feel like I have more left to do than I did a week ago. The way I'm approaching the buffs and debuffs has shifted a little bit, and it requires a lot more flavor text than I had originally planned. But I have been designing more enemy types/abilities, which is fun!
A few other miscellaneous things have actually been making progress - legal stuff getting done, and also some work on preliminary model designs and mechanics. By next week we should have a firm decision on whether we can use voxel tools in our workflow, or whether the 3D models need to be made in Blender itself. The performance and quality are really the major issues, and we still have to do a few more tests.
I wish I had more to report, but it's all been fairly boring hard work.
February 10, 2018
This week we've mostly been working on the tech tree, abilities, and dialogue. It's difficult to strike the right tone in a game like this - because it's meant to be sarcastic, but they're also touchy subjects and you don't want to come off as mean.
Obviously some people are going to be offended no matter how delicately you phrase it, and those people will never be the audience for a game like this anyway. But the general public needs to come away with the impression that your creation is fun, not malicious.
So far the tech tree is 90% complete, the abilities only about 25% but I'm hoping to flesh out the rest of those tonight. We made a full list of possibilities so it's mostly just mixing and matching to get a proper balance at this point. And the tutorial and finale are written, but I feel like there needs to be a cutscene for each level as well. I'm playing around with the idea of it being more of a boss introduction than a story segment.
There is a story that flows through the game as well, but I'm not sure how many cutscenes we actually need to tell it properly, probably not very many. The bosses and humor are more important in my eyes. Hopefully within a week all these elements will be 100% complete and the voice actors can start recording the script while the graphics are fleshed out!
February 05, 2018
The soundtrack for the game is complete, and happily I was able to negotiate a good bulk discount since it ended up being 28 tracks total. That might sound like a lot, but I want the game to have a certain progression through sound as well as gameplay, and I wanted two songs for each of the 13 levels. A lot of indie games use chiptune or procedurally generated music, or just loop a certain number of tracks, but I was looking for music that would be iconic.
Of course I still want it to be something you can listen to repeatedly, I think that's a sign of a good song, but in the actual game itself you'll only hear a song once unless you die or replay the game. It will be interesting to see how players react, since the design on a lot of these elements is slightly different than the standard indie design practices you see in a lot of cheap games, but also not the carefully orchestrated and always-present soundtrack of a AAA game.
I'm glad that part of the process is over though, at first it's great - you're just picking out songs you like, but once you start figuring out how they fit together and need a specific tone or theme to fill in a gap in the soundtrack the hunt becomes much more difficult. And after a week of listening to thousands of songs you're exhausted and would rather not hear music again for a little while! But it's all worth it once you hear the final songs in sequence, and can listen to them repeatedly without wanting to change the channel.
January 24, 2018
This week my main focus has been looking at voice actors who might be a good fit for the dialogue, and picking out songs to form the soundtrack for the game. Going into it I didn't realize how incredibly hard it was to make a cohesive soundtrack that isn't chiptunes or electronic music. I think at this point I've listened to parts of over 1000 different songs, and found 7 that are excellent quality and fit together well.
A handful of them are from the same musician/composer - he's far more talented than most that I've listened to - but he doesn't have enough songs or long enough songs to fill the entire game. That's the struggle - look for more pre-written music that fits with his level of quality, or actually hire him to write more and deal with a potentially frustrating process of trying to get exactly the right sound? So far I'm still looking around, but if I can't fill out the rest of the roster in the next day or two, I may have to cave and see what it's going to cost to have the custom music written.
I'm sure it will be pricey, even pre-written songs can be $50-100 each if you purchase them from the more expensive sites, and those prices range upward to $200-300 per song if you're talking about using it on a game that sells a lot of copies. Those prices aren't quite as bad as they sound - it works out to about 5 cents per game copy, and you only have to pay for the higher tier if your game actually sells well. Some places are much more affordable though, if you can find music you like in their library, somewhere in the ballpark of $3 per song ... but I feel like good musicians deserve more compensation than that.
January 20, 2018
Over the past couple days I've been considering the branding and name of the game. Originally my working title was "Progressive Stack: Smash The Patriarchy!" - and I was worried the first part of the title might sound like a card game to anyone unfamiliar with the SJW concept "Progressive Stack", which is why I had added the "Smash The Patriarchy!" tagline.
But with that additional tagline it's quite a mouthful, and after some consultation with friends I decided it was important to change it into something more accessible. I don't want the appeal of the game to be limited to the niche group of people who are already familiar with SJW concepts and terms.
Because some of the gameplay elements involve rainbows I thought Shoot Rainbows might work as a title. Unfortunately after talking to friends, the title gave the impression of rainbows and balloons - a younger and more pure demographic and concept than I'd like to portray. Other ideas about Triggering and Snowflakes were bandied around, but I kept coming back to the rainbows idea. What about "Puking Rainbows: Cult of SJW" instead? It's a little more edgy and removes the kid-friendly stigma.
This was controversial and had mixed reactions - some people liked the first part of the title, others liked the end, but no one really liked the whole thing. I wasn't sold on the reaction. Thankfully, the idea for "Rainbow Cult" came out of that word jumble, and seemed to resonate well with everyone I asked. It's a good mix of words that reflects the content of the game and avoids a lot of the misconceptions involved in the other titles.
Picking a good title is hard, but it's important to intrigue and draw people in - getting them to look at your game even if they don't buy it, rather than just passing it over at a glance. So always get feedback and make sure you're giving off the impression you intended!
January 16, 2018
I've been diving into graphics engines a little over the past week. This always feels like the hardest choice when starting a project like this, because once you commit you're locked in unless you want to spend a lot of time and effort rewriting code.
Right off the bat I ruled out the open source engines. I don't want to be dependent for bugfixes or features on a group that has other day jobs and just writes engines for fun. That's not to knock jMonkey or libGDX, they just aren't a good fit for this project. And since we're looking for 3D engines that also narrows the choices a bit. These were the options I started with:
- Source engine
- Unreal Engine 4
Source engine was an easy elimination - I'm sure it's great for free mods, but for paid projects you have to pay $25,000 up front for the physics engine. That's not a great way to start a modest project.
Likewise, Unreal Engine is great at what it does, but anything you make over $12k a year ($3k per quarter) requires a 5% royalty to them. On the off-chance that the game actually does become popular I'd rather not have to pay an extra percentage off the top if there are other reasonable alternatives (which there are).
Cryengine and Lumberyard are based off the same code, Amazon licensed a version of the Cryengine source for their own team. From what I understand they've made some nice tweaks, but it's essentially a fork in the code base, so any cool stuff the Cryengine team has added recently or adds in the future doesn't go into Lumberyard. It's also tied to AWS for multiplayer, and even though this game is single-player for now, I like to keep my options open and learn on the most useful platform.
So that leaves Cryengine and Unity. One downside of Cryengine is that the newer versions require "D3D feature level 11.0" - which basically means it won't run on older graphics cards. So do I care about supporting computers with older graphics cards, or am I just aiming for 2011 and newer computers?
Let's take a look at Steam's December 2017 hardware survey
. Obviously this is opt in, and the numbers don't totally add up, but it will give us a good estimation. If we ignore DirectX 9/10 users we'll be losing about 50% of the users on the platform. Now whether we can optimize the game to run on their low-end hardware is another question, but it's probably not smart to cut out 50% of the market.
Unity still supports DirectX 9 with shader model 3.0, so we're only cutting out 15-20% of the market if we go that route, based on Steam's estimated numbers. Since Cryengine doesn't have any features that I really need (I just wanted to go the more professional route if possible), I think Unity is the definitive graphics engine choice for this project.
January 14, 2018
We've talked a little about price-point, but there's one other money-making factor that most people don't take into account - Steam Trading Cards. I was planning to put them into the game anyway since there's little effort involved, and people enjoy collecting, but the revenue aspect adds an interesting twist. Developers actually get a cut of the money from the purchase/sale of trading cards.
Steam actually only gets 5% of the transaction fee you pay when you sell a trading card, the other 10% goes to the developer. Obviously the prices are pretty low, so you aren't going to make bank by adding cards, but it's nice that you get a little cash for adding a feature that players like. And the players make a little free cash in the process too!
January 13, 2018
There are a few people who have shared their sales numbers and experience in indie game making, and the general idea that shakes out seems to be: "You aren't likely to get rich doing this."
I've been thinking about price point a lot, and reading about the impact of putting your game in a bundle. Of course it moves a lot of copies fast, and gives you a little bit of exposure, but I'm not sure that it's really the right move until the game is at least a year old. It depends on how quickly your sales fall off after launch I guess.
As a consumer I love bundles - a variety of cheap games that I can play around with and not break the bank - but I'm always intrigued by the handful of games on the market that refuse to participate in sales or bundles. It adds more value to the purchase, but it also has to be something people desire if you want to pull it off. Making "Random platformer #24728" and then refusing to bundle it probably isn't going to earn you any extra desirability.
Here's how I'm judging the success of my game, after looking at sales figures across a broad selection of titles on SteamSpy:
|500||Abysmal failure, chalk it up as a learning experience|
|50,000||Moderate success, game had niche popularity|
|250,000||Popular, resonated with mainstream|
|> 1,000,000||Wildly popular, highly recognizable name in gaming|
Granted those numbers can sometimes be over the course of two or three years and include the game being in bundles. But even at the abysmal failure level, I can pay for my own costs and burn rate (unless I literally sell something ridiculous like 10 copies), so that's comforting. Though from a success perspective, unless I can sell 50,000 copies I'll consider it a failure, and that's going to take a lot of work.
I'm playing around with price points, and I think $24.98 is going to be the full price for the game, which is a little on the high side for indies but gives me good flexibility for sale prices. I'm expecting most sales will be made with at least a 20% discount, making the real price around $19.98. That sounds more approachable, and still leaves an opening for deep discounts to $10 for special events, or even $5 after the game has been out for a few years.
The important thing is going to be timing - you don't want to promote the idea that if someone waits a month they can get your game at half the price it is right now. I think those deep discounts will probably be reserved for a year or more after the initial launch, assuming the launch can move a decent number of copies. If it never gains any traction at all then that completely changes the game, because sales would fall to zero, rather than 10-20 a day, and basically be a dead product without a sale.
This is my hope
for what the sales breakdown looks like:
|$20||25% of copies sold|
|$10||25% of copies sold|
|$5||50% of copies sold|
But those distributions will most likely be completely different. Fingers crossed that I sell enough that I can give you guys a good retrospective on how reality differed from my hopes and plans.
January 10, 2018
Welcome to my first gamedev blog post. True, I'm just a nobody, but I'm documenting the process and struggles of making my first game on the off-chance that these struggles are worthwhile for another fledgling game designer in the future.
I have a general timeline in my head, one that I know is insanity, but I'm going to try to hit the targets as closely as possible to avoid spending two years developing a game that no one wants to play. My target is more like two months, although I know that's going to become three months by the time this is all over.
At this point I'm about a week into the process. Don't get me wrong, I've been mulling this idea over for several years and know exactly how the game will start and end, but all the middle parts need to be filled in. This past week has really helped - I've been researching the topic, doing a little world-building, watching a bunch of videos from the Black Shell Media gamedev list, and I feel like it's all coming together.
The important part is the core mechanic (not the topic), and although I had a general idea when I started, this week has really allowed me to condense and refine how that core gameplay will work. It's crucial, because if your core concept is fun to play on its own, then you can add sparkle and story later without it feeling like empty, repetitive, fluff.
The other difficulty in my case is that the subject is a controversial topic. On one hand this helps because it will stand out more if I do a quality job on the design. It also hurts because the culture of doxing and harassing people you don't agree with - even if their work is satire - is exceptionally strong right now. And that makes marketing on anything other than shock value difficult, because I can't build relationships without exposing myself or anyone I'm working with as a possible target.
This doesn't scare me, we can't allow bullies to have a chilling effect on our society, but I am being careful about the way I approach it to avoid making myself an unnecessarily large target. There's a fine line between standing up for something controversial, and openly taunting people to attack you. If it does blow up in my face, hopefully I can contain the backlash to my own life and not let it impact those working with or around me.
It would be nice if we didn't have to worry about such things in a supposedly free and open society. I realize that freedom doesn't mean you can do anything you want without consequence, but it also shouldn't mean that you're technically allowed to step out of line, but will definitely be punished for it if you do.