About a month ago I came across an open-source game on itch.io called Tanks of Freedom, a great take on grid-based tactics with three unit types that have great dynamics, and a solid resource system. I got really into it for a while until I kept running into the same problem - the game got grindy.
You see, in ToF you win by capturing your opponent's HQ. That's fine, but since most maps start you with an HQ near other buildings that construct units, and since most HQs are in areas that are easy to defend, once you reach the tipping point in the map and overtake nearly everything, to the point that it would be near-impossible for your opponent to make a comeback, it can still be a long time before you can actually win. Turns end up being "construct new units, send them toward the front along the single most efficient path, and attack the defending units and advance as much as possible, which is one or two spaces if you're luck." It's a grind, and everyone involved knows the game's already over.
But I really liked everything else about it - and this is not an insurmountable design flaw. I've played a lot of tabletop games, and one of the elements I've enjoyed in them are the shared objectives that are designed to require all players to compete directly for something neither can entirely control. I took this idea and tried it out in Tanks of Freedom.
Here is my initial OS X build from this branch of my fork of the game (feel free to build it yourself on other platforms) that adds a new structure, the "objective." Objectives start unclaimed, cannot construct units, and consume the unit that captures them. When objectives are present in the map, a score panel is displayed tracking game progress - at the end of your opponent's turn, you earn 1 point for each objective you control. I also included a built-in map called "objectives" to demo the concept.
If you want to try it, try the map in Skirmish mode. Presently there isn't any support for objectives in the AI, and I didn't write any code for online multiplayer, but for a 1v1 local game it works great! If you try it out, let me know what you think - I'm still doing the final tweaking before submitting it upstream.
As a developer, I am constantly facing problems of all kinds. Learn a new framework or language. Decipher business logic from uncommented code. Encipher business logic into totally-readable doesn't-need-a-comment code. And I overcome them every day.
But the problem I have yet to find a solution to is the Problem of Problems.
Behind me is a long line of partially-finished projects, and those are just the most recent ones I can link to. From speaking to other developers, this isn't an uncommon thing, and, as I am designed to do, I have been pondering the common thread between them in hopes of possibly diagnosing the issue and submitting a ticket.
And the common thread that, when pulled, unravelled the tapestry, is that while I am well versed in solving problems, identifying problems and presenting them to be solved is an art form I am much less skilled in.
My most recent shelved-project, a first-person RPG thing in es6, came into being when a few specific inspirations came together. At work, another team started using Babel/es6/7-stuff on an open-source project that piqued my interest in using those languages myself. I had tinkered with WebGL a few times before, and I was really hankering for some game development, as I'd let it slip through the cracks for far too long. And, I had just finished playing an Android game that I found surprisingly enjoyable, and I wanted to explore the design space of that genre myself. It all came together into a working, nearly-finished project.. and then it didn't.
When'd I stop? Right after all of the identifiable features for a game were implemented, but before a game was done. Right after all of the emergent problems were solved, but before it was finished.
My problem was that I ran out of problems.
The next step in the game would surely be to decide on some mechanics, make up a story, get the graphics together, and bang the thing out. It would take months, sure, at the schedule I have to work on it, but it would happen. But.. gosh, that's such a big, blank canvas to work on..and I want to work, but..on what?
I've seen people approach this problem in multiple ways. For some, the answer is to work on reimplemented things that already exist so that the set of requirements are laid out for you from the get-go, and this issue never has a chance to arise. For others, it's taking on contract work to feed the developer without staring down existential walls - although those can fall into the same trap when the client doesn't have solid requirements.
I think, though, that like most of life, it's more about other people than it is yourself. Approaching a vast emptiness of possibility alone is intimidating, horrifying really, but with someone else, maybe even a team, on your side, it is very approachable. A friend of mine has been working on an interesting game for at least a year now, and regularly keeps me and others up to date on it, I'm sure as a way to keep himself motivated. I think involving others is the right path toward success, and while it gives up some of the freedom of going in alone, I think in the end it will result in more completed projects and less half-finished heaps of code on the shelf collecting dust.
It's not a solid answer, but it's a direction to search. So if you're interested, you know how to reach me.
This week we're going a little outside the comfort zone and trying a completely new genre for which I don't believe I am the target audience at all. But don't worry, I've enlisted the help of my very own captive audience - my lovely Sara - in giving me her opinion of the game on her own playthrough. I was also very impressed at the mechanics I found in a genre I'd largely discounted without first giving it a look.
The Average Everyday Adventures of Samantha Browne is an interactive story in which you make decisions for a college student who suffers from social anxiety. Sam, the namesake, quests to make some oatmeal, and the only obstacle between her and a disappointing dinner is her own fear of others. It's free, and as usual, I recommend you try it before reading the rest of this if you want to remain spoiler-free.
Being an interactive story, you don't get much interaction - click to advance text boxes, occasionally make a choice that's presented on the screen. From seeing four playthroughs, there wasn't much variance in the different choices, and the story was pretty linear no matter what you did. There were failure states, and too many incorrect choices would make you start over from an earlier part of the story.
That's, honestly, all I thought these games were. I was surprised, and impressed, to see that there was much more on offer here.
Sam's social anxiety is expressed a number of ways in the game, from isolating her from the player by never showing her face to the constant uncertainty in her thoughts, but the most effective were the subtle mechanics.
Waiting. Spending time is a powerful thing, and TAEAoSB effectively spends it with a simple, but brilliant, waiting mechanic. At a couple points in the story you must simply wait - for water to boil, for a microwave, for oatmeal to..cook (this takes place in England, do they call "oatmeal" what I call "oatmeal?"). While waiting a countdown is shown on the screen, and you don't have to do anything...but I always clicked again, prompting Sam to pipe up with some worry. Waiting, alone, quietly, makes us nervous, and this captures it wonderfully, sticking us uncomfortably in our own head so we can be closer to Sam's.
While walking down a short hallway, TAEAoSB plays on the core of the genre by bombarding us with a long slew of dialog boxes, advancing the background one single tiny step each time they are advanced. This has the effect of making the hallway seem very, very long, while if you pay attention only a short distance is travelled. Sam dreads walking down the hall for fear of encountering another student, and by using the core mechanic of the genre, a fairly uninteresting advancement of dialog boxes, the impossible amount of time between A and B is conveyed to the player. It's quite clever.
However, the most effective mechanic is failure. On your first playthrough you'll almost certainly fail. This is your last chance to not have this spoiled. When first presented with the ability to leave your dorm..er..flat, you are given two choices - "Go Outside" or "Wait Here Longer." If you just go you advance the story, but you also forget your keys and lock yourself out of your room, something you won't notice until you reach nearly the end of the story. At first, this frustrated me, but on my next playthrough I found myself forced to make ever singe fearful choice just in case something awful would happen again - it worked. By failing me the first time for going into it as myself instead of as anxiety-riddled Sam, the game forced me to really get into character in the next run. It's a brave move to force the player to replay most of your (admittedly short) game, but it was a good call.
The takeaway this time is as the old adage says - don't knock it before you try it. I had been dismissing interactive stories since I first saw them, but having tried one I have more respect. There was a lot here, and while this may be an example of a good one, I feel like this genre has a lot of potential to give an impactful experience. I don't know that it's my thing, but I'm sure we'll cross paths again.
The most important lesson here is using the core mechanics of a genre to convey you message. Advancing dialog boxes seems like the least interactive thing in a game, but here they were used to create a tension that perfectly suited the atmosphere of the game, and indeed enriched the experience. This is what good design looks like, and I hope to find such thematic uses for core mechanics in my own works.
Sam's waiting mechanic also demonstrates respectful use of player time. Waiting in a game sucks, and it's very easy to do wrong, but none of Sam's waiting sections are frustrating. They are long enough to serve their purpose without being so long as to waste your time. I'm sure it took a lot of trail and error to reach the sweet spot, but every time I see it I'm reminded of how important it is to get right.
This time around I'm going to break form and do a freestyle rant on a game, but it comes with a huge disclaimer right up at the top:
Really, though, Moirai is an excellent, interesting, very short, very free game by a few awesome dudes, and reading anything more about it will really spoil the fun of it, so just go play it right now if you haven't and come back. Really, it took me like 10 minutes, it's worth your time. If you're at work or something just stop reading this then and play it when you get home. I don't even care if you come back, it's really cool, give it a try, please.
I'm writing the rest of this assuming you've played it, so you won't even get anything out of ruining it for yourself.
Moirai is a simplistic first-person adventure game (for lack of a better genre) where you follow a very linear story through a very pixly world with very limited interactions with anything. The story is about the disappearance of a woman from your village, but that's not what the game is about. This game is about choice.
Now, a lot of games are about choice, and it's so cliche that I feel bad saying it. It's not about "choice" like in Mass Effect or choice like in Undertale, it's about one specific choice. When you come upon a blood-covered farmer, you're given the choice to attack him or to walk past him. It looks bad, the situation looks awful really. He may've killed that woman. He may have killed the last farmer. There's no way to know. And the revelation as you leave the chamber with the woman, which ends in you bloodied either way, that the last farmer was a player like you, is great.
Or, well, it would have been.
On my first playthrough I got a farmer who was literally the internet, in the worst way. He even included a URL to visit.. I did not. Oh well. I'm afraid at that point I suspected what was going on here. But let's imagine a world where the other guy was not memes and vulgarity.
Moirai is about a choice, and it's a very human choice, and it's a humbling choice, and like all choices in life, it's presented to you before you understand the context of it, and before you can grasp the ramifications of either option. In retrospect you will realize that you couldn't have had all the information, that you likely never will have all the information, to know if the choice you made was the correct one, the "just" one. It's a reflection on the very nature of justice and morality and what it means to be human. It puts you in the position of deciding the fate of another (as an aside, Moirai are the fates) and then immediately shows you how little you knew in making that decision, and then turns around again to put you in that person's place, explaining yourself to the next unknowing sod. And that's it.
We'll email you with your fate, though.
I found this one really compelling. This is the kind of thought-provoking commentary on the nature of the world that I love, and a great example of the power of interactive media to do more than tell a story. Thank you Chris Johnson, Brad Barrett, and John Oestmann, for enriching my life. This is the kind of game I aspire to one day produce.
This week, we're going way more experimental, and it brings to mind an interesting concept - video game literacy. While playing this week's game I couldn't help but think that if I was not an experienced gamer, I would have been much more lost in what to do and where to go. In a game with barely any text or direction, how did I so easily make it from one place to the next? The answer I'll be discussing most is level design, but it's worth pointing out up front that this game expected a very literate audience, often relying on common conventions and assumptions to get the player moving in the right direction. As I go on working on my own projects, I will keep in mind how literate I expect my audience to be, and what that means I need in terms of direction for them.
Box Life by tequibo (also on steam) is a tiny first person puzzle platformer that claims to be a Metroidvania. The claim isn't unfounded, as you start with only the most basic abilities and then slowly find more, backtracking to access the new areas they open up. The entire game takes place in a single, medium-sized level.
Level design. This game is a wonderful example of a well laid out level, as with no instruction besides the controls, it gets you through the entire half-dozen powerups without any hiccups. When you start the game you appear at the top of a sort of tower, with only one way down (and no way back up). The area you end up in is relatively small, and after poking around you find only a single way to go, as well as some interesting pillars (that become important later). While there is only one path to follow, you happen upon it, and the area surrounding looks to be maybe-transversable until you try it, which I didn't the first time around, giving the impression that I had chosen a path instead of being funneled down it. That illusion of choice comes back many times throughout the ~45 minutes the game lasts, and it is the difference between a linear experience and a feeling of overcoming nebulous obstacles.
Once on the only path, you are presented with an obstacle you can't pass and a drop. Dropping down gets you stuck (you can't jump yet), and presents you another obstacle and the first powerup - jumping. This is the game telling you to return here once you've found more powerups, and it's very effective. With your new jump power you can explore another route up above, and quickly come upon the first key. With nowhere else to go, you return to the initial area and pass the pillars, where the key rests when you approach. Without any direction given, the player finds that there are obstacles they cannot pass, that there are powerups that let them pass obstacles, a location to return to after finding another powerup, and the objective of the game as well as how to complete it. It is brilliant in its subtlety. This theme continues throughout.
The variety of the half-dozen or so powerups you find also helps make the game interesting - everything from a shot that breaks certain walls to flight to the ability to shrink and fit in tiny passages. These especially serve to enable exploration, and it is satisfying to find something and consider what you can get past with it now.
In addition to the main objective or finding four keys, the game has "secrets," and when you find the first it is eager to tell you that it was one of nine. While that's fine, it doesn't really "work" - I looked for a few, but they are hidden so obscurely that hunting for them turned into rubbing every powerup onto every surface until a new passage opened up, and it was disappointing for a game with such solid level design to miss this extra opportunity to shine. There was also one section that required you to clear out dozens and dozens of blocks to continue down a corridor, and it just ended up feeling like work.
By far the biggest takeaway from this game is its focus, as Box Life wanted to be exactly one thing, and boy is it. The minimalistic, abstract graphics, lack of compelling sound, and general simplicity of the game are all overshadowed by the core focus of getting you from A to B without telling you how to get there. The mechanics it explores all contribute to this focus, giving you subtle, or not-so-subtle, ways of reaching things that you previously saw but just couldn't get. In my current project, I have implemented some combat mechanics that may end up being against the grain of what my game wants to do, and this game has strengthened the idea in my mind that any amount of work implementing a mechanic is an acceptable loss if it detracts from the focus of my project. Throwing away work like this takes courage, and it stings, but it's worth the loss to make the best product possible.
Welcome to a new column on dorthu.com - Avant-Garde Indie. Here we'll be exploring experimental indie games, and discussing what worked and what didn't, as well as what in the game has inspired me and will influence my own projects. This isn't a reviews column, and I'm not going to be recommending anything, but I will include links to the relevant sites if you want to try the games for yourself. I'm kicking this column off with a pixel-based short-story point and click by Peter Moorhead - Murder.
Murder is ostensibly a point and click adventure game, but in practice there are very few interactions - each screen of the game has one "Critical" interaction that advances the player, and maybe a few "Optional" interactions that trigger some extra dialog. In many cases, there are no optional interactions on a screen, and you just look around before selecting the only option to continue.
The first thing that drew my attention to this game was its art style - I'm a sucker for pixel art, and this is quality stuff. The use of color is especially striking, and the environments are fairly memorable, despite only visiting each briefly. It's also worth mentioning the soundtrack, which is spot on.
The real sell of the game is the story, though, and it does not disappoint. The story follows a Lieutenant in a cyberpunk future through the investigation of a single murder, and ultimately comments on the nature of conciousness and death. While left broadly open to interpretation, I felt the message of the game was that sticking to a routine, staying inside your small, sheltered safe zone, and never pushing yourself to do more than the rote bare minimum is essentially death. A powerful line went something like "I will not let conciousness be commoditized" - and I think the author wanted me to consider what that means for a nine-to-fiver today.
All of the dialog in Murder is voice acted, but I felt it detracted from the experience. The lines seem to have been recorded across many sessions, or out of order, or otherwise stitch together unnaturally - when played in sequence, they don't make for a conversation. Even worse, the lines for the few optional interactions can flow together very poorly when done in the wrong order.
The other major problem is the linearity of the experience - this game tells one story, and while it's a good story, it may s'well've been a movie. The most agency the player has across its thirty-minute runtime is the order of a few batches of optional dialog segments, none of whose order has any effect on the outcome. One sequence in the beginning really highlighted how little agency I had - I called an elevator, then the game apparently froze. A second later, I realized I was just waiting for the elevator through a scripted sequence where I couldn't even move the cursor. The shame of it is that I think this was avoidable - if I had simply been given the ability to walk my character around the room, even with no consequence to it, I would have felt more invested.
In fact, playing the game with a controller, all I could do was move the cursor between selectable points. If instead I could move my character around the room and interact with nearby points, it would have added an element of exploration and discovery that would have given me the agency I wanted - sure, highlight that I'm supposed to go through the door, but let me find out that I can interact with the newspapers and computer on my own. This would preserve the very linear story (which was not a problem), while making optional interactions feel like more of a reward for exploration, and make the entire game feel less like a short film that I have to press A to advance at points.
There was one moment that I don't want to spoil that really inspired me - toward the end of the story there is a sudden twist that took me by surprise in both its execution and impact on the message. If I take one thing away from this game, it would be the construction of that moment.
If there had to be a second thing though, I think I wouldn't attempt voice acting, especially in a situation where the sequence was variable. While I think I see what went wrong with it here, I don't honestly think I could do better, and I feel like the disjointed voiceovers took away from the experience more than I could gain by including them.
Breakfast. Commute. Work. Commute. Dinner. Family. Were all busy. I remember the days of endless nights, like pastures of green before me, free time roaming the virgin countryside. Now, for all the countless ways my life is better, this freedom escapes me.
Allow me to introduce es6-crpg. This cleverly-named hodgepodge of EMCAScript 6 and gluten is my latest project, and an effort composed in its entirety of Opportunistic Development. Take a look at its punch card. Don't bother clicking the link, actually, here's what it looks like at time of writing:
By looking at that, I bet you can guess what time my son goes to bed. On the weekends, we make family trips to Starbucks - Pat loves playing Mario Kart or another 3DS game, and I get a few good commits in then as well.
The rest? Two heroic pre-8 am contributions I don't remember (and probably didn't later that day) and naught. That's what I'm calling Opportunistic Development.
What motivates you to keep with a project? The world is an ever-expanding maze of options and adventures, the road outside your door leads to a hundred hundred experiences you've never had, and for each that you pass up a door shuts, the space behind it unknown to you and unwelcoming. What keeps you motivated to keep with a project?
Besides a paycheck.
It's accomplishment. It's looking at something you made and saying "yeah, that's good." It's showing a friend, a colleague or spouse or child or parent or some other living, breathing person to validate that your effort has not been thrown into a void because it has touched another life in even the slightest way. It's finally getting that damn sprite positioned where it had aught to be. It's accomplishment. Or else I'm projecting.
To stay motivated, sit down to work on a small, attainable, but tangible portion of what there is to do. "Tonight, I'll make an AI that can take a turn." I did. "Before we leave Starbucks, I will have usable inventory items." Done. Page through those commits - small, maybe even tiny steps toward something bigger, and each step onto solid ground, each step showing progress.
To the end of the strategy, it is almost necessary that we do not plan. This project started as a "huh, I bet I could," and has continued as such for so long as it has continued. There has been no long-term plan, in overall design or in code structure. Does it show?
The advantage to having no plan is to keep the canvas clean, blank, and accepting of the brush. The more space you fill, the more restricted you are in spaces to work, until work is a chore. And don't be afraid to paint over old strokes, either - rewriting old code to accommodate new ideas is easy if the code isn't too rigid.
As an example: In general, it's bad practice to use a "kitchen sink" design - through a hash around with all of your values paired to keys that made sense when you wrote them - but in this case I find it liberating. An inventory item? That's a hash with a name and a texture for an icon, maybe where you can equip it. I later rewrote it into a proper object with some logic, but not until I needed to, not until that crumb was the one I was chewing.
My final thought is schedule. Keep a schedule. It doesn't have to be intensive, but block out even the most marginal interval that you would regularly do nothing. A commute on a train. The time before work when you're awake but it's too early to leave because it would be awkward to get there that much earlier than everyone else. That half hour you sit in your son's room while he gets to sleep. Keep to it.
Skip sometimes. Tonight I am beat, I wrote a lot of code and did a lot of things today and I am done with it. Tonight, I did this instead. Skip, sometimes. When you need to.
But then keep the schedule.
There is time for the things you think of when you think you have time to do them. We're all busy. Develop opportunistically.