The latest gameplay video for VSR. The presentation got a complete overhaul since the last gameplay video, which is what this focuses on.
Advertisements
I feel that combat can very easily make a game feel repetitive and stale, which is strange because combat is usually added with the intention of giving players more to do. To circumvent this problem in Vision Soft Reset, I want to introduce a large variety of enemies that all feel distinct from each other. This includes differences in movement patterns, appearance, and even their cries upon death. By mixing different enemies together for each encounter each battle can feel like a fresh new challenge.
And here are four such enemies below, wonderfully animated by Elias Frost, VSR’s second sprite artist.
Sealime:
A green seal-like creature that is usually content with just flopping around. But some Sealimes are more dangerous than others, and will fling a barrage of projectiles if they feel threatened. The Vision mechanic can be used to reveal which one will strike before being in the line of fire.
Ciurivy:
A squirrel-like creature that can lob explosive acorns. They never seem to run out, but luckily they’re not very hard to avoid.
Magoom:
A mole-like creature that moves quickly while aimlessly slashing its claws. Magooms will occasionally burrow into the ground and surface in a different location.
Smosey:
A small mosquito-like creature. Not very threatening on its own, but in groups Smoseys become much more formidable.
Hi everyone. It’s been a while since the last update, and much of that time was spent reinventing the visual presentation of Vision ~ SR. My own art that I had been making was not meeting the quality standards the game deserves. So here I welcome Arron Johnson, a skilled sprite artist that has been working on improving the in-game assets. It took some discussion, but eventually we decided on a great new look for the game, a taste of which is below.
Pretty much everything has changed; from the UI elements to the ship to Oracle herself. The way Oracle is rendered was even modified. Instead of an ordinary sprite sheet, there are now two separate sprite sheets used to animate Oracle: one for the upper body (e.g. aiming) and one for the lower body (e.g. running). It’s a simpler workflow on both the artistic and technical sides, allowing me to easily change the stance of Oracle’s legs based on the slope of the platfrom she’s standing on. It’s a nice feature you don’t see in many sprite-based games.
Other characters have gotten face-lifts as well, while still retaining my original vision for them. We also finally got profile images for the text area, handily provided by concept artist Molly (who you might remember from the previous update).
The island tilesets and backgrounds have received improvements as well. Levels are being reworked to account for the new look of these assets, and they are not quite ready to be shown off yet. But the slightly-obscured screenshot below shows a bit of what it’ll look like.
With the revamp it’s only fitting to update the .gifs on the Gameplay page that explain some of Vision ~ SR’s key features. Here’s the new .gif of the Flashback mechanic:
And below is the new .gif showing the Vision mechanic. The shader rendering the silhouettes also changed; now they appear as a solid gray color rather than a grayscale version of the sprite. This was done to reduce noise and more clearly differentiate the difference between attacks and their intangible visions.
By contrast, here are the old versions of these animations:
Quite the difference, wouldn’t you say? I’m excited to think it’ll only get better from here.
After showing off some gameplay last month I realized I wasn’t satisfied with how the game looked. Despite my best efforts the sprites I made looked too plain and simple, and it would take a disproportionate amount of effort for me to get Vision ~ SR to shine on my own. Over the month of May I’ve been chatting with some skilled freelancers, and a few have signed on to work on this project. By living cheaply I’m able to offer fair compensation from what I make at my day job. One could look at my game’s development as a “really expensive hobby”, with “expensive” referring to money and free time. But since I’m an adult now I can do what I want.
On this post I highlight the efforts of Molly Heady-Carroll, who will be creating concept art for VSR’s prominent characters and bosses. So far she has been great to work with and you can expect more spectacular creatures to be shown off soon. But for now I want to focus on the evolution of the design of Oracle, the main protagonist.
Oracle
Oracle is a cybrog, the design of which was inspired by BR-W9 from the 2009 game Contra Rebirth. The decision to have VSR star a cyborg that can see the future was made for gameplay reasons; I needed a character that had most of their abilities from the start, but would be unable to use them until the player progressed through the game (I’ll go into why in a later post). With this reference I initially just dove into making the sprites from there without drawing it out first.
As it turns out, getting a cyborg to look appealing while not falling into the uncanny valley is quite a challenge. The first design had a stoic, creepily serious expression that never sat well with me. I later replaced the face with a singular “eye” to make it look more appealing. It wasn’t until I decided on getting a revamp did I consider updating the look further.
Amusingly one person told me that Oracle’s sprite resembled a “purple fox furry”, and someone else drew it like that. Clearly this was not the intention. But hey I got my first fan art of the game, so that’s a milestone right there.
Anyway I had Molly design some concepts, and we eventually reached on a final design shown below. The alterations to Oracle’s “hair” was a great change; making her look more sleek and futuristic without being creepy. Basically the concept artist made an illustration based on the pixel art sprites… which seems backward in retrospect.
Larva Oracle
Larva Oracle is Oracle’s true, suitless form. While in the suit Oracle is a dangerous force to be reckoned with, and I thought it’d be funny if it was actually being controlled by a cute bug the entire time. I still wanted a hint of mysticism in the design, as she’s still powerful with her ability to see the future. In fact in larva form Oracle’s clairvoyance is a bit stronger, but she lacks any combat ability. The four spots on her back are receptors she uses to commandeer the suit.
Currently Larva Oracle is only briefly shown in the game on the title screen and during her death animation. The form will be more significant as the game continues.
Thanks for reading, I’ll be sure to share more designs and other fun insights soon.
“Vision” describes the passive ability of seeing silhouettes of attacks from enemies a shortly before they happen. It empowers the player by giving them an extra bit of time to react to danger. Vision is a unique mechanic, and to my knowledge there hasn’t been a game before that offers a feature like this.
This idea came to me when considering how gameplay would work with the Flashback mechanic, where every time the player made a mistake, they could rewind time and correct it. This lets the player learn what the enemy is going to do next and play accordingly, which is a neat concept, but the execution didn’t seem much fun. Rewinding every time the player gets hit seems like it would get boring after a while. Having visions of the future was my proposed solution of preserving the concept, but removing the tedium from rewinding time. The name was inspired from a similar concept featured in Xenoblade Chronicles, a game I knew about from the Super Smash Bros. series but never actually played. Later I found out that the vision mechanic in that game works much differently than my idea for Vision ~ SR. So…it’s still unique! Still my idea!
Visions of enemies (and projectiles the visions spawn) are rendered as cloned versions of the original enemy with a simple grayscale shader. The visions make no noise and have slightly transparent sprites, which makes it clear they’re intangible. But they’re not so faint that the player would miss them. I also try to have enemies attack in such a way that movement is involved, resulting in a vision that moves around and stands out.
Functional Restrictions to Enemy Design
But that’s not the only way this mechanic influences enemy behavior. Obviously for Vision to work we need to know exactly where an enemy will be and what it’ll be doing in the next second. So for the span of time from when a vision appears to when the attack actually happens, the behavior of the enemy needs to be deterministic and predictable. This is surprisingly difficult to implement, as it turns out, and forces interesting limitations on enemy behavior.
Consider a Goomba from Super Mario Bros. It’s pretty hard to think of an enemy that’s more simple than something that just walks into you. If we wanted a Goomba-like enemy in Vision ~ SR to create visions of itself, we would need to be able to predict exactly where it would be in the next second. How hard is that?
If a Goomba walks in a straight line without accelerating, then the position it’ll be at is a simple function of speed and time. But what if it walks off a ledge? Considering where this ledge is or how above the next platform it is, it can be tricky to tell where it’s going to land. This might be manageable if we didn’t also consider that Goombas reverse direction when hitting a wall. What if, in the span of a second, a Goomba falls to a lower ledge, walks a bit, turns around after hitting a wall, and walks a little more? Where will he be then? Short of simulating a second’s worth of physics and movement in a single frame, there’s no reasonable way to tell! And that’s not even considering the possibility of bouncing off of other Goombas!
As it turns out, even a basic Goomba would be too hard for me to use the Vision mechanic before, as its movements are based off of reactionary behavior. Enemies with Vision-friendly attacks would need that span of a second to be completely planned out. In other words, position and state would all have to be determined from a pre-specified function of time. For example, enemies that move back and forth in Vision ~ SR do not react to the presence of walls. Instead, they move within static predetermined invisible bounds that make movement predictable. Given their speed, starting position and time since they first spawned, we can create a formula that gives us exactly where they’ll be at any other time. These predictable, deterministic functions are essential in creating enemies for Vision ~ SR.
Making Vision Fun
And here comes the really hard part: making sure these predictable movement patterns are actually fun for the player to fight against. On its own this predictability is boring and defeats the purpose of having the protagonist see the future in the first place.
Introducing randomness is a simple way to make enemies more interesting, and while we can’t add it to the spans of time when a vision is formed, we can instead use it at any other time. The movement behavior of an enemy when it isn’t attacking can be wild and varied. The time it takes for an enemy to prepare an attack can change as well, as long as it’s longer than the duration of the vision. We can create enemies that feel spastic and unpredictable when they actually aren’t for a specified block of time. This creates a more engaging encounter that makes the Vision mechanic useful for the player.
Another way is to make enemy attacks absurdly powerful and over-the-top. Vision gives the player plenty of opportunity to dodge, so while it’s easy to not take damage (and even easier when combined with the Flashback mechanic), the player can still feel accomplished for outmaneuvering devastating blows. Basically the player is OP, so in response I also made the enemies OP and that’s called game balance.
The player will also learn to value the mechanic, since Vision can be temporarily lost if the player uses Flashback too much. Predicting enemy movements without the aid of Vision is much harder, and will force the player to take a different approach, making the possibility of losing Vision a very important inclusion to the game. It also separates visions from “tells” of enemies in most other action games. If visions were essentially just tells it would be a pretty worthless mechanic, so I wanted to come up with distinctions between the two. To satisfy this Visions will occasionally be formed for non-attacking actions as well, such as teleporting or using healing techniques.
And here’s one last observation about the mechanic: visions cannot be made in response to anything the player does. For example: it would be impossible to create a vision of an enemy successfully landing a hit, taking damage from a bullet or dying. I want to devise enemies that take advantage of this, although at the time of this post there are no enemies in the game that do. Counterattacks and “combos” from a hit confirm are examples of attacks an enemy can perform without creating visions while still remaining consistent with the Vision mechanic. As these moves would likely be confusing for new players that are still learning how the game works, these will be restricted to late-game enemies and bosses.
Future of Development
At the time of this post Vision ~ SR is very early in development, so barely anybody knows about this mechanic. I have no idea if this idea will be received as fun, obstructive, or forgettable. It’s a risk that’s going to require a lot of playtesting and tweaking, and I hope people enjoy it!
There is no background music yet! Apologies if this makes the video awkward!
This video shows an early glance at what the gameplay will be like in Vision ~ SR. It showcases the title screen, basic movement, basic combat, basic exploration, and the Chamber Flashback ability.
I intend on commissioning a composer for music soon. Presentation videos like these should be made first though to let them know what they’re actually making music for.
Hi everyone! This is the first post of the development blog for the upcoming action-adventure game Vision ~ SR. What better way to start than explaining how it all began? It’d be good to write this all down before I forget anyway.
Initial Concept
Among many other sources of inspiration, the core idea behind Vision ~ SR came from the 2014 movie Edge of Tomorrow, where Tom Cruise’s character learns more and more about how to stop an alien invasion by repeating the same day over and over. This movie was supposedly inspired by hard levels in video games, where the player fails a level so much that they eventually beat it just from remembering where all the enemies are and what they’re going to do. This always seemed like cheating to me though, as the protagonist within the universe of these games would have no way of knowing all this information about the level ahead of time. But what if there was a game where this was the entire point? Would it work? Would it be fun?
Contra and Contra: The Movie
In the summer of 2015 I came up with the following concept for a game. The player is given a short amount of time (e.g. 15 minutes) to collect four keys in some sort of labyrinth. The majority of the game would be preparation; using the short 15 minute periods to enhance the player’s own abilities and determine the location of the keys. The paths taken would resemble a tree starting from one root location. One path would have the player heading right, one heading left, one heading left and then down, and so on. Ideally each path would serve a purpose, like determining the location of a key or unlocking a new ability. Once the player has learned everything they need to know about the labyrinth, they must use their knowledge to plan a route that would allow them to snatch all four keys and unlock the final door in the short 15 minute time limit.
This structure interestingly resembles basic concepts used in graph traversal. The initial runs are like depth first searches of a maze, and the final speedrun-like segment resembles a solution to a “travelling-salesman” problem, a classic “hard” problem in the Computer Science field. For a while the game was called “Nondeterminism” for this reason, but the name was dropped for being a mouthful to say.
Vision ~ Proto
With the general structure of the game planned, that left the question of what the minute-to-minute gameplay would be like. It could be anything really. I chose a 2D platformer with shooting combat just because I like those kinds of games and had experience developing them.
I also wanted unique features that fit the “seeing the future” theme. This is where the titular Vision mechanic comes from, which allows the player to see silhouettes of enemy attacks a second before they actually happen. Going backwards through time, denoted Flashback, was also thought of at the beginning but initially I wanted it to be an unlockable ability the player would get later on, and wasn’t even sure the mechanic would be fun. But I figured if there was even a small chance of including this mechanic, it would have to be integrated into the game’s code from the very beginning, which is why it was developed first. More about Vision ~ SR’s gameplay can be found on the Gameplay page.
To test out the minute-to-minute gameplay, I created a prototype version of the game called Vision ~ Proto. Proto was very short, and merely consisted of waves of enemies that the player had to defeat. It showed off the gameplay, but little else. Proto was a two-month project with a hard deadline of November 20, 2015, the date of that year’s Rensselaer Game Showcase (RGS). RGS was an annual event at Rensselaer Polytechnic Institute, the university I was attending, that allowed students to show off their game projects to the student body. Naturally it was a great opportunity to collect feedback from players.
Vision ~ Proto at RGS
Vision ~ Proto Screenshot
People enjoyed it, I think. Nobody hated it. That was good enough for me, and I made the push to expand the game into Vision ~ SR. I knowingly added features I knew would be removed for the real game, like a scoring system and a simplified menu, which resulted in some wasted assets.
Pushing the game to the next level was a long and arduous challenge that required me to work on it at least a little bit each day. Menus, upgrades, dialogue, a tutorial, multi-screen rooms, multiple rooms, a map, more enemies, more environments, and even the initial concept had all yet to be implemented. It took 4-5 months to evolve Proto into the game’s current state. Now that many core features are now implemented (with the notable exception of music), interesting updates should hopefully be coming out more frequently.
