Insight - The new name for the Blind Game

So the game that recently I've been referring to as The Blind Game has been without a title for the last year and a half, mainly because I was having trouble coming up with the right name. I thought I'd come up with something when I made a story for the game. But as of yet, I've focused more on mechanics and gameplay rather than the story.

As I was falling asleep (A time when many ideas come to me. which is why I have so much trouble waking up early) the name came to me. Insight.

It has a double meaning. In- is a negative prefix on many words in the english language, ie Indelible, ineffable, indestructable. Given that this game takes away the player's sight, I thought in that sense the title makes sense,

It also represents how the game gives players without visual disabilities insight into how it feels to try to navigate the world without sight. While I cannot say that this game fully recreates the experience of blindness, it does it's best to simulate some aspects of that experience, while also allowing the player to imagine interesting scenarios using sound to invoke ambiance, to imagine these adventures for themselves. After all, as nice as the GTX 1080 or a Titan X is, the most powerful GPU in the world is the human mind.

Anyway, this is just a quick update about the game, now that it finally has a title. I'm currently in a testing phase for V0.1, and I'm starting to conceptualize the next level I want to add.  I'll continue to post updates here as the game progresses.

The Blind Game: Version 0.1

I've been working diligently on The Blind game for the last few weeks leading up to my next major test version, V0.1. In this time, I've been working on some new mechanics, some under the hood changes, some bug fixes, and a new level.

During the last round of testing, my blind friend had some trouble with the game. There were two reasons for this, but it inspired an idea for a new mechanic. He wanted some way to know where he had been previously, because he would keep walking in circles. He compared it to marking a location on a map, like clicking a location on google maps to make a waypoint.

It gotme thinking, because allowing the player to mark waypoints on their map is a really common practice in modern games, especially modern open world games, so I thought it would be reasonable to have a system like this in my game. Of course, if this were a game with graphics, I would just make a map of some sort, or make one of those visual waypoints a la Assassin's Creed or Batman Arkham City. But this is not the case, because this game doesn't have a map or visual graphics.

But I do have pre placed waypoints. Anything that makes a 3 dimensional sound in the game could be considered a waypoint as far as this game is concerned. So I thought maybe I should make it so the player can generate something that makes a continuous 3D sound and leave it somewhere.

So now, the player now has access to Flares as a new tool in their arsenal for navigation.  Unlike throwing Rocks however, the player has a limited number of Flares, so they need to use them wisely. They generate a continuous sound that can be heard in an immediate area, so the player can leave themselves something of a bread crumb trail in places they've already been.

The other problem my friend had was a mistake I made. After converting the project to Unity 5, there was a change made to the 3D sound system in the game, with the use of the spatial blend parameter on sound generators. The default for these is 2D, so all of the sounds in the game were now being generated in 2D, so all the sounds were smashed together and flat, so he had trouble getting a sense of direction, as had all players who had played the game. I thought I had just made the game too hard. Never the less, the newest version should be a lot easier for blind and sighted players alike.

I've also completed a new level for the game. The objective of this mission is to navigate through a cave. It is effectively a simple maze, except all the surfaces are stone, making using rocks alone to navigate difficult. Instead, one must also use the airflow through the cave to figure out where the exit is, by continually checking world state. One could of course also use the new Flare mechanic to mark dead ends.

This required me to further enhance my 3D sound systems to be able to have different profiles for different areas, such as the difference between indoor and outdoor areas. I also enhanced ambiance generators to be able to create reverb areas with custom parameters.

Overall I think these things come together to make for a great effect. I don't live near any caves, I've never even been in a cave before, so I had to try my best to replicate the sounds of a cave without a cave to record in (other than my house)

Now it just comes down to testing this version. I have some ideas for new levels, but I'd like to get the current versions to be as solid as possible. I hope to eventually make the levels more complex, with multiple objectives and puzzles, but even I find the game extremely challenging without those elements, and yet still interesting and fun to play. I want to really see where this goes.

The Blind Game, and Fundamental Game Design

I've been working on the still untitled game for the visually impaired, referred to as the blind game for short, for nearly a year and a half.  During this time, this game has taught me so much about game design, at it's deepest level.

As noted in a previous post, when dealing with a game that has no visuals, you lose some of your most basic tools as a designer for conveying information to the player. Where one might otherwise just put something on the hud, or just put a visual queue in the terrain, this is impossible in Blind game. The information is still important and needs to be conveyed somehow though, so you need to come up with clever ways to give the player the information they need to play the game.

This is what is at the core of this game, and any game really. The gathering of information. The difference between a good game and a great game is the effectiveness of the methods used to convey information to the player.

Think about old NES games for a moment, the ones that were less good and usually extremely hard didn't do a good job conveying information to the player. Some of them depended too much on instruction manuals to tell the player how to play the game, rather than through clever design. Others didn't even make an attempt to convey the information at all. Granted, some of these games were bad and hard because of other things, but often a lot of the problem just came from the player being unable to understand what the developer was trying to convey. Can you think of an old game that you were good at as a kid, but can't for the life of you figure out as an adult? This might be because as a kid, you were patient enough to sit there and figure out what the designer wasn't doing a good job conveying to you without even knowing it.

Or think about modern games. Some of these have the opposite problem, where they overload the player with information, whether it be through excessive exposition of the story, or through conspicuous, overwhelming tutorials that cause the player to tune out, making them just as bad as not having tutorials at all.

Expressing information in clever ways is absolutely vital to the design of a great game. It's sorta like sending an encrypted secret message to someone. Make the cipher too easy to crack, and it will be too obvious and easy to crack, and if you encrypt the cipher too well, then no one will get it.

In this case, making the message too obvious is like having annoying tutorial popups and really excessive plot exposition, while too encrypted would be hiding the instructions to playing your game somewhere outside the game entirely like in an instruction manual that, as time passes, inevitably gets lost.

The key to this is evenly spreading just enough information through the game in such a way that the player can always find it if they need it. Use clever design to give them just enough to figure out how to play the game, then allow the player to find more advanced tutorials in the game, but make them optional.

The Beginners Halls in Final Fantasy VII are a great example of this. The visuals of the game are easy enough to understand that you can make it through the first bombing mission without any trouble, with NPCs dropping hints only where you need them, then if you want everything explained to you in detail, you can go to the Beginner's hall in Sector 7 to learn more. Even the Materia tutorial on the second day is completely optional. Just enough information is given to the player to get by, with more being available on request. Another example would be Metal Gear Solid with the Codec. You would recieve manditory calls, but the information recieved there was important, and if they player wanted more information, they could call for it at any time.

In the case of the Blind game, this is a much harder balance to strike. The entire game is information gathering without sight, so almost every action you take feeds back information on some level. Finding the balance point where the player is getting enough information is much different. After all, a picture is worth a thousand words, but all I have to express ideas to the player is words, and no pictures. This skews the balance.

What this means is making all methods of information gathering as tight as possible, making sure the player only gets feedback that is information dense and useful. Again, ideally this is the case in any game, but this is even more true in Blind game.

Right now we're dealing with balancing this, making it so the player has all the information gathering tools they need to complete the game, without overloading them. In recent testing (the game works brilliantly on OSX, by the way), I thought the game had enough information based on testing I've done so far. I found that this might not have been the case, and me and my friend talked it out for a while and came up with some great new ideas that I'm pretty excited about figuring out.

Besides all this philosophical musing, we recently straightened out a bunch of little bugs in the code, and now the game more easily transitions between levels. Level editing has also become significantly easier. I've found that a lot of optimization I did over the summer is now paying dividends, making level editing much easier, and saving me a ton of time.

Finishing the first level (which still probably needs some tidying up quite frankly) took well over a year to complete. There is now a second level that is nearly done, and including bug fixes, that has only taken about 2 weeks. I have ideas for two more levels as well, so we're really starting to make some progress.

I'll continue to update here as I continue to make progress.

Turn Based vs Action in RPGs: A Misunderstanding of Purpose

It seems like as of late, Turn based battle systems are falling slightly out of favor among the more famous RPG franchises in the world, and are instead trending towards more action oriented gameplay styles. Furthermore, beyond the bigger franchises, it seems like everyone is trying to smash RPG elements into their non RPG games, and in particular, it seems like ever since Kingdom Hearts came out, everyone has been trying to make the perfect Action RPG.

I am no exception. Ever since I could figure out how to string together basic logic in Game Maker I tried to mash the elements of these styles of games together into one. I've seen countless different attempts that try to mash different bits of the action and turn based gameplay experiences together, seemingly disregarding fun and instead focusing only on the hunt for their Moby Dick, which dooms the entire endevour in the end.

As I look at these sorts of games, and reflect on the design of the classic RPGs that make up many of my favorite games of all time, I realize that mashing the two together haphazardly is bad design. I've taken a step back and looked at what makes these games work, and realized where so many of these people go wrong.

It's the understanding of the purpose for each set of mechanics, and what gameplay experience is trying to be emphisized.

I feel like a misconception held by designers who try to combine these two gernes seem to have is this idea that Turn based battle systems were the result of a lack of hardware capability or something, that they designed these games this way because they were old fashioned and archaic.

In reality though, the design was intentional. In real time you can't really control 3 or 4 people at the same time and have them all take discreet actions, it's just not practical without some sort of AI controlling all but 1 of the characters. And if thats the case, you aren't controlling 3 or 4 people, you are controlling 1, with 2 or 3 AI bots, and lets face it, they aren't doing much.

The truth of the matter is that someone already figured out a way to control 4 characters simultaneously and allowing you to control each of their individual actions in a strategically meaningful manor. It's called a turn based battle system.

This is what the Turn based battle system is for, the strategic elements of the battle.

The appeal of this style is different from that of Action. Action is great for the flashier stuff. Or just the power fantasy of being able to beat 1000 heartless by yourself or do half the wild crap Dante does.

Turn based is fun for more strategic gameplay, more subtle and nuanced. You focus less on moving your characters around and instead issue orders to a group of characters, allowing each of them to specialize and giving you access to multiple styles of fighting at once. Rather than focusing on mastering fighting in a single style, you master the skill of managing the skills of a group. It's more the experience of playing as a general rather than an infantryman. To achieve this, Time is managed in some sort of way, usually splitting it into turns, which are discreet snippets of time where each character can act. This slows down the battle so that you can think clearly about each character's actions one at a time, rather than trying to mix them all at once.

Combining the two in too direct of a way is mixing two completely opposite gameplay experiences. There are elements that can work in both, like equipment systems and stats and such, but these can be shoehorned into just about any sort of game if you're clever about it. But trying to mix elements of turn based time managment with action based combat gameplay always just ends in awkward gameplay that makes no real sense. Usually these kinds of things play out with giving you control of a character in an action combat format, but for a limited amout of time, being treated as a turn, and just when you are start getting into the rhythm of the action, your turn ends and the fun part is yanked away from you, and you watch the computer take a turn. 

What you end up with is basically an El Camino, or a tablet with a bluetooth keyboard being sold as a "two in one laptop". It does stuff that it's two constituent parts do, but not as well as those two constituent parts would do them by themselves. As the two styles don't mix very well, they clash and conflict with each other, and end up making the whole signficantly less effective.

I feel that this is something people need to realize. Turn based systems aren't inferior technology or archaic, they're designed with a spesific type of gameplay experience in mind. They aren't meant to just be replaced by action style gameplay, they represent a classic paradigm that must not be forgotten.

9/18/16 Update, LOTS of Blind Game Stuff

I thought I had posted on here more recently, but the post seems to have been deleted, which is really a shame.

Given that I don't remember what I wrote last time, I'm gonna have to be more detailed this time.

So the big news right now is that I now have a stable, working test build of the Blind game. It's basically a proof of concept right now, but it's all pretty much self contained. It's only one level right now, but this represents huge progress.

As of now, the system can currently cycle through levels on it's own, meaning that when it reaches the last existing level, it automatically rolls back to the first level and the game starts over automatically. At this point, since the game is only one level anyway, the game just loops that level over and over.

I've also added some new features. I now have an objective tracker built into the game, that allows the game to keep track of the player's progress through a level, tracking milestones as set by objectives or the new and improved special colliders.

The special collider was previously for just letting the narrator know about special conditions in a certain area, like tutorials or additional information I want the player to know, which could help them solve puzzles or just expose the world further. I have overhauled this system to have a few new and very significant features. First is the ability to do automatic narration. Entering a special collider marked as a narration event will automatically read the special narration in that area, which can be heard then again by hitting the World State key, which checks direction and what they are standing on.

The other new feature is what I call the Finish Line parameter. Setting this will make an area of the game effectively the end of the level. It will check if the player has completed all other objectives in the level, then if so, it will read the level outro and move onto the next level, or restart the sequence if the final level is reached.

The level intro and outro are another feature that is useful for giving the player good feedback. The intro is used to state the players main objective, and give them some background on the particular level. The outro indicates that the mission is complete. This kind of feedback is very simple, but I find it's absolutely vital to being able to run the game autonomously with the player by themselves. It gives the player a sense of what they are supposed to do, and allows me to give them the kind of information they need to play the game. It makes the game feel structured, and actually game like.

I've also added a new button to the control scheme, the Quest key, that allows the player to check their current objectives. It reads back objectives based on how many objectives are in that level. If there is only one for example, it will just reiterate the main objective, while if there are more, the system can iterate through each objective and tell the player exactly what they need to do, based on what objectives are still incomplete. I feel that this gives the game significantly more depth, allowing me to develop challenges much more complex challenges for the player, without making them feel too lost, since at any time the game will tell them what they are supposed to do.

Additionally, I've also added the escape key to the game. pressing it asks the player if they would like to quit the game or not, and allows them to answer the question with the same prompts used for regular in game decision making. This allows for the player to accidently hit the escape key without immediately shutting down the game, and keeping the game's experience consistant.

I've made the builds for Windows, Mac, and Linux. I've tested so far with the Windows version on two machines, and it works perfectly fine no matter what settings you choose. I even got the game working on a virtual machine running Manjaro Linux, which, while it took some tinkering, worked perfectly fine. Given the extremely low resources of this VM (2 Cores, 2GB ram, 128mb Vram), I feel as though this game could run on a massive majorities of machines. I've also tested the game with some sighted players, and using the new systems, they seem to be able to figure out the basic demo mission included in this test version. I've turned the camera off, so sighted players play on equal ground with visually impaired players, as was the design.

The only test I haven't run so far is with my blind friend on his mac, I feel his test data will be the most important.

To make the game more generic for running on all these different platforms, I've altered the controls in a way that I think makes the game play much better, mapping the main controls to the Q, W, E, and R keys, or in other words the top row of the keyboard. A lot of the development software I use like Maya and Unity itself use these keys as hotkeys, and given that any English keyboard, regardless of platform or region, should have these keys, it should maximise the games compatibility. And at least on QWERTY layout keyboards, QWER should be easy to find even without sight, since they are next to each other (hence the name of the layout).

Turning to the recording side of things, The lost post was made the day I recieved my nice new SM-57. But since that post is lost, I'll recap

I wanted to get an external mic that is tough as nails for attaching to my recorder so I can leave my recorder in a safe location and record outdoors overnight. And given the famous durability of the SM-57, I figured this would be a good choice

I have since recieved all the pieces I needed to test this, and the test run went very smoothly. The ultimate goal of this was of course to record adverse weather, like rain and thunderstorms. I have devised a very complicated rig for doing this, that will hopefully protect the mic from damage while also getting a good recording.

Tonight, it is supposed to be scattered thunderstorms. Looking at the radar, I think it is going to be a lot more scattered than even they think. Of course, since I've started this quest to record a thunderstorm, we have had drought conditions for over a month.  Never the less I need to try and record this rare opportunity while I have it, incase we do get hit by a stray boomer. Just the off chance is enough to make it worth it. My only issue is timing. Though my recorder with the massive SD card I have in it can handle up to 30-ish hours of recording, the battery with an external mic can only handle about 4.5 hours of recording before it quits. So I need to get the recorder set up and recording as late as I can, but still before the storms, which according to the ever changing forcast, go later...and later...and later.... lets hope I get something.

In terms of those creek sounds I've been trying to get, I've bought my brother a pair of creek boots in hope of getting him to record those sounds for me (I would have got myself some, but imagine that, cheap Walmart muck boots don't come in size 13). Our schedules just need to synch, then we can finally get that done.

Overall, I feel like the project is coming along quite well, I'm starting to actually see a path to completion.

8/25/16 Update

So as we reach the end of August, work continues on the Blind Game.

Over the last few weeks (as previously noted) I've been spending time optimising the code to streamline the process of developing the actual game once that starts. In the meantime, sound recording has remained mostly at a standstill. I decided on an SM57 microphone for my external recording mic, and spend most of the week waiting for that to arrive. Now I need to get my hands on a sufficient XLR cable and setup a waterproof system of recording for long term, overnight recordings. While waiting for that, the next goal is to set up for some more regular recordings, like for additional sounds for the game.  Part of this requires me to nail down more details of the story so I can know exactly what some of the puzzle objects will be. To that end, I've been discussing ideas with my friend Dylan, who has given me some good ideas so far. I just need to condense those ideas into a functioning story to give the game a sense of direction.

Speaking of stories, I've started on writing a treatment on what could become my next project. A treatment is basically the beginnings of a story. It's sorta like a synopsis, but more detailed, but less detailed than an actual script. All of the games I've made so far have been much more centered on gameplay than narrative. But the kind of games I really want to make are narratively driven games. I love both kinds, but I believe games represent the ultimate vehicle for storytelling, when used correctly. Ball on a Stick was my attempt to crank back the ambition knob a little in an attempt to make something more "realistic" in terms of scope given our limited resources. While that was helpful to let me see my limits, I also feel that I want to accomplish something that feels more substantial, and closer to the kind of games I truely enjoy the most. Ball on a Stick was my attempt at a genre I don't really like too much. I want my next project to be my attempt at one of my favorite genres.

On the subject of Ball on a Stick, while I am mostly putting that game aside so I can focus on finishing Blind game, I am still considering expanding on the platforms it is available on. I've looked into Amazon's store, as well as finding a way to get the game on the cost prohibitively expensive iOS platform. Someone also recommended a web browser version, which I haven't completely eliminated from the realm of possibility.

For now though, I'm gonna focus on the Blind game

August Update

So it's been about a week and a half since the official release of Ball on a Stick on the Google Play Store.   

Now we haven't exactly hit my target amount of downloads, but thats OK. I'm just glad some people downloaded it at all, and I can now say I am a published game designer.

Since then, I've been in the process of switching gears to get back into working on Blind Game. Ball on a Stick was supposed to be a winter project to just kill time while I couldn't record sounds, and I was gonna dedicate this entire summer to finishing all the recordings for Blind game. But given that Ball on a Stick went 2 months over schedule, the better part of the summer is now gone, so I'm gonna have to really rush recording now to get the small amount of sounds I'm missing. If I miss this opportunity now, I'll have to wait an entire year to get it again.

Here in the northeast, we have maybe 4 months out of the year where it's actually nice enough to go outside and record things, especially sounds in the water.

Beyond this, there are some ambient sounds I want to record that I can only get in the summer. But I need an external microphone for this, and I'm looking into options that will allow me to get the sounds I'm looking for.

On the code side of things, I've made some significant breakthroughs in terms of my proceedural generators. Now I can generate pretty much anything into the game I want to at will. This was a problem for my ambient sound generators and some colliders I use for telling the narrator about special features in an area. Those in particular were a real pain to position, and would have made generating multiple level layouts pretty much impossible.

Now I should be able to generate the entire game procedurally, and even run the entire game in a single scene, being able to generate any number of maps and levels all within a single scene.

I've also begun to optimize and streamline some of the older code to make altering the sounds associated with different materials much easier. Before, each sound was associated with the thing that made that sound. Now I'm trying to consolidate all of the sounds inside of the material class, so that they are all in one place, and can easily be swapped and altered in one place rather having to look all around to find the different sounds everywhere.

My goal is the make the level design phase of this project as streamlined as possible. The work I'm doing now will hopefully make the second half of this project go so much more smoothly.

All of this would have been impossible without Ball on a Stick.  When we started that project, I was having trouble with a lot of different parts of the code for this game, especially generating the other elements of the map. I think the experience I gained from doing Ball on a Stick leveled me up to the point that I'll be able to do some of the more complex work I'll need to do to finish this game as well as future projects. So while Ball on a Stick ate up a lot of my summer, it has also helped me make a few huge breakthroughs for this game.

But never the less, recording challenges continue. Hopefully I'll figure something out soon.

Ball on a Stick: Official 1.0 Release!

Official Launch Trailer:

https://www.youtube.com/watch?v=oQ9c_0eTWio

Download Link:

https://play.google.com/store/apps/details?id=com.KnightsHouse.boas

I'm proud to announce that Ball on a Stick is now available on the Google Play Store!

This has been the culmination of a lot of hard work. You wouldn't expect that from a game as simple as this one is, but there were a lot of unexpected hangups on this project. But we worked though them, and now the game is finally done.

I'm really proud of Danielle for making through this process. I feel like this project succeeded in building her confidence as a developer, and now we are ready to move on to bigger and better things. When we started this project, she had never worked with the Unity workflow before, and it was rather overwhelming for her. But now I feel like she knows her way around and has learned a ton the way I did when I finished Rat Boy. On future projects, I feel confident that I could tell her I needed something done in Unity, and she could do it.

I have also learned a ton from this project as well. I was expecting a project this simple to feel like an easy refresher course or something, but I ended up instead challenging myself which taught me a ton of things about programming and design. I felt confident enough in the simplicity of this project that I could experiment with some ideas I had, that ended up working out amazingly. These new techniques have made their way into The Blind game (which I haven't forgotten about) and will likely help me on other projects in the future. All the games I've ever made have done that for me, and Ball on a Stick is no exception.

I also have to shout out other people who helped make this possible. Of course Laurence once again lended a hand whenever I was in over my head, and we spent a very stressful E3 weekend trying to fix some Google Play Game Services issues that ended up getting cut from the game anyway. He knows I will always appreciate his support.

Our friends and family in general have really helped us with the testing of the game as well. They gave us a ton of great insights that helped shape the game.

We will be busy promoting the game all weekend, we hope you download it and enjoy it!