We’re launching Chasing Aurora on day one of the Wii U in Europe, Australia as well as New Zealand. Tomorrow, when you go to your store of choice to pick up your Wii U, and after a quick download of a firmware update, you’re able to get Chasing Aurora from Nintendo eShop. The price is EUR 11.99 (AUD 15.60, GBP 10.79, CHF 16.80, NOK 96.00, SEK 120.00, DKK 90.00, PLN 48.00, RUB 479.00, NZD 20,40) and the download is about 110MB. Then you’re going to invite up to four friends and play through the short tutorial to unlock three multiplayer game modes in 14 unique levels. We’re so looking forward to your feedback.
What is Chasing Aurora? An action-packed single player game? A moody multi-player game? The simple answer is: Chasing Aurora is a series of games. We originally devised it as a series of three games. We’re working on two of these at the moment. One is a multi-player game that is best played together with friends in front of a TV screen. This is the game we’re going to bring to the Wii U first because it is tailored to home consoles. There’s also a vast single player game that we’re working on. This game will take longer to develop because it requires more content. Both games are connected on several levels. They share technology. They share assets. They share characters and sound effects. Most importantly, though, they are set in the same world. This is the heart of Chasing Aurora: The loss of innocence in a merciless nature. The story arc follows the development of the main characters from the innocence of childhood to the wisdom of age.
Chasing Aurora (work in progress)
The first game is centered around child’s play. It’s a multi-player game and the game modes are based on folk games. The games children play take place in their fantasy world and the real world at the very same time. The hunter in freeze tag has the fantastic power to freeze the players. Imagination fuels the simulation. Children’s games are brutal but the brutality is just part of the fantasy. The games are played in all innocence. Yet there’s already a shadow cast over them. While the conflict is staged the games serve as training for the struggles of life to come.
Then a real conflict begins. In the single player game of Chasing Aurora, the player is tasked with a mysterious mission. There’s a dark ritual that marks the transition from child to adult. That rite of passage is the main story of the game. While growing up is a gradual process, many cultures have a ritual that signifies the progress to adulthood. All major religions have coming of age ceremonies. After the ritual, the child is held accountable for his or her own actions. Bar/Bat Mitzvah, confirmation, Samavartanam. All of them mean different things, yet all of them mark the transition from one phase of life to the next. The child turned adult gains freedom and pays with responsibility. In some instances, the young adults have to prove that they have, in fact, grown up. The player faces such a trial in the second game of Chasing Aurora.
The big picture is that we are building a world. A world that we flesh out more and more with every game. It could happen that we squeeze in a small game for another platform between the first “big” title and the second. While the similarities between the games might be easy to see on first glance, the true bond between them lies in the common themes they have. The longing for an intact nature. The manifestation of a dream reality where humans can fly. The question of consequences of ones actions. The struggle of developing a personality that one can – that one has to – live with for the rest of their lives.
This is our vision. This is our quest. This is Chasing Aurora.
We’ve just announced the first platform of Chasing Aurora: the brand new Nintendo Wii U.
We are very excited to work with this new platform. It is full of possibilities. It is social. It has a unique controller. It features excellent connectivity. It has a great development environment. It is plain awesome.
While we can not show you any images of the game running on the device, we will speak much more openly about the development from now on. That means no more lengthy vague friday updates. Instead, you’ll know it first if we’re working on a hot new asynchronous multiplayer mode with Wii U GamePad support. If you follow us on Twitter you’ll learn first hand how it is to develop for a console that is not even on the market yet. And we can tell you: it was awesome to see how Nintendo has designed this complicated piece of machinery. We can’t talk about anything that is still secret, of course.
At the same time, we’re now at a point in the development of the game, where we sometimes need the opinion of the public. Your opinion. We’ll ask some questions on Twitter about specific features in the near future. And we’re happy if you get involved.
Here’s the list of features that are confirmed by now:
Unique physics-based flight inspired by the age-old dream of human aviation.
A fresh and mysterious world to explore.
Outstanding 2D vector- and pixel-based art style right in the middle between origami and pop-up book.
Challenging creature AI and spectacular physics- and frame-based animation.
Original soundtrack performed on Alpine instruments and composed by Christof Dienz.
A story-based single player campaign told without words.
At least 4 different multiplayer game modes, some of them asymmetricand specifically built around the unique features of the Wii U™ GamePad.
To make it easier for journalists to find everything they need to know about us, we’ve created a sexy press kit*.
Here’s the press release in full:
Chasing Aurora to launch on Wii U™
VIENNA, Austria – May 31, 2012 – Broken Rules announced the Nintendo Wii U™ eShop as the official launch platform of their game Chasing Aurora today. This highly anticipated indie game is scheduled to be released in late 2012. Chasing Aurora is an aerial action game that is set in the thin air of the Alps. It is a 2D open world action game featuring physics-based flight and air combat. The game has been nominated at the A MAZE Indie Games Award 2012 and was first shown to the public at LunarCade Shanghai.
Confirmed key features of the game include:
- Unique physics-based flight inspired by the age-old dream of human aviation.
- A fresh and mysterious world to explore.
- Outstanding 2D vector- and pixel-based art style right in the middle between origami and pop-up book.
- Challenging creature AI and spectacular physics- and frame-based animation.
- Original soundtrack performed on Alpine instruments and composed by Christof Dienz.
- A story-based single player campaign told without words.
- At least 4 different multiplayer game modes, some of them asymmetricand specifically built around the unique features of the Wii U™ GamePad.
More features, other platforms and new killer content will be announced once they are developed far enough to talk about them. There is no ESRB rating yet. Stay up to date by following @BrokenRules and @Chasing_Aurora on Twitter.
The press kit containing text, images and video may be downloaded using the following link:
About Broken Rules
Broken Rules is an independent game studio based in Vienna, Austria. Broken Rules makes downloadable games with refined game mechanics. The studio’s first release, And Yet It Moves, was a commercial and critical success. The title went on to win awards in game design competitions (Student Showcase winner at Independent Games Festival 2007, Nominee at IndieCade 2008) and garner industry-wide recognition, which led the team to expand the property to the Wii. The WiiWare release of the game currently ranks up 83% on Metacritic.
To learn more about Broken Rules, visit http://brokenrul.es/presskit
Nintendo trademarks used under license.
* Thanks to Vlambeer for their awesome presskit() scripts.
Sorry – we didn’t have the time to post a friday update this time around. And now it’s already Saturday. We’re crunching hard to get the single player content from being playable to being fun. We’ve scheduled a game test with a select group of players on Monday. They’ll visit us in the office and we’ll video-tape them while they explore the game. Follow Chasing Aurora on Twitter if you want to learn how the game testing goes.
And Yet It Moves 1.2.2 was just released on Steam and the Mac App Store. To celebrate the update we’ve also put the game on sale. You can get And Yet It Moves for $2.49 (-75%) on Steam and for $2.99 (-70%) on the Mac App Store for the next days.
This build includes a host of new content and brings the game on par with the WiiWare version. We’ve added three mind-fuckingly hard bonus levels, three new game modes and a ton of new achievements. If you’ve got the Humble Indie Bundle-version of And Yet It Moves you’ve got most of these features already – but now you got them in your Steam version, too. Of course we’ve also fixed a number of bugs and compatibility issues. If you got any trouble running the game, please tell us in the new forums.
Here’s the full Changelog of the most recent versions:
1.1.6 - rev. 5583 - 2011-05-31
Japanese localization updated
Correct list of doable achievements in the demo version
1.1.7 - rev. 5605 - 2011-06-22
Steam Summer Achievement: Bat-Wetter
1.2.0 - rev. 5590 - 2011-06-10
3 NEW PLAYMODES: Time Trial, Limited Rotation and Survival
12 NEW ACHIEVEMENTS
3 NEW LEVELS: find them in the Epilog Chapter after you played
through the credits
Improved linux compatibility
Fixed startup GLX errors
Improved 64 bit version
1.2.2 - rev. 5631 - 2011-11-18
No more Mac PPC support
Improved game compatibility
Indicating loading state in menu
Added MS visual studio redistributables for better compatibility
We’re a small indie company of six. Four programmer/designer hybrids, though each of them proficient in other areas too, one artist/designer and one community manager/marketing/designer. Only half of us have ever worked in other game companies and only one of us has ever contributed to a AAA game (though uncredited). We have no strong ego running the business, but a very collaborative atmosphere. That’s why we need a clear methodology for working efficiently. We have a rigid structure for our creative process in order to live the freedom that it gives. The system we’re using is loosely based on scrum but finely tuned to our situation. I don’t believe in off-the-shelf design methods. So we tailored our own. Here’s how we scrum.
We usually work in one or two week sprints. It has been seen that we’e been doing three week sprints, too, but those were rare. We use Basecamp for the detail-work, i.e. todo lists and discussions. We use Skype for immediate communication. The scrum is a tool for on-site face-to-face collaboration and that’s why we do it on paper. We scrum on Monday, Tuesday and Thursday. Our core period is from 11am to 3pm. You’re supposed to be on-site during that hours. If you can’t make it to the office, you must be available on Skype during that time. The scrum is shortly after 11am, usually around 11:30am, once everyone is in the office or online. We try to timebox it to 15 minutes, but sometimes we fail.
We have no roles in our scrum because otherwise half of the team would have a role which somehow contradicts agility. We know that this will change once we’re a larger team, but for our current situation, the most important factor is honesty. And if you’re playing the “Product Owner” when you’re in fact the engine programmer, your honesty is severely compromised right from the start. We don’t play games, we make them.
Our scrum board has the following layout. There’s the “Future” box on the left. Unassigned and miscellaneous future tasks can be put into that box all the time. They are to be considered in the next sprint. Then there are three bars titled “Todo”, “In Progress” and “Check”. On the right, there are two boxes, “Done” and “Backlog”. An item is introduced in the “Future” box. During the planning of the next sprint, the tasks’ post-its are moved from “Future” to “Todo”. Also, one ore more people are assigned to the task, one of them officially responsible for the completion. Those are written on the post-it, too. If a task loops over the whole scrum board several times we talk about why that happens and either drop it or reframe it so that it can be completed. During the scrum meeting, each team member picks the task he’s going to work on for the next one or two days and moves the post-it from “Todo” to “In Progress”. He also moves all accomplished tasks from “In Progress” to either “Done” or “Check”. Tasks that are to be checked should be tested by a different team member before they are considered “Done”. If the task could not be completed and gets postponed to the next sprint, the team member puts it in the “Backlog” box. Additionally, there are “Mail Pending” post-its that signify an external dependency. Sometimes you can’t proceed because you’re waiting for a phone-call or email. Other dependencies are modeled using different post-it colors for the tasks. Red means either that the task is very important or that a yellow task depends on its completion. Green is one hierarchy level lower than yellow.
We’re currently quite happy with our custom-tailored scrum (or is it even scrum-ban; I’d say so). But there have been times when things didn’t work so smooth. We had one person responsible for the scrum meeting for some time who was not interested in that particular position at all. He did the job but the scrum really started to show its strength as a productivity tool once we’ve made our whole development dependent on it instead of having one guy reminding us that it is time for the scrum. Put bluntly, it’s necessary that the scrum feels necessary for everybody. We’ve also experimented with estimating the hours we have to put into a task and writing them down on the post-its in order to get a better feeling on the amount of tasks we can put into a sprint. That worked but always felt awkward to me personally. Currently we’re not pursuing this route anymore. In my opinion it is much more valuable to have flexibility than predictability. In other words: Postponed tasks and tasks that explode into hour-eating martyrdoms are problematic cases. Keeping an eye out for those is really important. We might experiment with a more abstract system of estimating the workload of a task in the future.
This is how we scrum. As usual, we’ve broken a lot of rules. I’m not writing this because I want you to copy our methods. I’m fairly certain you can ruin a project by doing that. All I want to tell you is that it is a good thing to tailor your production methods to your own needs. How do you scrum?
Last week I’ve written about OpenGL GUIs and gave you an overview of what’s out there. Right after finishing my posting I decided to integrate Gwen into our engine. Why Gwen? It is sleek, highly configurable, stable, well maintained, and close to production-ready out of the box. It does not throw exceptions and relies on simple data structures (if you consider STL as simple). It is quite well written and the code is easy to understand. And, yes, there is code to read. The library is open source and comes with an MIT license attached. Actually there are only two downsides: Gwen is not an immediate mode GUI and I would have loved to check that new paradigm out and Gwen uses dynamic_cast and thus requires RTTI. I’ll try to iron that out later on and will post my progress here. This time I’ll focus on how you hook up Gwen with your tech by telling you about how I hooked her up with *my* tech. There’s one more downside to Gwen: There’s hardly any documentation.
This post is part one of a short series of posts about my progress in searching a viable GUI solution for our in-game/live editor. It is live coverage of my research and implementation. I welcome any and all feedback.
We’ve integrated live-editing into Ginkgo some time ago by hooking up our component system and AntTweakBar. Now that the system has outgrown what AntTweakBar has on offer, I’ve started the epic quest of finding a suitable OpenGL-based GUI solution. Our requirements are straight-forward:
Platform independence (i.e. Windows, OSX, possibly Linux and maybe even iOS)
Either scriptable or easy to abstract
Copy&paste and Undo supported, or easy to add
I’ve spent the last two months on and off evaluating GUI libraries and toolkits in order to find the perfect one. Sadly, all of them have proven to have their downsides. Let me summarize what I’ve found out so far.
All content (C) Broken Rules GmbH 2009-2012, unless otherwise noted.
Where not otherwise specified, this work is licensed under a Creative Commons License permitting non-commercial sharing with attribution.
Powered by WordPress using a custom theme based on Renegade