The game is about you (Jebe) and your buddy (Frits), your arch nemesis (Frederik), and your wager to make it to the North Pole first. By hot air balloon, naturally!
We had to cut a boatload of features to get the download up in time, but we think this is the most minimal version of the game that’s fun to play.
We were inspired by lots of things! The biggest and most direct influences are:
– Roguelikes!
– Proteus
– Kerbal Space Program
– Dear Esther
– Last Exile
– Steamboy
– Minecraft
– Music we played (Kettel, Emeralds, Ochre, Biosphere, Deru, more)
So yeah, I’m still slogging through the implementation of the Split Screen Audio system I detailed last post. It’s boring, it’s a total bitch to get right, and once done it will merely enable functionality that you would consider standard in any other context; but it’s important and like me many developers have use for it.
Unity has been a right pain all the way through, too. (What happened Unity, I thought we were friends?)
“Did you know I actually wasn’t serializing your Dictionary.”
“Err, no you can’t extend GameObject. Why would you want to?”
“I’ve secretly overridden the Equals operator so your null-checks are bogus.”
“No, you can’t control order of instantiation, and no, I will not tell you when it happens.”
“This field value only exists in unmanaged code, good luck if you want to manipulate it!”
It’s not so much extending Unity’s functionality, it’s fighting against its functionality.
I chose Unity so I wouldn’t have to develop my own game engine and could immediately start building my game. It turns out that for anything other than a mini-game or a tech-demo you still need to do lots of non-trivial ground work. This seems logical to me now, but I didn’t realize this when I started.
Anyway, I keep telling myself that Volo will need a strong foundation, and that these features need to be in place before I can start creating the game properly. Whether that’s correct I don’t know, but it’s a way to get there, I suppose. Actually, you could argue that I should work these big frameworks into the game gradually, and you would be right. But at the same time I want to finish up these frameworks, start selling them to other developers, and actually earn some money off the work I put in the game.
I know you are anxious to play new, better Volo. Heck, you might be someone who pre-ordered (thanks!), in which case you’re definitely expecting more bang for your buck. I’m committed to making Volo Airsport into all that it can be. To you I say: I’m not going anywhere! I’ve refused jobs in the triple-A industry and stuck to freelancing specifically so I can do this, and while I may dabble with other game concepts from time to time (game jams) I never intend to work on those for more than just study. That said, Volo Airsport is a multi-year project and there’s no way around that. 🙂
You’ll have noticed: I suffer from a character flaw: I hate to disappoint other people, so when I inevitable get myself in a situation where that can’t be avoided, I tend to stop communicating. When I asked you to demand frequent updates at the start of this year it was precisely with regards to that. Thank you for demanding!
Ok, any more of this and this website will be more LiveJournal than development blog. I’ll finish these damn input and audio frameworks and get to the real meat of the game. Then we can have fun times!
Work on the split screen audio solution for Unity has ended up taking most of January. It’s quite mindboggling to consider that I had the basic idea up and running in a couple of hours of coding, but to properly finish it up it required thousands upon thousands of extra lines of code. I’ve been up to my armpits in disassembled Unity editor code, and have been forced to change course drastically at several points. I might do another big technical blog post about the development when its done, to serve as a roadmap for anyone venturing into similar territories.
It started so simple:
/* * Move real sources to correct relative position around the real listener. */
void UpdateRealSources() { // pair.Value = real source, pair.Key = listener foreach (var pair in _listenedSources) pair.Value.transform.position = pair.Key.transform.InverseTransformPoint(transform.position); }
Each Virtual Source has one Real Source for each Virtual Listener in the world. Each frame the position of each real source is adjusted according to position relative to its associated Virtual Listener.
And that’s all there is to it, really.
But then you have to actually integrate it in your game code and your editor, and by far the biggest problem becomes robustly modelling object and component relationships and comply to Unity’s editing workflow. I never, ever imagined there would be so many edge cases to keep in mind (especially all the different ways you can utilize prefabs). With every new use case there would be a new bug, another thing that would break. But that’s for another time.
Global Game Jam
Last weekend I participated in the Global Game Jam with six other friends. If you’ve not heard of it before, the premise is this: You go to one of the official jam venues near you, you get a theme to develop a game around, and you get 48 hours to do it. Go!
The theme this year was an audio clip of a beating heart. Here’s the, uh, thing we ended up with.
http://www.youtube.com/watch?v=H-aXW_CemuA (WordPress seems to be a bit broken so I can’t embed this right now. :/)
We associated the sound with a living machine, one with many individual parts that are all tightly intertwined and interdependent. From that interpretation came a concept for a multiplayer game in which each player controls a single element of a body or machine, is responsible for a singular task, but is entirely dependent on the other players to achieve success.
One player controls the heart and lungs. This player’s goals are twofold: Pump things through the system with the heart, and supply things with energy when they pass through the lungs.
Two other players control cells that live in the blood stream. They are responsible of transporting energy through the body, to be used by other organs, or by themselves to fight off infections. They have very limited means to move by themselves and rely on the heart to pump them through the system so they get where they need to be.
An infection starts to develop throughout your play session. The infected cells try to invade the body and remove energy from every part of it. Without energy none of the organs or cells will be able to do anything, and the body will die.
Live in harmony. Die in disconcert.
We were not able to finish what we set out to do (no gameplay yet), but we ended up with an interesting little toy and are very happy with how the Jam went.
The team consisted of:
Joost Pastoor (Game Design, Programming) Frank Versnel (Game Design, Programming) Ruben de Gooijer (Game Design, Programming) Bram van der Hoeven (Game Design, Sound Design) Robin Vink (Game Design, Graphic Design) Snoo Chen (Game Design, Graphic Design) Martijn Zandvliet (Game Design, Team Captain, Additional Programming)
My role was not so much to code the game, but to lead the team. Being the most experienced with game design and development I tried to make sure everyone felt invested in the concept, was able to do their work, and avoided common pitfalls. Not being the one doing the driving was a little scary at first but in the end it was a wonderful experience and I learned a lot.
Right, back to work!
P.S. Next post I’ll talk about the short term and possible long term features I have in mind for Volo. They’ve gotten to a point where they’re concrete enough to get feedback on. It has taken me a long time to figure out what the game is, can and should be.
As I mentioned last time I’ve been creating a plugin for split-screen audio in Unity. I can demonstrate the basics now, so here’s a video:
The plugin will be sold on the Unity Asset Store once finished, so if you’re interested in testing it or using it for your own games let me know!
Edit:
I uploaded simple a webplayer demonstration for you to check out: http://www.ramjetanvil.com/games/multiaudio_demo/WebPlayer.html
The Beta package is now ready for testing. Again, if you want to participate, contact me through email, or post in the Unity forum thread: http://forum.unity3d.com/threads/165694-Multi-Audio-Split-Screen-Audio-Plugin-Beta
Hey everyone! Hope you’re all enjoying the festivities. 🙂
Thank You!
Thanks to everyone for playing! It’s heartwarming that so many people like the game so much, even though it’s in such a raw state. And thanks again to the people who’ve purchased the game. While I certainly can’t make a living out of the earnings yet, it does let me purchase things like a license for a multiplayer networking package. Everything is being put right back into development.
Back in October I wanted to do a quiet release, just something to keep folks happy while I worked on a first ‘proper’ release. Of course, there’s no such thing as quiet on the internet, and the game got way more attention than planned. Rock Paper Shotgun and PC Gamer US both picked up on it for example, and many people enthusiastically shared the game with their friends.
While this was all very flattering, it also caused some pressure. Everyone was trying to play, but without configurable controls and a boatload of performance problems the game left a lot of people wanting. I thought I’d get some essential features done in about a week, which turned out to be a preposterous assumption.
Read what’s been happening since October below the jump.
Lowered Joint Iteration Count for player ragdoll to increase performance at the cost of slight loss of joint stability
Created a lower-resolution terrain to increase performance
Let me know what you guys think! Specifically, I want to know if this increases performance for anyone.
Happy flying!
Useful info from the previous post:
The game can be played with an Xbox 360 pad. For other controllers you’ll have to remap the configuration in the launcher window. Here’s the controls:
Back: Reset/Respawn
Start: Pause
Left stick: Pitch/Roll
Right stick: Camera
Triggers: Yaw
A: Close Leg wing
B: Close Right Arm Wing
X: Close Left Arm Wing
Y: Close Both Arm Wings
The first times you play you’ll find yourself tumbling down and crashing. This is perfectly normal. The control scheme is complex and gives you a lot of control; but it expects a lot of finesse.
Some tips:
A gentle touch is key
Pull back on the pitch control slightly maintain an even glide angle
Banking turns usually require simultaneous use of the pitch, roll and yaw controls to find the right balance
Close wings temporarily for fast manoeuvring
Crashing lots is fine
Please send me any feedback you have. Feel free to share the game with friends. And if you think you’ve gotten the hang of it, record your runs and share ’em on Youtube! I’m really curious to see what kind of lines you can pull off.
— Updates —
Donations
By popular demand I’ve set up a quick Donation page. If you donate $15 or more you are entitled to all future releases of the game!
Issues
Controls Configuration
Some folks are having trouble setting up their own gamepads and joysticks. The most common problem is that Unity’s button numbers start from 0, not from 1. So your joystick’s button 3 should be entered as button 2 in the configuration panel. Future versions of the game will have an in-game configuration screen for all this.
Playstation 3 Controller users can use MotionInJoy to map their controls to the game.
Performance
Performance on older or lower-end systems can be bad. If you experience framedrop, shakey bodyparts or stuttering camera motion you are most likely affected by performance problems. Don’t fret about having to upgrade your system just yet! I have lots of optimizing to do, and future versions of the game will likely run both faster and prettier.
Mac & Linux Support
Mac and Linux (ubuntu) versions of the game are on their way. A Mac version of the the first alpha release should be out within the week, but the linux version will have to wait a little longer (have to bring the game up to Unity 4 Beta release for that).
Small edit: The early preorder price is $15, not €15 as I previously wrote. Sorry for the confusion!
You’ll recognize the build from last year’s videos. This version is the old prototype I’ve had lying around since that time.
The game can be played with an Xbox 360 pad. For other controllers you’ll have to remap the configuration in the launcher window. Here’s the controls:
Back: Reset/Respawn
Start: Pause
Left stick: Pitch/Roll
Right stick: Camera
Triggers: Yaw
A: Close Leg wing
B: Close Right Arm Wing
X: Close Left Arm Wing
Y: Close Both Arm Wings
The first times you play you’ll find yourself tumbling down and crashing. This is perfectly normal. The control scheme is complex and gives you a lot of control; but it expects a lot of finesse.
Some tips:
A gentle touch is key
Pull back on the pitch control slightly maintain an even glide angle
Banking turns usually require simultaneous use of the pitch, roll and yaw controls to find the right balance
Close wings temporarily for fast manoeuvring
Crashing lots is fine
Please send me any feedback you have. Feel free to share the game with friends. And if you think you’ve gotten the hang of it, record your runs and share ’em on Youtube! I’m really curious to see what kind of lines you can pull off.
— Updates —
Donations
By popular demand I’ve set up a quick Donation page. If you donate €15 or more you are entitled to all future releases of the game!
Issues
Controls Configuration
Some folks are having trouble setting up their own gamepads and joysticks. The most common problem is that Unity’s button numbers start from 0, not from 1. So your joystick’s button 3 should be entered as button 2 in the configuration panel. Future versions of the game will have an in-game configuration screen for all this.
Playstation 3 Controller users can use MotionInJoy to map their controls to the game.
Performance
Performance on older or lower-end systems can be bad. If you experience framedrop, shakey bodyparts or stuttering camera motion you are most likely affected by performance problems. Don’t fret about having to upgrade your system just yet! I have lots of optimizing to do, and future versions of the game will likely run both faster and prettier.
Mac & Linux Support
Mac and Linux (ubuntu) versions of the game are on their way. A Mac version of the the first alpha release should be out within the week, but the linux version will have to wait a little longer (have to bring the game up to Unity 4 Beta release for that).
(Crossposting here since 7DFPS.org seems to be down)
Over the last week my friend Robin and me created a first person shooter game in seven days, participating in the 7DFPS challenge. It was close, but we made it just in the nick of time! Our game is called Armed & Dangerous: Opposing Thumb, and we’re quite happy with it.
In Armed & Dangerous you play a robot defending his lovely Data Cube. Build a fort, kill the oncoming drones, and defend the Data Cube at all costs. The game is player cooperatively with a friend beside you. The trick is that you both control the same character, a robot, and you have to really work together to win.
One player controls the left arm, the other controls the right arm. Both players can run, look and jetpack at will. All this means you have to coordinate, otherwise you’ll just stumble around and not get anything done.
You can grab things, you have guns, and bad guys want to kill your Data Cube. Stop them no matter what!
You can check our dev-blogs and download a playable version on the 7DFPS project page, although the website seems to be down right now. Direct link for windows version:
This first version is very rough, only available for Windows, and only playble with two Xbox 360 controllers. We will be updating with more builds and better support for platforms and input devices though.
This is work in progress, but she’s airbourne now.
To aid wingman in moving around the world I’m adding vehicles. Having controllable airplanes to skydive from is a feature I really wanted to add, and besides: you don’t want to walk everywhere do you?
I’m creating a modular set of mechanical parts and aerodynamic tools with which vehicles can be created. I’m keeping them all the components quite simple so that it it’s a snap to create a new airplane.
Once that’s done I’m getting my feet wet in networking this stuff so it can be enjoyed over multiplayer. Then the wingsuit goes back in.
Hey Everyone! Err, this is a little awkward after all this time…
First, here’s something fun. Last year I worked with a couple of guys from Koelstof (some of you may know Jarno Cordia, who works with Phoenix Fly) to produce a prototype for an arcade wingsuit game. We put something together in a couple of days, and the result looked like this:
You can try out a webplayer version as well! (Requires Unity browser plugin)
This thing has been lying around for a year, and none of us were really doing anything with it. Recently some kind folks contacted me to ask if I would help them build their game, or if they could use parts of the source code for it. The game has a different theme, but shares some of the core mechanics. I’m working out a deal with them right now, so with any luck you will see this thing come to life soon.
(Just to be clear, this is not Volo, nor is it related to it. Volo is very much on the simulation side of the spectrum, while this game is distinctly on the arcade side.)
So what about Volo?
I have spent the last year setting up my freelancing business. I started out as a complete newbie, and have been stumbling my way towards a vague sense of competence ever since. I’ve been meeting a lot of interesting people, and have been learning a lot. Scoping projects, not not biting of much more than I can chew, and getting work done in time. I renamed my business to Ramjet Anvil (an almost-anagram of my name), and I am looking forward to working under that banner.
But crucially, I burnt out on Volo big time last year. It’s very ambitious for a first game, and to think I could pull it off was at least a little naive. Perhaps I should have done a 2D platformer first, heh.
Progress ground to a halt. I kept staring at the Unity project for days on end until I was banging my head against the monitor in frustration (no joke there). It got to the point where I figured I should cut my losses and move on to a completely different project; something a little more suited to my skill level. I thought I couldn’t realize this game, and I did not want to make promises to you guys that I would not be able to keep.
Meanwhile, every day I received youtube and facebook comments along these lines: “Holy shit! I’m throwing money at the screen but nothing is happening!“, as well as: “Hey man, are you still working on this game? It’s so sad to not see any updates…” These comments are very heartwarming, and they slowly made me realize that I was onto something too big to just throw away.
So now I want to try it again!
The biggest problem that I faced was that I wasn’t able to handle the sheer complexity of the physical simulation. With so many moving (body-)parts, and without adequate tools, it took weeks to understand the consequences of even the tiniest gameplay tweak. Not instantly seeing the effect of your changes has a devastating effect on your productivity. Imagine trying to draw a picture, but you only see the lines you draw appear half an hour after you’ve drawn them! It’s not impossible to work that way, but it is extremely difficult. I only really realized this after watching this wonderful talk by Bret Victor, a designer/engineer with a resume so impressive you’ll fall of your chair. If you’re at all interested in the fields of design and engineering I highly encourage you to check this talk out:
(And read his article on the Ladder of Abstraction; it applies so much to my Volo troubles I almost cried.)
So, I’m picking things up again, but taking a different approach.
First, the focus is not on realism, but on gameplay. This is to avoid the pitfall of adding lots of complex stuff even though it isn’t needed for the play experience. For example, most players think there is a very complex wind model in the game. There isn’t; so why would I focus a lot of time on putting one in, at least early on? It’s good enough as it is.) I’m also looking for a stylized look for the graphics. Something simpler to produce, better at communicating the simulation state, and something that will not look old and ugly the day the game comes out. A stylized and slightly fictional look would also enable me to get away with not simulating some things. Just boring things though. 😉
Second, I need to build adequate tools to deal with each bit of complexity I add to the simulation. Unity’s default tool set is great, but it will need significant additions if I am to tweak aerodynamics with it. I need wind tunnel testing with exquisite graphical readouts, and I need it now.
Third, multiplayer code needs to be in there right from the start.
With those things in mind I first plan to get some basic aircraft flyable on a multiplayer server. Once that is up and running add first/third person walking, getting in and out of vehicles, switching a character’s gear, and then finally wingsuit flight.
As always, let me know what you think!
And thank you for staying interested, it means much to me.
