Air Carnival is a Unity-made game based on the fictional sport of Flying Circus, originating from the series Four Rhythm Across the Blue (Ao no Kanata no Four Rhythm). The rules are simple, hit the buoys in order before your opponent or strike them on the back to score a point, with the player scoring the most points in a set amount of time winning.
The Interesting Parts
Despite its simple ruleset, Flying Circus was a sport I’ve been eager to look into since watching the show a few months back. Given the free-flying 3D environment and potential for special moves and customisation in-air, it came across as a treasure trove of cool things. One of the more interesting things is shown towards the end of the series with the idea of stabilisation. With stabilisation on, the anti-gravity is easier to control, but turning it off gives participants far better control if they can handle it. I feel this would probably map well in creating an additional sense of risk and reward.
- Flying Circus basic implementation
This would be a simple game where players can fly around a map and race to touch buoys before their opponent. At this level, hitting the opponent on the back won’t be a method of scoring points.
- Special moves
These could be mapped to a button for simplicity, or triggered if I can find a way to detect certain movements. Things like Scissors and Yo-Yos seem trivial, but moves like the Air Kick turn might pose more of an issue. I feel the biggest problem will be tying these moves into offensive options.
- Back touching
Scoring points by hitting your opponent on the back. While implementing this in concept is easy, making a fun gameplay mechanic out of hitting a small moving target probably is less so. Even in established air combat games such as Ace Combat or Earth Defense Force (using Wing Divers), it’s rarely a case of aiming yourself into something in this way. Adapting back touching into some kind of targeted attack that can to some extent home in is probably the way to go.
- Different arena and buoy layouts
This seems trivial if the game is structured properly. Simply store buoys in an array in the currect order, and reuse the script later with a different layout. It’ll probably be something small but increasing arena diversity will make the game far more replayable.
- Character customisation
While this could include skin customisation, the main focus here is on ‘fighters’ and ‘speeders’ seen in the series. Fighters have high acceleration with a lower top speed, with speeders having the opposite. This could be implemented using something like the scale you see in F-Zero games, giving you the option to tweak the setting to your liking. Here, anti-gravity stability could also be configured. With a lower stability, perhaps offer an increase to the maximum speed at the cost of handling. Each percentage of stability lost could represent a random chance for your left or right momentum to fall slightly out of balance to make it harder to control without being too destructive to the overall experience.
- Maybe some dialogue
On-screen advice from your second seems like a fun idea when certain events occur. This could include reminding you of time limits, offering encouragement, or even advice on the enemy’s strategy.
With this project being submitted as a ‘Game in a Week’ for a university assignment, the aim is to begin planning today (Monday the 28th of January) and have a playable and reasonably polished version for Sunday. While I might not be able to get everything I want into this project by the due date, I’m hoping to do a bit of work beyond this to get it to where I want it to be. If you’re interested, you can check out my creative process and progress on a day-by-day basis below.
Monday - Planning
Today, the focus has been on getting everything together. I’ve written this up, created the project, and got it all linked up here (or at least will do shortly). Being a programmer, the one thing I feel I’ll have to compromise on is the graphical side of things. This means I’ll likely be using basic 3D shapes to represent characters (I’ll probably end up going with beans because beans are cool). It’s a slow day, but I’d like to think I know what I want to be cracking on with. Tomorrow, I’ll put together a basic scene and see if I can get a bean off the ground.
Tuesday - Getting Started
The bulk of progress today came from designing bean movement and setting up various things I haven’t looked at before. I have an Xbox controller setup nicely, as well as smaller things like learning how cool a LineRenderer is! The bean is a bit of a pain to get my head around to be honest, but the general idea is that pressing RT will add force from the bottom of the bean, where you can then steer them as you want with the left analogue stick. Kind of like a rocket in my mind, only a bit more beanline. I’m thinking the way to go is for left stick to just rotate the character, and keep the direction of the force constant from a local perspective. For the time being, I’ll also work without gravity. The beans are supposed to be wearing anti-grav boots after all, gravity wouldn’t make sense. A casual floating animation if the character isn’t moving would be nice though!
Wednesday - Floaty Bean
Not all too much went down today. I’ve applied force in a seemingly logical way to the bean, and hey, it moves now! The controls aren’t all too different to your standard air combat, rolling instead of turning for the mostpart. It’s fine as it is, but not ideal. It has a long way to go before being something satisfying to play around with, it’s far too floaty at the moment. There are a few things I need to be considering going forward. The first is being stationary in the air; it doesn’t make sense for the bean to be laying forwards if it’s not moving. If there’s no force being added, the bean should slow down and straighten up, before going into an idle bobbing motion in-air. It doesn’t seem too complex, but I feel it’ll make things feel a lot nicer. The next big thing is gravity. It’s easy to throw it aside on the basis of the beans being anti-gravity, but hear me out. If we want such intense special moves as the high and low yo-yo, it’s something that needs to be considered. With this in mind, I came to the conclusion to only factor gravity into the player’s movement when either ascending or descending, this tracked by looking at the L_Vertical axis value. If it goes past a certain point, put gravity into the formula proportionate to the value. It makes sense in my head, but it’s another thing to see it through. There’s a few smaller things on my mind like multipliers for turning and drag, but I can figure those out once the essentials are ironed out.
Thursday - A Day Off
Perhaps not the greatest idea given the circumstances, but what’s done is done. Other projects needed some attention, and I also accidentally sunk several hours into Mario Tennis with a friend. It’s not to say this hasn’t been on my mind though, the most significant point being AI. Separating AI behaviours into the player classes of speeder and fighter to create a simple degree of variance seems like a good idea if AI is the route I choose to go down. Something else I’ve been heavily considering is a split-screen local multiplayer mode, which as you might imagine would be easier (assuming splitting the screen isn’t a difficult task). This seems like the kind of thing I should decide on later when the player controls are ironed out, having human PvP as a fallback if needed.
Friday - CharacterController
So after deliberating the use of AddForce() with a Rigidbody, I came to the conclusion it was simply far too floaty to provide the fast and reactive control scheme I’ve been aiming for. With this in mind, I decided to give a CharacterController a shot, and at first glance it seems pretty nice. The controls feel sharper and more responsive from the getgo. It’s not to say they’re fine as they are however, there are still a few things that need attention in this department. The most prominent of these comes from turning (kind of a key part if you ask me). Sure, it feels more responsive now, but it’s far from being precise. The current setup of rolling to turn works reasonably well when in motion, but it’s just too easy to overshoot the target. I do have options here. The clear fallback would just be to make things bigger. Bigger target, the less imprecision matters. Of course, that’s a fallback. Realistically, it should be a case of fiddling with roll multipliers to find something that feels ‘right’. If I can’t manage that, there’s also the possibility of reworking the left stick to actually be moving the character left and right, in oppose to just rotating them. I still have a weekend to get these things figured out, so I’ll be putting my mind to it. With some luck, I’ll have something fun to play by the end of this.