The core team:
- Mauricio Garcia: project management, production issues, and logic programming
- Carlos Lopez: technology programming
- Juan San Miguel: logic programming
- Emilio Joyera: game design, puzzle design, writting, scripting, and some art
- Enrique Cabeza: game design, interface art, adventure art
- Alvaro Rico: character design
- Carlos Viola: music composer
- Juan Miguel Lopez: 3D modelling and texturing
- Fern?ndo Rom?n (Sonogames): Audio FX design
- Alexander Guillen: Digital Painting
- Logic-Lingo: English localization
"Rotor'scope - The Secret of the Endless Energy" is an addictive and challenging puzzle game in which the player's intelligence, logic and spatial perception are put to test.
The game features a never seen before rotatory mechanism, in which the player will have to activate lots of different block types to solve each puzzle, and progress in a fantastic Sci-Fi adventure. The players will enjoy more than 150 puzzles, an easy to use puzzle editor to create their own puzzles, the ability to share them on Xbox Live and to compete with other players for the best solutions.
We wanted to create a puzzle game with an easy control. It was inspired on the new motion controllers which appeared some years ago; the most easy set of moves we thought were "turn left", "turn right" and "turn over". After thinking and evaluating some ideas about which way we could use these moves to play a puzzle game, the final concept came up. A series of closed puzzles showing a different challenge each time, in which the player only can turn the piece container. The gravity does the rest.
Of course, this idea was quite simple on his own. More variety was needed, so special blocks (bombs, metallics, beams, hyperexplosions, surprises....) were added. Also, some restriction rules were inserted to make puzzles more challenging to the player.
About the steampunk inspiration, it was chosen on the early stages of development, when we were deciding the ambient of the game, and how the screen menus should look. Enrique showed us some designs, and one of those looked as an ancient plane with some gears like Leonardo Da Vinci's drawings. That concept art made us think of a steampunk-clockworks world, in which a complex machine made of gears would present the puzzle to the players.
When we decided to add a story to the game some ideas were put on the table. Most of them had only one main character. The exception was one which talked about two people trying to solve a mystery. Finally we decided to use it, the story of Traveller, Julie and Anythree (the time machine), which is strongly inspired on the Doctor Who's adventures, but taking place in a steampunk universe. There's even a joke about that in one of the dialogs. In the analogy Traveller is, as The Doctor, someone clever, impulsive, even eccentric... He also has inherited a little bit of the personality of our game designer. And on the other hand, Julie has the role of the "Traveller's assistant", much like The Doctor's companion.
We are a group of game enthusiasts, a combination of established and aspiring professional game developers. Some of us used to be, or are currently working for game companies in Spain. The rest are IT professionals eager to switch to the game industry.
So, I'd say that although it started like a hobby, the final goal was becoming an Independent studio since the very beginning.
I've liked video games for as long as I can remember. This hobby grew stronger and stronger with time, and the will to play games transformed into a will to participate in their creation. Working as a graphic designer, I had the chance to meet Mauricio, and started working with him in what later became our first game: "XtremeTableSoccer", which we entered in DreamBuildPlay 2007 competition. Currently, although I still work as a graphic designer for an IT company, I dream of creating great games with Nivel21 for a living!
Since I was young, my passion is creating music and playing instruments. I taught myself to play each instrument I got my hands in: guitar, bass, piano, drums, violla and cello. Some years ago, I started using computers to create music, and since then I've been putting up my own home studio, and never stopped improving my composing skills. Currently, not only I work for Nivel21 as a core team member, but also collaborate with many other Indie studios. I make my music available in my website so anyone can freely enjoy it. I'm also known as a recurrent contributor to "Frets-on-fire" (a free, and very popular open-source guitar playing music game for the PC).
Emilio Jos? L. Joyera:
I am a game enthusiast since I was 15. When I made myself with my first computer at 17 I wanted to create games. I learned to program on my own, making some little games and prototypes in my spare time, always trying to create some new stories, mechanics and concepts I never seen in others games. During this time I learned graphic design (2d an 3d), programming in some languages (C++, C#, Java, Visual Basic) and the use of some game libraries such as Allegro and XNA. I had been working alone until I joined Nivel21 Entertainment in 2008 as a game designer to create Rotor'scope and other games in the future.
I had my first computer when I was really young, at the age of 6 if I recall correctly. It was an MSX microcomputer. My first programming experiences where copying endless pages of code from the manual into the computer. For me coding quickly became more entertaining than playing games, so I never stopped programming for fun since then. Years later I got my hands on my first PC, and with it I started developing a serious interest in graphic programming. When I finished my studies, I started working as a programmer in an IT company. Here is where I first knew about .NET technologies, and had the chance to work with them on a daily basis. The arrival of XNA technology occurred in a very crucial moment of my life, in which I was considering switching from the IT world to the videogame industry. XNA gave me the chance to develop great game creation skills, and thanks to that my dream of working as a professional game programmer became true.
Carlos L?pez Men?ndez:
Since I was a kid I was interested in computer programming. I studied computer engineering and started working in the University of Oviedo in several research projects on Computer Vision and Real Time Systems. I have always been a game enthusiast, so in my free time I started programming my own games and learning about graphic engines and other technologies. Until one day I decided to try to start a career as a game programmer and moved to Barcelona to attend a Master Degree on Game Programming. When I finished the Master I moved to Madrid and started working in Pyro Studios (known for the Commandos saga). There I met Mauricio and Juan, and after the game in which we were working was cancelled we decided to try to make our own games. Now I'm working in another game studio (Freedom Factory) and I combine this job with my work in Nivel21.
Juan San Miguel:
Ever since my childhood I've been a compulsive videogame consumer. I started programming at high school and then I chose to study a degree in Computing Engineering. After that I surprisingly took a Master Degree on Videogame Programming in UCM, Madrid. As my first job I spent 3 years and a half working for Pyro Studios. And now I'm working in Thinkia Entertainment. In the end, my time passes between consuming and producing videogames, such as Rotor'scope.
?lvaro Rico Soto:
Since I was a child I've always dreamt about making games. Every time I could I did drawings, map designs and programs in order to reach my dream. One day I won a contest and that started everything. Today I am working in Digital Legends as a Game Designer and I am finally happy!
It's awesome, a sort of a dream come true. We were amazed by the quality of many of the other participant's games, so although we were very happy with our own game, it was like... "Oh, man, look at this incredible games, no way we're getting to the finals!". So in the end, we couldn't believe it when we finally found out our game was in the top games.
We are also excited about the great new opportunities the contest will bring us, like a bigger media coverage for our game, or even the chance of signing a deal for distributing the game in Xbox Live Arcade.
The entire team put a great amount of effort and care in the development of the game. Everyone was really committed to create a great game, a game that could kickstart Nivel21 as a professional independent studio. We know that putting up a new video game company is a very hard task, especially for individuals that have no resources at all, except for their own talents. Now, thanks to Dream Build Play, we are more confident about setting up our company. Thanks to this awesome contest, we expect our game to have a greater presence on the media, as well as other opportunities we couldn't have dreamed of before.
I'd like to thank Microsoft, and the XNA team, on behalf of the entire team behind "Rotor'scope - The secret of the endless energy", for providing us with such a great technology, and great opportunities.
We entered a game to Dream Build Play 2007 (the first edition of the contest). It was a foosball simulator, called "XtremeTableSoccer" (a video of the game can be found here). Although the game was visually appealing, the physics-driven gameplay made it really hard to play, and in the end it wasn't as funny as it should be.
After having no luck in the Dream Build Play contest, we entered the game in the national ArtFutura GameDev contest, in which we obtained the Special Jury Prize.
Even though we ended discarding to continue developing this game for the reasons before mentioned, the experience of creating our first playable console videogame make our desire and commitment to create our own Indie studio, even stronger.
The key difference in our recent project has been paying special attention to an early prototyping stage. This time, we focused on having a mature and fun gameplay before including all the art, sounds, and writing. To make sure the game was fun, we ran lots of user test with friends and family. We successfully detected and fixed all kind of issues regarding gameplay, and the core concept of the game. Once all that was put in place, we added the story to the game, the art, music and sound.
Opportunities! The obvious chance of getting some fresh cash to support your development, is just the beginning. I think the key benefit is the awareness of your game in the press, gaming communities, and even in the Indie Games section of the Xbox360 dashboard. Not to mention the chance of signing a publishing deal with a top publisher, which is a dream for any aspiring Indie game developer company or team.
The rotatory puzzle concept was an original idea of the lead designer, Emilio Joyera. He wrote the first prototype and the level editor entirely on his own. Then approached the rest of the team, and we decided a strategy to turn the prototype into a complete game. Our primary objective was to determine the scope of the game correctly; to make sure the finished game would be well finished and polished by the Dream Build Play contest deadline.
An overview of the project would be the following:
- A stand alone game engine was created, to keep all the tech-stuff conveniently separated from game logic. The engine used for our previous XNA game was used as a start point, and we decided to release it for public use as open-source, under the name of "Tomahawk XNA Game Engine".
- A new prototype of the puzzle was created, this time using the new engine. This prototype had the objective of testing which mechanics were fun, and which weren't.
- Once the engine and the new prototype were in place, we discovered that a "story component" would be necessary to keep the player interested in playing the game, puzzle after puzzle. So a new prototype was started for the adventure mode mechanics. Once the basic features were working, we created the tool that allowed us to easily create the maps for this new gameplay mode.
- Once the adventure mode was ready, and all the essential mechanics were working, we began writing the actual story script. We needed a story that could be successfully narrated with the simple mechanics we had available in the adventure map.
- When we had both the adventure mode and the puzzles working, we started production of the final art and assets. Until that point, all models, textures and audio used in the game were "placeholders", many of them were even created by the programmers themselves.
- While the final art was being created and added to the game, the additional features were created by the programmers: the puzzle editor, content exchange via Xbox Live, etc.
- Also at this point, we decided we would need to acquire external services in order to deliver the best polished game possible. We had a very low budget for this project (close to zero, indeed) but we were really fond of the project so we decided to give away some money from our pockets. Luckily we could hire the services of some of our friends in the industry, and in the end they added a really impressive value to our game: the amazing digital paintings of the adventure mode, impressive FX audio design, and the excellent English localization of the dialogs were added this way.
- Two months before the deadline, we started running lots of user tests to determine which things needed improvement. Lots of small features and fixes were added thanks to the valuable feedback they gave: help screens, navigation consistency on screens, small parts of the script were rewritten, etc.
- Finally in the last month, we added the last stages and puzzles of the adventure mode, added the extra features (medals and collectible items), but mostly we spent all the time playing the game over and over again, and making fixes and improvements here and there.
Yes and no, I mean we managed to fit in all the features that we had planned for the game. We even included a few ones that weren't planned at all. When somebody had a great idea, and it wasn't too hard to implement, it was approved and added to the planning. But in the end, we came with so many good ideas that we had to start rejecting them because of time restrictions.
Also some other ideas that we actually implemented were later removed, mostly because of design reasons. For instance there were like 6 types of blocks that didn't make it into the final game, because they were adding too much complexity but not enough enjoyment to the game.
I can say we are very happy about how the project has progressed, from its early stages to the end. We have used an adaptation of a methodology called Scrum, which consists of cutting down the entire development cycle into smaller (1 month long) cycles. Each of those cycles are called "sprints" and are treated like full cycles: first we decide what is going to be done during the month, then we actually do it, and finally everything is tested and showed to the entire team. The goal is to divide the pressure one might expect at the end of a huge project, into smaller pressure sprints at the end of each month. Also a benefit of this iterative procedure is that you get a stable and fully playable version at the end of each month, which you have the ability to evaluate in search for the weaker features, to improve them in the next cycle.
Using this methodology we also kept a high morale on the team during the whole process, as it gives you the opportunity to clearly see the improvements compared to previous month. This way the team is always aware of the progress of the game, which keeps everyone motivated and happy.
The only critical problem we faced during the development was the departure of one of the core members. He wasn't as committed with the project as the rest of the team, so in the end he had to leave. It's hard to face this kind of situations in small teams where all the members are friends as well as co-workers. The entire team, as well as myself, considered it was mandatory to let this person go, and explore another options to cover the task he left unfinished.
We were lucky to find someone we could afford to hire, an excellent artist that created the digital paintings we needed for the adventure mode.
Personally I've been playing with XNA since its initial release. Most of the team members were familiar to this technology, because of our first XNA game "XtremeTableSoccer", entered in the Dream Build Play 2007 competition.
That was our first game ever, and we learned all the basic techniques of game creation during its development. Also, the source code of this game was later used as the base of our new engine, called "Tomahawk". Having this as a working code base, allowed us to rapidly create a playable prototype of the new game.
The first time we approached XNA as a game technology we did it mostly because of its ability to run code on a major game console, the Xbox360. That was attractive enough for us to give XNA a try. Once we saw how cool was writing games for your home console, Microsoft announced the first edition of the DreamBuildPlay contest, and we knew that we had to participate.
I must admit that when we finished "XtremeTableSoccer" we were not very happy with the fact that almost nobody could ever play our recently created game, because in those days the only way to play a XNA game was being part of the Creators Club. That made us reconsider XNA as a technology for our future developments, but only a couple of month later, Microsoft finally dropped the Community Games bomb, the democratizing of game creation and publishing. Once again, the decision was easy: now the perfect technology met the ideal distribution channel!
We went back to XNA technology with more passion and commitment than ever before!
I'd like to mention that for "Rotor'scope", two of the programmer had no previous experience with XNA and C#. I was amazed by how fast they were producing quality code for the game, they had virtually no problems going from absolute beginners to experts, thanks to the great documentation, the huge sample library available in Creators Club, and other exceptional resources one could easily find in the Internet.
I started working with XNA when it was first released, and there were only few resources about it in the net. So I started experimenting with it on my own. With the help of the excellent documentation included, I started building things and playing around with basic concepts for a while. The XNA user community started growing rapidly and lots of resources became available everywhere. I read lots and lots of articles about different techniques. I found especially interesting those you can find in Ziggyware, and of course, those written by Shawn Hargreaves and Catalin Zima. I also began to check the Creators Club forums on a daily basis, where I always found somebody willing to help me out.
Making a game is a complex process in which you have to face wave after wave of problems. Given that, and towards the consecution of your goals (for instance, finishing your game), I would recommend anyone to use as much help as possible from pre-existing working pieces of code. I know developers who radically apply the politics of "do it yourself" and they commonly pay the consequences: all the efforts you spend in reinventing the wheel won't be spent in making your game fun to play.
By the time we started developing our game, there was no XNA engine available that suited our needs. We did a large research before hitting that conclusion. So we decided to create our own engine, with the features we would need for the game. As there was no engine like the one we were creating, we decided that our engine would be freely available as opensource, this way other teams would be able to build their games easily using it.
Although no complete engine was available as a base, we could find lots of useful components that we ended using. Most of them were used as an inspiration to build our own versions. Others were heavily adapted, and a few could be easily added out-of-the-box to our engine.
Here are some of the components we added to the engine, not all of them being actually used by our game:
- JiglibX physics library
- XMAS animation system, by Jose Arias
- StorageDeviceManager, by XNAWiki
- C# ZLib compression library
- OnScreenKeybord component
- ParticleSystem Component based on the examples found on XNA Creators
- Some other utilities and code samples we found on Codeplex, such as an onscreen console command.
Our engine was openly developed since the beginning. It's called "Tomahawk XNA Game Engine", and can be freely downloaded from here. It's published under the terms of the New BSD open-source licence. We are currently working on a better documented, stable, and easy to use "version 1.0" of the engine, which will be ready probably by the end of September.
We also came up with an innovative idea for "Rotor'scope - The secret of the endless energy" that will allow players to publish their game score in Facebook. We believe this kind of integration could improve the awareness of not only our game but many other Indie Games as well. We are releasing a generalized, easily adaptable version of this feature, called "IndieFb". This way, any Creator Club member willing to improve the awareness of his games could use this solution to take some advantage of this popular social network. The project is still in an early stage and a release date has not been decided.
More details about these and other projects can be found in our website: http://www.nivel21.net
There are lots of features of XNA technologies that we actually find interesting. First, is the great similarities between PC and Xbox360 targets. Although some restrictions and special rules apply for the console, most parts of your code will run just fine there, as well as they do on the PC. Also, the documentation included with XNA Game Studio is excellent, and really helpful.
In the end, but no less, is worth to mention that all these tools are totally free, you don't need to pay a penny to access these great tools, and create your own games!
While creating the game, we discovered that not all the things available in the console were present in the PC. Some of them are emulated for debugging purposes, but not available when compiling a PC Release build. When we planned our user tests sessions, we discovered that our testers weren't able to run the game on the PC for these reasons. To overcome this situation we created a detailed manual to explain them how to install all the tools required to run the game. We noticed that many of our testers lost all interest in testing the game because of these requirements.
For the next testing sessions, we enabled a completely disconnected mode that will not make use of GamerServicesComponent at all. This way we were able to compile a PC Release version that would be much easier to run on non developer machines. To achieve this, we had to add components to replace some of the Guide services we were using, like text input or storage devices. The final test sessions were made in the actual console, so only Creator Club members could participate.
Our game includes a level editor. We really wanted to give the players the ability to exchange levels with other players. As Indie Games doesn't support server side Xbox Live features like scoreboards, achievements, etc., initially there was no way to achieve this feature. We thought about possible workarounds, and created a prototype of a background content exchange service, that worked using multiplayer network services. Once we got it working, we added it to the game. This way, while you are playing, the game is continuously creating and joining multiplayer sessions, which are used to exchange contents like user created puzzles and puzzle solutions from other players. If a player enables this service in the options menu, every once in a while he'll see a notification message about new content becoming available.
One of the biggest technical problems we had while creating the game, was the performance of XML serialization on the Xbox360. Our engine makes a heavy use of Xml, so when we put together all the pieces of the game we found that the loading times were terrible because of this. We studied the problem, and determined it was "Reflection" that was causing our problems. We came up with a complete replacement for XmlSerialize that run 10x faster, by not using "Reflection" at runtime. This new mechanism is called "SerialBoost" and it's available as a part of the "Tomahawk" engine.
We started using 3.0 and then moved to 3.1 as soon as it became available. The migration to 3.1 was smooth, and painless. Kudos to the XNA Team for the great migration tool included.
We knew about the new features included in version 3.1, some time before they were available, and we decided to only take advantage of the video support. Our game concept leaves no room for a clever use of Avatars, so we left that for our next game.
First, be clever deciding the scope of your game. Forget about FPS or RPG genres until you have successfully completed a good puzzle or arcade game. Creating a good game takes a lot of time, and the complexity increases exponentially depending of the scope. Going for a smaller scoped game, will result in more chances of getting it done.
Also regarding the scope, decide the game you are going to make taking care of the roles you have in your team. For instance, don't make a game that requires lots of animations if you don't have an experienced animator in your team. Also a 3D game will require more specialized artists than a 2D one. Be "pessimistic" when evaluating the amount of work that a single individual can achieve: it's better to finish a simple game, than to abandon an ambitious game half way done.
Then, pay special attention to the early prototyping stage. Don't put any final art into the game until you have a solid playable and, most importantly, fun-to-play base.
And finally, designate a project manager for your project, and take advantage of project management tools: version control, tickets, wiki for documentation, etc. There are many tools you can download for free to help you manage your projects. There are also companies that will offer all these services in an integrated fashion, for instance we are using Assembla, which is both cheap (cost less than a regular web hosting) and powerful.
Absolutely. We have some innovative ideas we'd love to start working on very soon.
We probably will. We always found both funny and rewarding to participate in development contest like this one. The competitive factor pushes you to give your best for your entry, and also, you watch how the rest of participants do the same. That is enough reward to justify participating. Then you add the amazing prizes and opportunities that Microsoft gives for their contestants, and it becomes a must.
We are currently focusing on releasing the game on Indie Games. We still have to complete both Playtest and Peer-review processes. In the meantime, we are working on releasing the first fully documented, ready to use, version of our open-source engine, "Tomahawk".
We are working on "IndieFb" too, our template Facebook application for Indie Games creators.
We have a couple of ideas too for the next game titles, and we will be evaluating them soon.
"Rotor'scope - The secret of the endless Energy" will be the first title we are publishing in Indie Games portal. We are really looking forward to see how well our game does in this new channel. This first experience will be useful to determine if Indie Games portal will still work for us in the future, although for now nothing indicates the opposite. Having such a huge base of potential players for our game is really appealing to continue working on Indie Games titles, not to mention the power of the Xbox360 console itself. We are also considering expanding into other platforms for an even greater potential player base, but I believe no other platform is as accessible and appealing as Indie Games.
Creating "Rotor'scope - The secret of the endless energy" has been a great experience. We are really excited about letting the game out in the wild, and watch how the player community will react about it.
We really want to thank Microsoft and the XNA Team once again, for creating such amazing technologies and giving people like us the opportunity to create the videogames they'd like to play.