Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

AnthonyMoh

6
Posts
A member registered Jun 29, 2019

Recent community posts

Quite fun, and funny too! There wasn't much to do after finishing the laundry though.

The UI is a little disruptive - with menu elements taking up space on the screen and blocking things.

But it's a pretty fresh, interactive take, on the "draw as few lines as possible to go through these points" puzzle.

Played in the browser - didn't see any perspective changing. Was fairly confusing, as after I jump I seem to have free vertical control over my character for a while.

Also, control scheme says "J" to jump, when it's spacebar. And had no idea how to get over the "spikes".

Walked out of town, and unfortunately ran into an error on the first random encounter: "Failed to load: img/sv_actors/Bandit.png"

Mechanics evolution

The initial mechanics of the game were intended as follows:

- Player 1 (henceforth known as the "Typer") would have to type letters, which had to match the letters on an enemy object that:

- Player 2 (henceforth known as the "Targeter") had targeted using the mouse. All the while:

- Player 3 (henceforth known as the "Mover") would have to ensure there was a clear path between the player and the enemy, while avoiding bullets.

If you look at the final version of this game, many things have changed. The first thing to change was how letters behaved. They were originally supposed to be extremely fast, and firing in a straight line. But when the first prototype came out, letters moved slowly, but followed the mouse, kind of like being beamed down from a spaceship. Not at all how I had envisioned it when writing the design document... but somehow a much better interpretation.

The initial movement mechanic allows players to freely use the arrow keys to move for a short period of time (in any direction), then switch to the numpad for a short period of time, and on and on. This didn't feel as frantic. We wanted players to have to change direction often, and yet keep track of which input mode (numpad or arrow keys) they were using to go in a single direction. Once that was done, it was a matter of iterating to ensure that movement felt smooth and forgiving enough such that players felt like they could move smoothly when they did everything right - and the challenge was to do everything right (rather than just being angry at unfair mechanics).

The targeting reticle underwent the most drastic change. Letters used to just be beamed from the player to wherever the mouse was pointing. Then we changed it so that letters would follow the targeting reticle (allowing you to lead them around obstacles), and this was pretty fun. But it made it a bit too easy, so we added momentum and drag to the targeting reticle - to move great distances, you had to accelerate it. And to stop on a dime, you had to de-accelerate it by moving in the opposite direction.

The targeting reticle mechanic has been rather controversial. Some players love it because operating the cursor in a precise manner requires a high degree of skill, and a small amount of forethought. Others say that mouse movement is expected to be snappy, and the sluggishness doesn't feel good.


On challenging vs frustrating

Much of the challenge in this game comes from controls not working like how they normally do in other games. The mouse moves like a spaceship, not like a pointer on the screen. Moving the player requires more coordination than normal, and changing direction is sometimes the only way to stop moving. We were very worried about making sure that players felt the controls were fair.

Playtests revealed that most teams got significantly better at this game over time - but their first few games were incredibly frustrating as they had to learn the controls. Originally, the game started out difficult, and then scaled up to become pretty much impossible. Having been familiar with our own game, we failed to account for the fact that players who were brand new to the game wouldn't be able to do much without getting used to the controls - and since the game was punishing from the start, they didn't have much time to get used. So we drastically tweaked the difficulty of the game down early on to give players time to ramp up - but the difficulty still ramps up quickly enough to get challenging very quickly.

One problem from testing our own game was that we only really tested one aspect of the game at one time. Individually, we felt like each player's job was equally difficult.

Unfortunately, it turns out that despite the game trying to promote kindness and forgiveness between players, the game itself is extremely unforgiving to uncoordinated teams. This is kind of by design - a single player under-performing makes the game almost impossible. But it can be problematic not everyone has easy access to two other friends who are willing to embrace failure and learn together. In some ways, this does necessitate that players be forgiving to each other in order to get better.


On UI

As much as possible, we tried to convey information visually. Letters change color when they're slower. The targeting reticle does as well. As you take damage, the light you emit gets dimmer. This started out as a way to debug what was going on, while deciding on the best way to convey this information to the player. As with most things, we ended up being too lazy to come up with a separate mechanic, and just use what we already had.

I think that, as much as possible, conveying information to the player is best done by just changing the existing elements on the screen, without words or numbers. I think we could have done better about making the color changes more obvious - especially because there's a certain point where if you make too many mistakes, your controls actually get reversed.

The one thing we didn't get to was clearly indicating why bad things were happening (e.g. when the Mover presses 2 consecutive arrow keys in a row, the Targeter is punished by having the reticle move slower). A visual "wave of badness" flowing from the player to the targeting cursor would be a nice way to represent that the Targeter's job would be more difficult because of a mistake from the Typer. But we didn't have the time to get to it.


On the Passage

Ephesians 4 is also very applicable to the whole of our development process. Having never used Unity (which this game was developed on) prior to this game, I was the beneficiary of much kindness, compassion, and forgiveness.

Our schedules didn't manage to line up well over the 2 weeks, so there were many cases where we would discuss something, and then it would get implemented by the other person in a completely different way. This was in fact, a really good thing. One idea could unintentionally spawn a completely different idea! While we wouldn't recommend businesses apply our practice of "innovation by mis-interpretation", I'm pretty pleased with how we were able to roll through and change things as different ideas came up.

Viewpoints were diverse. I like games that swiftly obliterate any hope you have of winning within the first 10 seconds. Sarriest does not. As Ephesians 4 suggests, we are all on the same team here, and a difference in viewpoints means we have more to work with.

The timing of this post lends it to be more of a retrospective than a true Devblog. Instead of a real-time log of thoughts, I instead get to provide a brief history of how this game came to be. Just because I tail-load all the writing doesn't mean I'll spare any development details - so I expect that this will just be the first post of many.

Of the 3 passages provided, we chose Ephesian 4:32 because it gave us a template for an idea (the general process being: "Step 1 - Read the verse. Step 2 - Wait for inspiration."). We were further inspired by an earlier phrase, Ephesians 4:25 - "for we are all members of one body". Compassion and kindness are universal virtues, preached among many faiths. So is the idea that humanity has to be united as one body.

The initial idea was to create a multiplayer game to illustrate both the struggles and rewards of being kind. We had no specific mechanics in mind, but wanted to create a game that rewarded players for betraying other players, yet still rewarding them even more for forgiving those who had betrayed them. However, it seemed inappropriate to try to incentivize players to co-operate for selfish rewards. And after a day of brainstorming, we couldn't find a mechanic that was fun.

So we shifted gears and tried to make a co-op game with the following guidelines:
- It had to be couch co-op, i.e. all the players had to be physically near each other (slightly so we didn't have to deal with networking, and also to make it so real-life interactions were integral to the game)
- Players had to all working towards a common goal (i.e. a true co-op game, not some co-op game where each player has hidden side agendas)
- Each time one player made a mistake, the price would be paid by the other players
- Players had to be occupied enough so that coordinating with other players required trust and efficient communication - we didn't want players to have the time to micromanage their teammates - trust and communication was required.

The final guideline (underlined and bolded) was the most difficult - we had to make something that toed the line between challenging and frustrating.

I didn't expect the final form of the game to have clouds, stars, and the player controlling a sun-like object. I didn't expect it, because the initial design doc had clouds, stars, the sun, and the words "objects are all placheolders until we decide what they are". Perhaps I shouldn't be that surprised that we were too lazy to replace the placeholder objects.

The game's mechanics, though, were changed many times, and the final version's (at least, the version we had at the deadline) mechanics turned out to be very different from the initial design doc.

Next up: Actual iteration and tweaking of the game's mechanics