Design Tips Needed for Partial - An Audio/Video Game Hybrid

Hmm, yeah that's kind of what I thought I'd have to do. Was getting set on omitting currency altogether so that pretty much confirms it. Had it on my mind in case there was some more preemptive planning that could be added to the game, but there's other ways to add strategy so it's all good.

Aside from the menu and tutorial, having a voice count how much of something you have will probably be out of place for the game's atmosphere. But I'll definitely keep the pitch changes and specific sound effects in mind. Thanks!

It'll have 3D-orientation sounds so having a headset helps provide better feedback, but the graphics are actually 2D which makes information easier to convey! And the narrative reflects the design mechanics, such as being able to hear your surroundings in a way that's vivid. Each ground segment is shaped like an octagonal pillar, and each of those pillars has a different attribute. Since the pillars move up and down a lot, they can act as either the ground or the wall, which should help with spatial awareness.

There's no announced release date yet, since it's still in the prototyping stage. Originally, there weren't going to be any beta testers unless they were in-house. HOWEVER, @itchio just announced their Refinery program.

If you're unfamiliar with the Steam client's Early Access program, it allows fans to help test out the game publicly, but it has some community and marketing issues that backfire on the developer; over the few years it's been available, Early Access often hurt more than it helped, for both players and developers. Seeing that this was the best solution for indie devs like myself, I opted out. But Itch.io Refinery remedies most of those issues, and the itch.io team is pretty great to work with in general. In addition to getting some design feedback, the Refinery program is the reason why I wanted to talk about Partial a little earlier than I had originally intended. We'll announce a date at some point, but you can find more information about the program at this link.

http://blog.itch.io/post/144305999624/itchio-week-day-5-part-1-itchio-refinery

Partial won't be available for some time, but the plan is to release it for iOS, Android, and the Windows PC, Mac, and Linux operating systems. The game will need to be bought, so it will be IAP-free. Still working out the price.

Ahh okay, haven't really thought of many gestures besides taps and swipes, but I'll keep it in mind. Just worried that memorizing the gestures will become a usability issue, but we'll give it a try at some point in testing when the game is further along.

There's eight playable characters known as Partials, each with their unique quirks, but the idea was to let the player figure out their stats through trying them out and figuring out those strengths and weaknesses yourself for some added surprise and tension. But if that ends up backfiring, we'll probably have to add a way to explain those stats explicitly. MORE TESTING!

Thanks Brad! I know what you mean, but more complex doesn't always mean better! A lot of mobile apps suffer from over-simplicity though, which ends up creating the ten-minute effect you're talking about. Partial, on the other hand, is inspired by the rogue-lite genre.

A rogue-lite is a genre that's more accessible than the rogue-like genre that it originated from, but shares a lot of qualities. The most common rogue-lite mechanics include permanent death and procedural generation. This means that every time you die in the game, you start from the beginning. As for procedural generation, it means that every time you play the game again, the level varies each time. Because of these two mechanics working in tandem, there's an emphasis on skill rather than memorization, because each new playthrough provides a different challenge. Rogue-lites in their purest form are simple in terms of design, focusing around one core mechanic and only adding designs that strengthen the core. And its because of their clean design that they've been incredibly popular in the indie gaming scene for the past three or four years, sprouting from The Binding of Isaac and Rogue Legacy, to the most recent Downwell and Enter the Gungeon. Often times, each playthrough (also known as a "run") takes about 45 minutes from beginning to end. But due to the emphasis on skill, your first few runs will probably have you fail within the first five minutes, but you'll be reaching new milestones with each new run. Rogue-lites are easy to learn, but difficult to master.

However, most rogue-lites, if not all of them, use currency. You collect coins by defeating enemies, then spend it at the shop by choosing items that optimize your chances of success depending on what obstacles you expect to come across, and you continue on. This aspect makes currency incredibly important in games since its a simple yet diverse way to add strategy to your game. Before I posted here and asked for help, I had no idea how to implement currency to be blind-accessible, so we circumvented it by inventing the friendship mechanic. Unlike many games where you gain strength by upgrading your gear, the creatures that you save in this game are your strength; the more allies you have, the stronger you are. In this sense, the creatures you save sit in a vague area between currency and equipment. There's still some kinks that we need to figure out, but with the advice you've all given on how to implement currency, we'll give it a second round and see where it can benefit the game's design.

One more thing to mention. Designing it as a rogue-lite did end up creating issues for us, though. Rogue-lites, by their nature, are hard. Really hard. To reflect this, many games design their atmosphere to reflect the bleak outcomes that the player experience, most often of which are the underground dungeon setting, and loot is as common as the enemies you face. In a rogue-lite, everything is trying to kill you. Partial's atmosphere, on the other hand, is in the complete opposite direction for a number of reasons. Unlike traditional genres where each genre has their community, blind players are incredibly diverse in opinions and taste. We had a hard time pinpointing what you'll enjoy because it's all over the map, so we focused on the design first and the narrative direction second. Because of that, we aimed for a game that's welcoming and forgiving, but still contains the core elements of a rogue-lite: an emphasis on skill rather than memorization. Like the game Downwell, we're planning on making the average run last about 5 minutes at first, but the game definitely has some depth the more time you put into it.

Thanks for your comment brad!

Ahh yeah, I read about FREEQ and really liked the concept. Not sure if we'll use it since its not the kind of game where you drag a point around trying to find the sweet spot, but we might be able to do something with it!

Thanks Jeff! It won't be coming out for a good while, so I wouldn't get your hopes up from the chance you'll get your hands on it soon haha. We're thinking about an Early Access kind of thing using itch.io Refinery though, so you can stay on the lookout for that.

As for why game devs don't make games more accessible, I don't think its out of laziness or greed most of the time. It depends on the direction of the game and the team's budget. Take this with a grain of salt since I've never worked on a big title, but in AAA (big-budget) development, there's a lot of pressure from publishers who are the ones paying the dev team and help market the game. It's the publisher's job to make money, its the developer's job to make the game, and simply put, there's no money in accessibility. In that sense, you can say its a mix of greed and laziness. But most game devs working for AAA don't have complete control over their project due to their publishers; its not uncommon for a dev to want a design and the publishers say no in place of their own design, because the publisher's design is quote-unquote "data-proven" to generate more sales. (See example: all games should have multi-player and DLC, or downloadable content.) There's often hundreds of devs working on a AAA title, and with a lot of small parts working together, there's the need for a lot of overhead control. Developers and publishers are two separate entities, and in many cases, the publishers are the developer's boss.

Indie (small-budget) games work a bit differently. Most indie devs make games because they love games, whether they enjoy playing them or enjoy making them. To many indie devs, its like doodling drawings because they enjoy doodling, and no more. Money is incredibly useful, but its the not priority, and often times they are self-funded. In addition, many indie teams consist of no more than 20 people, with most teams hovering around the 4-person mark. Communication is much more direct, especially since the community for their games is much smaller, which means they can actually talk to every person who posts on their forums. It's not as overwhelming since the community isn't nearly as large as a AAA title, but indies have to wear a lot of hats and multi-task a lot. If indies aren't thinking about accessibility, it's usually because they literally forgot about it. Figuratively speaking, its difficult to put yourself in another person's shoes when you have to run a long distance in your own shoes. But indie devs also tend to have a small budget to work with, and its not uncommon for them to spend a month or two eating just noodles on a tight budget. And often times, when the game is released and there's a community asking for better accessibility, the developer decides not to for either of these reasons: they didn't make enough money from its initial release to expand on the game since the game isn't that great to begin with (which is basically polishing a turd, which still makes it a turd), or because they were definitely lazy and just wanted that project over with so they can move on to the next thing. By doing the latter, they have no idea they just missed nearly guaranteed sales and that's their fault.

On the bright side, indie games tend to be less complex than AAA games, so if there's the chance to make the game more accessible to a certain audience, its more likely that they'll do so, such as epilepsy or colorblindness. In indie development, anything counts. But audio games are another beast altogether. Many of the design techniques learned just don't work well in an audio-only format, resulting in spending a lot of time designing solely for a visually-impaired audience. It's like saying that a developer needs to turn a fast-paced action game into a slow turn-based strategy game; the original game just wasn't designed for that. An audio game is its own genre with its own criteria, and its a niche market. So unless you can merge the audio game with another popular genre successfully, its unlikely that your average developer will be thinking about blind players. It's unfortunate.

I'm no exception to selfishness here. Partial wasn't originally designed to be a game for the visually-impaired. At the very beginning, the concept of Partial was for it to be a music-based role-playing game. While thinking about the design, I told myself one day, "hey man, if the game is focused around music, you should be able to play with your eyes closed," and the rest is history. I found out about the blind gaming community, was sad about it (I have a good idea of what it means to be marginalized), and decided that I would make a game that allowed the blind community to sit alongside the main gaming community as opposed to behind them. The game had to be great in its own right, not because its catered to a marginalized audience, so I focused on making Partial a great game first and foremost. This sounds great and all, but before the eye-closing thought, I had no idea this community existed. I was just making a game that I wanted to make. Blind-friendly gaming just wasn't on my mind. Most game developers have that mindset, because its not in front of them 24/7.

I hope this helps give a bit more insight into what's going on; thanks again Jeff.

Thanks Igna! We're thinking about early access testing using the itch.io Refinery program, but it'll be a while before then. Just keep an eye out for when that happens!

Hey TJT, thanks for your response. It's not that I don't want to integrate VoiceOver from it being too complicated. In my opinion, when it comes to game design, everything should be available in a clean package. If I'm working on an audio game, VoiceOver support shouldn't be necessary. The game should be good enough so as to not use any outside support, and all of the needed audio should be implemented as we see fit for the game.

For example, if there's words that need to be read in the game, the game should supply that voice, not an outside app. Imagine if a Nerf Gun set had two nerf guns and no darts to shoot, and you needed your own darts to use the nerf guns. It shouldn't have to be like that, you know what I mean?

Please let me know if you have any concerns.

Hey Jeff. Yeah its a shame that some people are like that. It doesn't take much to be honest.

As a matter of fact, there's been an issue in the industry lately and the developers have been getting their comeuppance for a little while now: many developers, especially the big-budget devs, have pretty much bred their community to expect certain things that end up damaging the success of other developers, thus damaging the player's experience. It's a strange loop. And I say big-budget mainly because their community as a much larger reach, and they tend to exploit their audience in ways that would only hurt smaller devs. Simply put, players have gotten spoiled and expect that game development is as easy as a press of a button. I don't know much about it since I've only been in the industry for a little over a year now, but I'm sure I'll experience that firsthand at some point.

While practicing programming over these past few months, I sort of came up with this corny mantra during my work: "As a game developer, we start making games because we love games. We finish making our game because we love the community." It's not something I've fully experienced yet, but I've seen it enough times to see that that's how many successful projects go, and should go.

Thanks Ming! It probably won't release until sometime next year, at latest the year after that. It's taken a year to just get development started, so who knows. We plan on finding testers later down the line, using itch.io's Refinery program, and I'm pretty excited to try it out. In the meantime, we'll post any updates either on the AppleVis forum, on my blog, or on Twitter. So much to do, so little time. :)

Hey TJT, thanks for the insight. We'll definitely look into customizing the voice of the game. I didn't really think much about it, mainly because there isn't much text in the game to begin with, as text only exists in the main menu; there also isn't much character customization, outside of choosing a character and the strategic options available to you. During the gameplay, at least 95% of the content is provided through either audio or imagery, so that there isn't a language barrier. In addition, the game is designed to not have a high barrier to entry in terms of familiarity with games. In other words, you shouldn't have to be a gamer to know what's going on in the game. The wider the global audience, the better.

We definitely intend on having an early-access testing phase in the future, so no worries there. I'm not sure if we'll be able to fulfill all of these needs, but we'll do the best we can. Thanks again TJT.

Hey TJT, to address your considerations:

(1) As the design sits right now, currency is omitted to negate speech concerns. I wasn't sure how it was implemented and it was one of the biggest questions I had, which is why I asked. The reason for many of our design decisions for audio is to allow the game to be more immersive than anything you've heard in an audio game, as is often the goal in many great game titles. In a game about small creatures and animals, having the game talk in English is incredibly out of place.

(2) The wide variety of sounds are reinforced by their setting. If the level being played is a forest, most aspects of the game reflect sounds you would hear in the woods. Same with the ocean, or in a cave, and so on. Our sound engineer will be designing the audio in a way so that even when certain sounds are different, objects with similar properties will project similar sound effects.

(3) Every object in the game that can be interacted with is reinforced by audio, and there are objects that are further reinforced by other sounds to verify what the player does. Partial is designed so that every single thing in the game can be conveyed through audio without complicating the gameplay.

I hope I don't come off as standoffish or anything like that. Please don't worry too much, and if there's any huge roadblocks, user testing will be a huge help. Once user testing starts, the QA (quality assurance) testing pool will be small, but as the game is further along, we'll increase the QA amount to bring in some fresh eyes. Skepticism is great, and your feedback is much appreciated.

Heya Piotr, I appreciate your input. I've never worked with VoiceOver before, and I'm not sure if I can implement it in the engine I'm using. Unlike Unity, which codes in C, C sharp, and C++, it uses GML. Once user testing is further along, we can figure out how VoiceOver will work with everything, if it does end up being absolutely necessary.

And yeah, when the early designs for Partial had currency, I had the same thought when it comes to 50 coin jingles, and if there was a way to have a shortcut for that (like having 5 coin jingles that equate to 10 cents each). The button hotkeys and heartbeats are a clever idea I didn't think about, surprisingly enough.

Thanks Shelby. As the design sits right now, there's 3 levels per environment and at least 8 environments (I say 8, but we have way more than that; we probably scoped too big but we'll figure that out later since they aren't mandatory for the final product). I can't really talk too much about the game's design anymore since I've already said too much on this forum post, but we plan on providing ample challenges for it. Hopefully that eases your concerns. :)

Yeah programming is pretty rough. Spent 20 years of my life avoiding it, but I found myself embracing it more than ever. Once you get the hang of it, code is probably the closest thing we have to magic haha. And I'm pretty sure that I won't have the time to reply to everyone's posts in the future, so I'll do what I can now while its still a small community.

If you mean that you keep playing until you run out of health, then yes you do that. But its not like Minecraft where you find resources and build a home to survive against enemies. A mode like that USED to exist in the project's earlier iterations, but we threw out the idea because it wasn't working as well as we wanted it to. That's not to say its impossible, of course. A survival mode just doesn't align with our project goal is all.

Yep! The character you play as definitely has health. :]