Been working on a clean little font for a while. Vectagon originated from an attempt to create a visual identity for an indie game. The game focusses on geometry, so does the font!
Vectagon development blog, containing thoughts, secrets and tutorials from Tom, Matt and John.
Play online at vectagongame.com
You can just about see the tunnel splitting on the right hand side.
High FOV makes the geometry fall into line. Pretty unplayable though!
Time for some more theory! Today we’ll be looking at one of the 4 categories of play set down by Roger Callois; ilinx. Let’s start with a quote explaining just what this is.
"Ilinx creates a temporary disruption of perception, as with vertigo, dizziness, or disorienting changes in direction of movement." - Wikipedia
Some examples of Ilinx play might involve spinning around on the spot, riding a rollercoaster or eating some special mushrooms. Vectagon fits pretty nicely in this category. In fact, it’s almost defined by the category. Mechanically, Vectagon does very little to separate itself from the crowd - Super Hexagon, Temple Run, Doodle Jump all use twitch responses and rely nearly entirely on skill (ludus).
- Fotonica uses a strong sensation of speed to create ilinx.
"Ilinx, therefore, can best be understood in the context of videogames as an experience enhancer.” (Beyond Game Design: Nine Steps Toward Creating Better Videogames, p87).
Vectagon stands apart from the crowd because it’s a game designed around ilinx, using dizzying visuals, warping geometry and a strong sense of speed to draw the player in a hypnotic space that can fixate them for long periods of time - longer than if I hadn’t put focus on ilinx.
Small FOV results in some tidy Playstation dashboard effects!
Happy Sunday! Here’s another funky experiment from Vectagon HQ.
For the last few days my works on Vectagon has been fine tuning the “feel” of the game. It’s hard to pin down how any game feels, but we often describe specific elements as feeling “heavy” or “slippery”, especially in games where you’re controlling a vehicle. We want Vectagon to feel “fast”, “alive” and “responsive”.
So let’s talk theory. A while ago three big name game theorists came together with a framework for approaching game design called MDA: Mechanics, Dynamics, Aesthetics. The mechanics are the hard-coded rules of the game, the dynamics are how the mechanics come together in play to create a system, and the aesthetic is how the dynamics of the game feel to the player. Their point was that players and designers start at opposite ends of the framework, and by looking at the game from a player point of view we can better create experience-driven games rather than feature-driven games.
This is helpful to us when trying to nail down a feel because we can use an aesthetics lens to help define the nature of the problem (turning feels “unresponsive”). Now we understand the problem is to do with the sensation of play, we can consider how changing the dynamics will change the aesthetics for the better (increased player control over turning). Lastly, we change mechanics to create the intended dynamic (pressing the rotate key for shorter/longer will affect rotation speed).
So what have we been doing to create the feel we’re looking for? We’ve added early camera banking, a field of view tied to player speed, subtle visuals to give a greater sense of space and some near-miss effects. And plenty more!
If you want to get involved with testing the latest version of the game, send us a message!
Twist and bank, with a fiery palette and a low FOV.
We’ve been doing some experimenting today, testing out the range of visual effects we can achieve with our tech. I’ll be posting a unique screenshot (no Photoshop involved) of our experiments once every day this week, starting now!
All in series:
Part 1 -
Part 2 - Part 3 - Part 4
Happy Halloween everyone! I’m going to begin a new series of posts where I talk about the logic behind Vectagon. I’ll be talking about three major parts of the code; the path, the shapes, and how those two components come together to create the final tunnel mesh. I’ll be providing source and demos for each concept, which will always be at the bottom of the page.
What is the path?
In Vectagon, the tunnel you ride is constantly twisting and turning. It might look like the player and gates are strapped to the tunnel, but in reality all of these objects are reading position and rotation from the same Path object. Everything that follows a path is subclassed from the PathSlave class which contains all the necessary data to interface with a Path. As the whole path is saved until the game resets, I can move GameObjects along it by only changing the distance variable - much like an animation, except we’re not scrubbing through it using time. This system is likely similar to that in a time rewinding game where positions need to be stored over a fluctuation variable, such as Braid.
How do we store positions and rotations?
We use AnimationCurves to store data in a graph form. There are 6 curves: xRotation, yRotation, zRotation, xPosition, yPosition, zPosition.
The Y axis of each of these curves stores the value of position/rotation, and the X axis represents distance along the path.
Inside the Path class are two vital functions, GetPositionAtDistance, and GetRotationAtDistance. They read from either the position or rotation AnimationCurves, and create a new Vector3 (for position) or a Quaternion (rotation).
PathSlave is a class which updates its own position and rotation every frame by calling the functions we discussed above on its pathToFollow variable, passing in its distance along the path. The pathToFollow variable is left open, meaning that we can have slaves follow any path we create in our game.
Now we have a path and a slave to follow it, all we need to do is alter the AnimationCurves on the path and set the slaves path to this path. See the results yourself below!
Next time we’ll be looking at how Vectagon draws its path procedurally.