main

ContributionsDevelopmentGame DevelopmentIndieOnlinePostmortem

Somyeol: Going HD and Making an Engine Together with a Game

August 6, 2014 — by Industry Contributions

Brain Connected is a German-based independent game developer studio founded in 2011 by Jannik Waschkau and Kolja Lubitz making games for mobile, TV, and PC platforms. Both being programmers and not good in creating art, they are currently looking for an artist to join the team, and telling how they managed to get to the point where they are now with their game Somyeol.


Everything started at the Global Game Jam 2011 where we developed a prototype of a platformer game which would later become Somyeol. Before the Jam, we had hardly any experience in game development, with our only project being an unfinished racing game which we programmed for fun alongside our studies. We stopped working on it in favor of Somyeol.

An iOS App for $0.99 Because Everyone Else was Doing It

Somyeol was released in the end of 2011 as a paid app at a price of $0.99 for iOS, because a lot of other gaming apps were doing it. As we were, and probably still are, an unknown developer, we didn’t attract a lot of attention and hardly anyone was buying our game. Because of that, we came to the conclusion that we had to make our game free-to-play with in-app advertising to reach more audience. That went a lot better, and around two years later, we can say that we are very happy to have gathered more than 1 million downloads over all platforms with our first game. While not commercially viable, we have made a few bucks and gained tons of experience about game development.

screenshot_2013-10-02_21-51-06
Somyeol was first released as a paid app for iOS because everyone else was doing it

Somyeol HD: OUYA and Roku Because They’re Not Crowded

Somyeol was designed and optimized for pre-Retina iOS devices with little processing power. It runs perfectly fine on a device with only a 400 MHz single core CPU. The game is written in C++, which is a pretty fast programming language. The graphics have very low resolution, which looks fine on devices with resolutions up to 800×480.

icon_rest512
Due to low resolution, Somyeol graphics look fine on devices up to 800×480.

To change that, we let our external artist Carsten redraw all graphics in high resolution, changed our rendering code, and released a Somyeol HD version for Android. The HD version can be used on screens of all scales from small smartphones and up to 4K displays. To get Somyeol HD to these big screens, we first ported it to the Ouya, but it wasn’t accepted well there despite being featured in their store.

We first ported it to the Ouya, but it wasn’t accepted well there despite being featured in their store.

We are not sure what the reasons are, but one of them may be that it’s a single player game, while lots of the successful games on the Ouya have multiplayer and couch co-op components. Because the Ouya is just another Android device, we will probably release our future titles on it. Releasing a game does not take a lot more time than compiling an APK and uploading it to their store system. We only got 500 downloads and to date, we’ve sold around five copies of Somyeol HD.

screenshot_2013-10-02_22-19-26
We only got 500 downloads and to date, we’ve sold around five copies of Somyeol HD.

Before Christmas, we released on Roku because our middleware-added support for this platform, and it is not bad to be on as many platforms as possible. The only downside is that we can not access their in-app purchase API from C++, and that is why we’re not able to release a version where the first few levels are free to try.

It is not bad to be on as many platforms as possible.

Bringing the game to Roku was a seamless process, and they provided good support. They even sent us free devices to test our game on. There are not many games released for Roku, and so we do not have a lot of competition. Sales were a lot better than on the Ouya, and we are happy that we ported it over.

Try Available Engines, Eventually Make Your Own

Because we were building on top of the architecture from the Global Game Jam, Somyeol has not the prettiest code to read, let alone to enhance. Over the years, we were updating it with a lot of features which were not there in the initial design. Eventually, it got too time-consuming to maintain that code, so we decided to re-make our projects started long ago, transferring all new features into independent modules, which worked out pretty well. The big advantage is that the modules can be reused across all our games.

screenshot_2013-10-02_22-15-29
We decided to re-make the codes of our old projects, transferring all new features into independent modules.

For Somyeol HD, we also needed to implement a new renderer, since the resolution of the textures got a serious increase, which was also programmed as a module, and is now (slightly modified) used for our unnamed 2D game engine, which will power our next title and hopefully all of our future games. We now have 40 different modules which we can use across our games, and will hopefully save us a lot of development time in the future. Without the making of Somyeol, where we made a lot of bad decisions engine-wise, and which we could learn from, we wouldn’t have the knowledge to do this properly.

We now have 40 different modules which we can use across our games.
DSC_0099_bc
Kolja and Jannik: students working slowly but steadily.
Photo by Vlad Micu.

Starting with the development of our own game engine and our next title, we thought about features we will need for both. One of the most important ones is easy 2D content creation. After a little research, we stumbled across Spriter, which is a pretty interesting 2D animation tool allowing bone animation for 2D graphics. While the format Spriter produces is open source, there are no good examples of how to integrate Spriter into games, and we had to invest a lot of time to get it working properly. We are supporting all basic features of Spriter. Because every game needs collision detection, we also wanted to integrate a 2D physics engine to get these for free, and also the possibility to run physics simulation. For this reason, we tried to integrate Box2D which only took us a few hours to get working. Sadly, we noticed pretty fast that integration with Spriter would take too much time. So we had to ditch Box2D as our physics engine and instead wrote our own collision detection. The good thing is that we now have full control over internal workings of our collision system, which makes it a lot easier to integrate into the other engine parts. Missing physics simulation would be no problem, as we can always integrate Box2D at a later point should we need it.

Kolja and Jannik are still students, so they can only work on their projects part-time, and that is why they are making slow – but steady – progress. Most time, they are still working on the different modules of their game engine and want to get their first prototype, which will someday be Somyeol 2, ready in the next few months. Up until now, the plan worked out and they are confident to have a great foundation with their engine for Somyeol 2 and their future games.

 

ContributionsPostmortem

Travail – Learning That Every Game Needs Heart

September 20, 2013 — by Mariia Lototska

Grandendroit is a small indie team currently developing Travail, which was in the Indie Prize Showcase at Casual Connect USA 2013, and hopes to continue making games full-time. Eli Delventhal, Project Lead and Programmer, describes the experience of creating Travail.

Team
The Grandendroit team

Travail’s development has been erratic, arduous, and transformative. In many ways, it has closely mirrored my own life. As a kid, I didn’t really know who I was or who I wanted to be. For absolutely no reason whatsoever, I recall thinking I would become an architect. But eventually, and after much reflection, I realized I wasn’t interested in that at all. I grew out of that and into what I was meant to be: a game developer.

Start With an Escape

Travail began its life as a 48-hour game jam entry for Ludum Dare. The theme was “escape.” At that time, the game was called Death Boulder Jones, and was a throwback to Indiana Jones. The character ran through a temple getting money, all while avoiding a boulder that chased him.

Even though it was first created for that jam, Travail’s inception was, in reality, a year earlier. I first met Seth Robles, one of the artists on Travail, at the first Global Game Jam in 2009. We made a game together and hit it off. Afterwards, we started making more games on the side. Our first real attempt at finishing something was a game called Lab Rinth, which was about a super hero who made his way through a maze-like laboratory. It also had a lot of enemies who had to find their own ways around. At first, they were very intelligent about finding their way to the player, to the degree that it was frustrating and unrealistic. As a solution, I decided to make them stupider, where they would sort of walk and steer around until they saw something interesting.

It just so happens that shortly after making this change, the Ludum Dare “escape” game jam started. I noticed it was really fun to move the walls in real time while the enemies were in the middle of walking around, so I decided to explore that in a full game. This became Death Boulder Jones’ core mechanic of dragging walls to indirectly control a character and block traps.

After the jam, we realized we had a really cool and unique style of play on our hands, so we grew it up into a full game, now called Death Boulder Bones. Just like I once wanted to be an architect, DBB wanted to just be a silly runner with no story. We had the gameplay, and that’s all you need, right? We figured we were just a few months from releasing. But then we were forced to think about what was really important, and everything changed.

We had a really cool and unique style of play on our hands. which crossed over when creating Travail
We had a really cool and unique style of play on our hands, which crossed over when creating Travail.

The People Have Spoken

Because we thought it would be fun, we decided to sign up for IGN’s The Next Game Boss, a show where different game developers compete. Everyone came with an in-progress game and essentially were judged on what was the best. We brought in Death Boulder Bones, which I described as a game “about a nearsighted guy who just wants to get some money, and is protected by a spirit.”

The judges were very into our gameplay. They had fun, they laughed at our silliness and my terrible voice acting, and they generally gave us positive feedback. Eventually, we finished in third place, to two games that were much more polished than our own, with lots of heart and story. Although we didn’t win, I left the show feeling pretty great, because I had confirmation from some amazing game people (David Jaffe, Jenova Chen, Lisa Foiles) that I had something special.

I had confirmation from some amazing game people that I had something special...but then I started to read Youtube comments.
I had confirmation from some amazing game people that I had something special…but then I started to read Youtube comments.

But then I started to read YouTube comments.

What got to me was not the very rude and off-base things that you are bound to expect on YouTube; rather it was that practically everyone thought that another, much more boring game should have beaten us, and that our game was just a ripoff of Temple Run. Had they actually gone hands-on with the game, they would have seen that both opinions were very wrong. But, they hadn’t played the game. And they wouldn’t.

Riding on the viewership for The Next Game Boss, we decided to try a Kickstarter. We asked for a paltry $28,000, which may seem like a lot, but is an absolute pittance for developing a game. I thought it was a safe amount of money, especially when episodes were getting at least 30,000 views. Kickstarter even featured us, putting us on the front of the games page. But, after 30 days, we raised less than 10 percent of what we asked for, and much of that money was from friends and relatives.

Here we were, with amazing feedback from some of the biggest voices in the industry, and yet nobody seemed interested or excited by our game.

So what the hell was up with that? Here we were, with amazing feedback from some of the biggest voices in the industry, and yet nobody seemed interested or excited by our game. That forced me to look inward, just like I did as a kid when I really thought about what it meant to be an architect.

My realization? Death Boulder Bones was a stupid game, and I didn’t care about it.

Now It’s Personal

That was quite a revelation for me. I thought the gameplay was fun, and I wanted to make some money and get a game out there. But I was spending hundreds or thousands of hours making this thing that I didn’t really care so much about. Once I knew that, I knew that everything had to change. I had to put myself into this game, and make it speak towards something meaningful to me.

I spent at least a month in creative limbo. What could I do to the game we had to make me feel something towards it? Was it really worth it to throw out so much of a game that had just been shown to thousands? Then, suddenly, the vision came to me, and Death Boulder Bones grew up and became Travail.

Travail is the story of an artist who is trying to create a comic book series. He works full-time to pay the bills, and goes just a little bit crazy staying up all night to make his comics. He doubts that he has talent, he doubts that his story is good, and yet he unhealthily continues it. He does so because he has to – the creative spirit in him won’t be ignored.

The creative spirit won’t be ignored.
The creative spirit won’t be ignored.

Really, it’s a story about me. It’s about how I feel making Travail at nights and on the train and when I should probably be doing other things. Why can’t I just drop it? I’m not sure, but for some reason I need to make it.

I also want Travail to be a mirror for everyone else who tries to create things. I want them to play it and feel that somebody finally made a game about their life, too. And I want them to have fun while they do it. Maybe then, the next time they make a game or a work of art, they’ll make sure to put their heart and soul into it as well.

Travail is scheduled to release this winter for Mac, PC, Linux, iOS, and Android.

ContributionsPostmortem

The Global Game Jam and beyond: FYI (2011)

February 20, 2013 — by Bart Eijk

The “Global Game Jam and beyond” series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advice on their attempt to turn their Global Game Jam project into a full-fledged commercial product.

The Global Game Jam version of FYI was developed by the Dutch game studio Digital Dreams and two friends of the studio. The concept of the game is based on infographics. Every action by the player results in changing bars and pie graphs, which make up the game world. After the Game Jam, FYI won the Independent Propeller Award for Best Design. The game has grown a lot since the team decided to continue development. Digital Dreams plans on releasing FYI to the public and is currently talking to publishers.

We were able to go just a little bit further with our game than the average Game Jam game

What triggered your initial consideration that your game was worth continuing with?
It felt right. From a gameplay point of view, the concept just felt right. Besides that, we had been able to reuse a lot of the code from previous projects at the Game Jam, so the prototype was already fairly complete as far as Game Jam standards go. We were lucky that our main programmer had recently worked on a similar game in terms of camera, physics and collision. Because of this we were able to go just a little bit further with our game than the average Game Jam game.

What do you believe was the main element of your game that allowed it to be commercially viable?
Even though it’s probably cliché and a common answer, we believe the uniqueness of the gameplay and the aesthetics makes FYI commercially viable. The gameplay is unfortunately really hard to explain in pictures and words, it’s something you should play for yourself in order to understand the concept completely. As far as aesthetics go, we use infographics as a visual style, which makes it stand out as well. This was also the main inspiration for the concept.

A screenshot of an early prototype of the game, showing the use of infographics in the game’s level design
A screenshot of an early prototype of the game, showing the use of infographics in the game’s level design
The biggest realization of the team members from the company was that we could produce so much in so little time

How did you manage the aftermath in your team?
Four out of six persons from the Game Jam team were already part of Digital Dreams. The biggest realization of the team members from the company was that we could produce so much in so little time. That’s why Digital Dreams decided to switch to developing smaller projects after the GGJ. That was a valuable lesson.

Another valuable lesson was about handling the IP. We talked to the other 2 GGJ team members and discussed our intent to possibly continue working on the GGJ prototype. In hindsight, this wasn’t enough. We should have done more than just talking. It’s never a bad thing to have things like this in black and white to avoid problems later on, especially before any money comes into play.

It made sense for us to continue as a company, because we really wanted full dedication and commitment. Basically we wanted to invest a lot of time, which is hard to achieve when working together part-time with people that have lots of other stuff to do. We also knew from the start we were taking a huge risk as Digital Dreams by investing our resources into this rough prototype, because we didn’t have the slightest idea if it would pay off some day. We really started to believe in its commercial viability after we won the Indie Propeller Award for Best Design.

What were the most important experiences/learned lessons and/or challenges that you had while further developing your game?
We knew the project would take around a year, making it the largest project to date for Digital Dreams. We did not have the money to do that. Selling the game to a publisher was the follow-up challenge. But it is great to get experience in this important aspect of the game industry, and learn how to pitch to other parties. It took quite a while before we convinced a party to actually invest in us though. This is one of the hardest things to achieve as a new start-up.

A second important experience was the difficult but necessary choice of engine. We considered quite a few engines to support the game. Unfortunately we can’t say much more about this without giving away too much at this point.
A second important experience was the difficult but necessary choice of engine. We considered quite a few engines to support the game. Unfortunately we can’t say much more about this without giving away too much at this point.

In your case, what did you learn from getting the game out to the public?
Well, the game isn’t public yet. But when we showed co-developers, other friends and publishers one of the prototypes we made, we saw how hungry they were for more. You just know you have something worth spending your time and effort on when people want more. This sure gave us confidence to continue development on FYI.

If you think you want to continue work on a GGJ prototype, it’s a smart move […] to know all the team members

What kind of tips would you give to other GGJ participants who might decide to continue developing their project?
Make properly signed agreements with your teammates shortly after or even during the GGJ. It’s not 100% necessary from a legal point of view, but it might help avoid some issues once you decide to continue with the project.
Also, it helps to know all the team members, this will make it easier to discuss this option, and you’ll know with what kind of people you’re getting on board with. It kind of goes against the GGJ spirit - getting to know new people - but if you think you want to continue work on a GGJ prototype, it’s a smart move.
Last but not least: Have fun! Creating something cool with friends in such a short time is one of the most fun experiences we can think of. So don’t worry too much, just give it your best and enjoy the ride!

You can find more information on FYI on Digital Dreams’ website. Currently, Digital Dreams is working on a big project, which will be announced in the coming months. Stay updated through Twitter: @DigitalDreamZzz

ContributionsPostmortem

The Global Game Jam and beyond: Somyeol (2011)

January 7, 2013 — by Mariia Lototska

The Global Game Jam and beyond series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advise on their attempt to turn their Global Game Jam project into a full fledged commercial product.

During the 2011 edition of the Global Game Jam, the “extinction” theme brought forth an incredible variety of concepts. A familiar looking, but incredibly refined game was Somyeol 2D, created at the Bremen GGJ site in Germany. A young team of students that made the game decided to continue development and released Somyeol. The original GGJ version developed at the Bremen site looked like this:

Its successor, called Somyeol (the “2D” was dropped), has got more features and better graphics and was released on iOS in February 2012. The game uses MadeWithMarmalade as middle ware and was later released our game on all mobile platforms including: Android, iOS, Bada, and Blackberry Playbook and the team is still working on the versions for Windows Phone and Blackberry 10. Somyeol now has more than 100.000 downloads in the Google Play Store and a 4 Stars Rating or higher in all the App stores it’s availabe in, including the Blackberry Appworld store. The final version looks like this:

ContributionsPostmortem

The Global Game Jam and beyond: Resonance 2010)

December 18, 2012 — by Mariia Lototska

The Global Game Jam and beyond series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advise on their attempt to turn their Global Game Jam project into a full fledged commercial product.

During the 2010 edition of the Global Game Jam, the “deception” theme brought forth an incredible variety of concepts. A rather unexpected entry was Resonance, which ended up winning both a jury and popular vote prize at the Dutch Global Game Jam. The game was released on iOS in February 2012. The original version looked like this:

A rather long concept phase spawned the idea to use deception as a visual aspect in the level design: musical keys would trigger blocks to let a character reach a seemingly impossible point in the level. The first version of this platformer concept was already ready in the evening of Saturday. From that point on, everything went smooth for the team. The rest of the time was spent creating levels and ended up having 14 levels.

People actually had to queue up to play the game even with 3 laptops showing it

We were already very proud of our game, but we didn’t expect winning our site’s jam with it. When people started to walk around and play other games, we got a lot of positive reactions. People actually had to queue up to play the game even with 3 laptops showing it. That was amazing to see and was an enormous boost in motivation to continue developing the game after the GGJ. When we later won the awards for best game of the site and the popular vote, we all knew we had to finish and release this game.

Finishing the game eventually took a bit less than two years. Team member Ruud van Boerdonk was able to release the game on iOS through his company ParaLogic Media. The original first 14 levels of the game were made available for free.

The resonance team after receiving their prizes for winning the Dutch Global Game Jam
The resonance team after receiving their prizes for winning the Dutch Global Game Jam

What triggered your initial consideration that your game was worth to continue development?

The positive reaction during the Global Game Jam and of course winning both the audience award and the jury 1st price made us decide on the spot that we wanted to finish and release the game. At that time I had some contact with Spil Games for other games so I promised the other team members to check if Spil Games would be interested in releasing the game.

What do you believe was the main element of your game that allowed it to be commercially viable?
The unique experience the game provides. It’s unique in graphics, game design and audio, which together make a great and unique gaming experience.

How did you manage the step to go commercial in your team?
Not everyone in the team had the time or motivation to finish the game. A few members displayed the game on some local game events like Indigo, Game in the City and Festival of Games. We used those events as “deadlines” for the development iterations, such as adding more levels, bug fixing, publisher API integration and so forth.

What were the three most important experiences/learned lessons and/or challenges that you had while further developing your game?
- Making agreements. This turned out to be a bit of a pain because the time invested into the game per member varied during further development. Because of that the agreements had to change too from time to time, not always to everybody’s satisfaction.
- iOS version and royalties. Team member Ruud created the iOS version of Resonance on his own. Making agreements on the royalties with the rest of the team didn’t go as smooth as he had hoped, which was a bit depressing from time to time.
- Development time. Because we had an agreement with Spil Games, we should have finished the game asap. Unfortunately, that didn’t happen. It took more than a year to get the game released on iOS and flash. Fortunately Spil Games was a good partner during that period.

In your case, what did you learn from getting the game out to the public?
We’ve learned that the app store is a hard market to get noticed on.

What kind of tips would you give to other GGJ participants who might decide to continue developing their project?

Do’s

If your game got a lot of attention during the Game Jam by winning for instance, keep interesting parties up to date on your progress and try to showcase your game on events.

- Keep everyone motivated. Not everyone on our team was as motivated to continue on Resonance as the rest or had the time to do so. Part of our programming team wasn’t to do any extra work after the Game Jam itself. Communicating with the entire team was also a challenge some time. Once the development of Resonance came to a halt, rekindling motivation became quite a challenge.
- Get together to finish the game if you can. We never really met again after the Global Game Jam, as our team was composed of folks spread all over our country. Regular meet-ups might have helped a lot in finishing the game sooner. It would’ve also added to keeping everyone motivated.
- If your game got a lot of attention, harness it. By winning a prize at your own Global Game Jam site, make sure to keep interested press or publishers up to date on your progress and try to showcase your game on events. We were able to showcase our game at several events because of the attention we received, but never really chased down the press. Resonance was released two years after it was made at the Global Game Jam, causing us not to received a lot of press. We might have had more press attention if the game would’ve come out earlier.

Don’ts

Resonance's Appstore icon
Resonance’s Appstore icon

- Be too serious. Setting up contracts and making revenue share agreements was a rather exhausting process that we took too seriously. This also had a very demotivating effect.
- Take too long to finish the game. We ended up making both a Flash version and iOS version of the game. Both pretty much came to a halt because of a lack of motivation and other responsibilities, taking much longer to finish than we wanted to.
- Let your team mates down. As a member of any team, you have to make sure to fulfill your responsibilities or, in the worse case, pass them on to someone who can take care of them. If someone ends up not responding to a decisive e-mail that requires the entire team to answer, the team gets kind of stuck.

The Lite version of Resonance for iOS can be downloaded here. The additional map pack can also be purchased for $0,99 cents.

ContributionsPostmortem

The Global Game Jam and beyond: Pulse (2009)

December 13, 2012 — by Mariia Lototska

The Global Game Jam and beyond series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advise on their attempt to turn their Global Game Jam project into a full fledged commercial product.

Pulse was made during the first ever edition of the Global Game Jam in 2009 and was the result of a highly collaborative effort of a bunch of the enthusiastic Dutch ‘Team Alfa’ during the very first edition of the Global Game Jam in 2009. The game ended up becoming the very first game in the history of the Global Game Jam to receive a publishing deal. The original Global Game Jam version looked like this:

The Pulse team won third prize at their GGJ site in Hilversum, the Netherlands and received a publishing deal with the Dutch game studio Virtual Fairground shortly after. It was launched in the Apple Appstore in March, 2010 as Pulse: The Game a year later as a promotional game for the popular Dutch DJ Ferry Corsten, who also produced an exclusive soundtrack for the game. The game received rather good scores on various popular mobile game websites, including TouchGen (3.5/5) , Pocketgamer (7/10) and many others.

The final iOS version featured above was released in March 2010 after being completed by Dutch game developer Rough Cooky, famous for their famous iOS game Star Defense.

It also forced us to make some solid agreements because not all of our original team members would put in an equal amount of work in the future development.

What triggered your initial consideration that your game was worth to continue development?
From the very moment we decided on the game’s concept during the first hour of the jam, it felt like we we’re working on something valuable. Our team was radiating with energy as each of us produced our separate parts. When everything comes together like that it just feels right. We won the popular vote through our site’s Audience award, so we knew there was an audience. Also the Dutch game studio Virtual Fairground was one of the judges and was interested in further development of the game. It was super exciting, but it also forced us to make some solid agreements because not all of our original team members would put in an equal amount of work in the future development. We solved that problem with a one contract between all the original team members and another one between us and Virtual Fairground.

What do you believe was the main element of your game that allowed it to be commercially viable?
It was a game focused on experiencing dance music in an interactive fashion. It was one of the first of its kind and super casual with its one button controls. The way the audio works together with the rather trippy and colorful visuals instantly gave it that special look. We had some pumping beats and vivid colors going on from the very start, creating an experience that would make you bang your head without a doubt. A lot of people also liked the GGJ version because it was co-op, but we made sure to make the single player experience on mobile as fun as possible when we developed it for Virtual Fairground.

One of many pieces of concept art team member Samar Louwe drew after the Global Game Jam to further flesh out the game’s visual style.

How did you manage the step to go commercial in your team?
We decided to split the IP right evenly over the team members. So if there was going to be any revenue it would be divided accordingly. A few team members where hired by Virtual Fairground to work on the game at their offices. I was responsible for initial project planning before it was gradually passed on to Rough Cookie.

What were the three most important experiences/learned lessons and/or challenges that you had while further developing your game?
1. It’s hard for people to make a switch between the GGJ-mindset and a commercial mindset. It was the first commercial project for many of the team members to work on from start to finish. A lot more stuff comes at you and if you don’t have the experience to turn your prototype into a product or the proper guidance from senior developers, prepare to learn a lot of new things.
2. Good ideas depend on a lot of factors to turn into good products.
3. We were funded with €10.000 euros to turn the original GGJ version into an extended version, but that wasn’t enough to finish it completely with just a part of our original team. Virtual Fairground ended up deciding to pass on the development of Pulse to another Dutch game studio, who eventually made the iOS version. In hindsight, we could’ve made the game for mobile ourselves, if only we had more time and funds to do so without the involvement of another party. Then again, we all had responsibilities at college, a job or a company to worry about outside of our team effort for Pulse, making the further development quite tricky.

Our team was completely exhausted at the end of the Jam, but the vibe after finishing version of Pulse and the excitement of showing it kept us psyched until the very end of the jam!
Our team was completely exhausted at the end of the Jam, but the awesome team vibe after finishing Pulse and the excitement of showing it kept us psyched until the very end of the jam!

In your case, what did you learn from getting the game out to the public?

Assumption is the mother of all great screw-ups, they say. And it’s true.

A lot of things came up, but if it comes to releasing a mobile game, especially now more than ever, good marketing really makes a difference. In our case, the marketing done for the game wasn’t optimal and Ferry Corsten’s fans apparently didn’t all own an iPhone as we hoped. As for getting the game ready for the public, testing remains the most important part of development. It’s always a scary moment to show your game to new players, but you want to do this as much as possible before getting your game out.

What kind of tips would you give to other GGJ participants who might decide to continue developing their 2013 project?
1. Make sure to have a solid agreement in place with all your team members before continuing to commercialize your GGJ game, so everyone knows what to expect from each other.
2. How will you fund your game development? Free time just doesn’t cut it. You need a better plan, divide the responsibilities among your team and find more support to further develop your ideas into a real product.
3. Do you have enough skill and knowledge in your team? Just having a game designer and programmer isn’t enough. Bringing a game to the market also requires product management and a ton of PR & marketing. Prepare for it to be quite the learning experience.
4. Make good decision tools. Or find someone to advise you, like a game studio or experienced game developer.
5. Try to keep your team small. Don’t involve too many extra people in the development process.
6. Don’t create too many features. Remember how you made this game at the GGJ in the first place!
7. Try to finish your game quickly. Promote it as much as possible and put it out there. If it’s successful, you can go on building all the features you wanted to in the beginning and introduce them with updates.
8. Make very nice graphics. High polished graphics are a must to stand out in the oversaturated mobile and tablet markets of today.
9. Playtest a lot. Every build, every prototype, you should play test on at least a few people. It speeds up your process, and makes it easier to make decisions.
10. Recognize assumptions. Assumption is the mother of all great screw-ups, they say. And it’s true. If you ‘think’ something will be great, or won’t be very hard, chances are reality proves you wrong. Be honest about what is unknown and unproven.

Pulse: The Game sadly is no longer available for download after Virtual Fairground closed down in 2011.

ContributionsPostmortem

Global Game Jam post-mortem - Studio Miniboss’ Planetary Plan C

December 10, 2012 — by Mariia Lototska

Press-Release-01.jpg

Planetary Plan C
Planetary Plan C

The Global Game Jam post-mortem series covers the experiences of various Global Game Jam (GGJ) teams from all around the world. We ask teams from various locations and GGJ editions to look back and tell us about their experiences, share learned lessons and offer advise on creating something beautiful and fun in less than 48 hours.

This is ship’s log for ARK-II, mission 2301.A.NULL, written by captain-in-charge, NoahX02.
Our mission will begin shortly. It will be our last mission before departing the solar system.
Preparations are complete. The estimated hour for execution was, unfortunately, imprecise.
NoahX01 is MIA as of the last hour. Our current measurements indicate that temperatures have reached critical levels, and we must depart at once.

The storage system is functioning properly, and is ready to receive the specimens. I fear that the early arrival of the sun’s thermatmosphere will render most of the remaining life in the system extinct before our current plan can be executed. It is for that reason that we have ultimately agreed upon adopting plan C.NULL to mission 2301, at our own expense and risk. That plan does not exist in your archives. It is as follows:

  • ARK-II will follow the designated route of the planets as of plan A.NULL;
  • Each landing will be the beginning of an approximately 1-minute search mission, instead of the 3 hours designed in A.NULL;
  • We will deploy as many NoahX units as we can, but only one at a time, to guarantee the success of the mission;
  • ARK-II will depart the planet when that time has elapsed, regardless of NoahX units that are in the surface of the planet;
  • The times are calculated for every planet to maximize our orbital jump’s effectiveness;
  • Upon leaving the last planet, the ARK-II will enter phase 2, and launch into hyperspace as expected.

All NoahX units have agreed on this.
All our hope are belong to you.
It begins now.

From scratch

Early concept art for the main character
Early concept art for our main character

Cheers everyone! We are a team of independent game developers who participated in Global Game Jam 2011 from Curitiba, Brazil (with PUC-PR - one of the biggest jam sites in 2011) and created the game Planetary Plan C.

This year’s theme was “Extinction”, and the idea for the game came from looking up the word in a dictionary, where we found the meaning of stellar extinction. After a brainstorm session by most of the team, we came up with the basic ideas for the game mechanics and concept - at this point, it’s difficult to say who had which ideas.

In our basic game conception, the player is able to visit four different planets in succession. In each of them, he is given about a minute and a half to rescue as many plants, animals, people and novelty items as he possibly can, before everything is incinerated by an expanding sun in its Giant Red stellar phase. The game is played as a simple platformer, with the added twist that the worlds are small and circular, so you can walk all the way around it in a few seconds. To add challenge to the quest are natural hazards: lava, water, and volcanic eruptions. Once the time is over, the ship automatically takes off to the next planet, until they have all been visited, and the player is awarded with a sight of everything that he has rescued, on their new home planet.

Determining this basic gameplay took a lot of time. The duration of each world (and of the game as a whole) were also a serious issue, as we needed to decide it beforehand so the music could be composed to match it, but we didn’t have enough gameplay feedback to make a well-informed choice. We went by our gut feelings, and we think that we got it just about right. Beyond that, everything went very smoothly.

With the main idea in our heads, we then proceeded to organize our work process and assignments for each member on the team with what was important to take the most advantage of our time and resources.

The tasks were divided based on the specialty of each member of the team, so the programmer (Rodrigo) and composer (Rafael) worked on their own in their respective areas, and the art assignments were as follows: Santo was responsible for background art, props and audio effects; Amora made the art and animation of the main character, the robot Noah, as well as animating part of our game resources; Irene worked on the design of the game’s visual interfaces, menus and HUD; Henrique focused on concept art, animated resources and Noah’s spaceship - and also wrote the game intro message; and Karen made concept and resources art, spaceship and game introduction screen. That aside, everyone took part in the creation of concept and game mechanics.

“There’s much credit to be given to the classic platforms like Mario, Sonic and Megaman, for their influences on how we perceive platform movement.”

The influences and sources of inspiration for the game were many. There’s much credit to be given to the classic platforms like Mario, Sonic and Megaman, for their influences on how we perceive platform movement. The “controlled jump” and “accelerated move” of Mario and Sonic are seen in the game, as is Megaman X’s dash.

In the case of our composer, Rafael didn’t look for specific game soundtrack references with a thematic similar to our game idea, mostly because there was not enough time for this task. So he focused on his own musical preferences he was used to working with, so he could reach the soundtrack effect he wanted more easily. He took as inspirational sources L. V. Beethoven, J. Brahms, Leonard Bernstein, and music from Banjo-Kazooie, Zelda and especially, Mario Bros. He composed the orchestra as to provide the game with a dramatic atmosphere, supplying an urgent and epic feeling to the task of collecting resources and avoiding extinction. The musical percussion was specially designed so it could give an additional fun ambience to the missions.

The right scale

During the game’s development, several ideas didn’t make the cut, simply because we didn’t have enough time to implement them:

  • There were supposed to be at least two additional hazards, a lightning bolt and a meteor;
  • Smoke particles were supposed to be used for the dash and as a notification that the volcanoes were about to explode;
  • We originally had planned a solar system-wide view, where you could see the star swallowing the planets as time went by.

We tried to deliver the player an experience where he comes upon a situation in which choices are to be made, for he will never be able to save everything from each small planet. These choices per se imply results and responsibilities concerning the influence over the sustainability of a new world as well as the preservation and extinction of species and cultures. We wished this game to provide fun above it all, without trying to stuff the player with moral lessons or cliché preaching. If the player can gather a deeper meaning from his experience or just have a really good time playing, all is well, our mission is accomplished!

“Looking back on our development process, one thing that could probably have been better would be to have more time to balance and refine the gameplay.”

Looking back on our development process, one thing that could probably have been better would be to have more time to balance and refine the gameplay. Particularly, we believe that the final scoring and collectible distribution systems could have been improved. Our programmer’s opinion is also that the game might have ended up being too hard, perhaps due to the unpredictable spawn of volcanoes and the movement (in particular, the unstoppable dash).

Overall, everything went incredibly well. Some great ideas surfaced, like Henrique’s idea to use a “surface map” to indicate the hazard areas of the map. With a combination of Notepad++ Macros and Photoshop trickery, he could create a long string of 0s and 1s indicating which segments of the surface of each world was safe to step on, and Rodrigo hardcoded that into the game as C strings. Without that, it would have been impractical to implement this concept, at least given the time that we had with only one programmer. It was very surprising to see that all surface maps were very accurate, and not a single one required tweaking!

Looking back

The team is very proud of all the polish that we were able to give the game, including finishing a reasonably complex game with relatively few bugs. We also managed to complete the GGJ-2011 Achievement Playing the Music: The game’s duration is matched to that of a song. When the song ends, the game ends. No loops allowed.

For events like the GGJ, where you only have a weekend to develop a whole game, the most important thing we can say is: THINK SMALL. Games are always more complex than they seem at first. In particular, we strongly recommend making a 2D game, since not only does 3D add extra difficulties in both programming and asset development, and given the time constraints, they are rarely worth the effort, and are more likely to look “amateurish” (it’s unlikely that you’ll have time to make professional-looking models and textures).

“There’s no “write the whole game first, program the whole game later” - and some questions are better left unanswered, too!”

After the first concepting phase, when you know what kind of game you want to make, you will have tons of gameplay and feature ideas. You will also get that paralyzing feeling of “we have to decide everything that would be in a game’s design”. We really think it should be avoided as much as possible. Think of all the questions on your mind, but don’t decide on anything beforehand - instead, think of the smallest subset of the game that you can build fast, and then as you build it you will feel the answers coming. We tried defining that smallest subset as early as possible, and work on it right away: “some platformer guy who is running around on a 2d planet with lots of hazards and a spaceship he has to return to. He collects things.” Whether the guy was a robot, a dragon or a human, whether the things he picks up are rocks or books or people: it didn’t matter at that time. There’s no “write the whole game first, program the whole game later” - and some questions are better left unanswered, too!

A tip we would like to give is that care should also be taken when picking your tools: pick something you’re familiar with; you already have enough on your plate, don’t try to learn new technologies as an added difficulty! Try to prepare in advance, setting up a blank workspace/project can save you a lot of time. When you’re trying to get a game done in 48 hours, you don’t want to spend a few of those tracking down dependencies and writing boilerplate. And finally, have fun! Otherwise, there’s no point in joining.

Finally, we wanted to say that having such a positive feedback about our work is without any doubt the best kind of stimulant we could get. It’s definitely an incentive to keep working hard and makes us value our work as a team and individuals, as game developers. We want to keep producing games and giving it our best.

We are sure that this positive response to Planetary Plan C is the result of an incredible teamwork, full of talents that not only complement one another, but are capable of communicating well and sharing a harmonious view of the whole.

The Team

The Planetary Plan C team
The Planetary Plan C team

Amora B. has a career in Animation, having worked in productions such as “The Princess and the Frog” (Disney), “Chico y Rita” (Estudio Mariscal y Magic Light Pictures), and other films and commercials. She’s a co-founder of MiniBoss.

Fernando Su is a friend of the team. He helped us as a Beta Tester, cooking-planner and moral support.

Henrique Schlatter Manfroi majored in Game Development. He has worked for Southlogic Studios and Ubisoft as a 2d and 3d artist, and is now co-owner of the independent developer Sulistas.

Irene Sasaki Imakuma majored in Architecture and Urbanism, and works in a retail architecture office. She also works with graphic design, animation and project management as a member of MiniBoss.

Karen Garcia Teixeira has majored in Visual Arts. She works as an Illustrator and is a member of MiniBoss team.

Rafael Miranda is a pianist and studies composition at Alcântara Machado College in Brazil. He composed the soundtracks for the games Jules: unboxing the world, Talbot´s Odyssey - part one and Planetary Plan C. He is a member of MiniBoss team.

Rodrigo Braz Monteiro is the game’s programmer. He works for an online casual gaming company, where he is the lead programmer.

Santo, a.k.a. Pedro Medeiros, has majored in design and works with illustration and concept art. He is a co-founder of MiniBoss.

Find out more about Studio Miniboss team on their blog.

Online

Gamesauce Challenge Announces Global Game Jam Winners

February 2, 2011 — by Vlad Micu and Javier Sancho

GGJ2011_posterBLUE_text.jpg

The GGJ2011 Poster by Sjors Houkes

We have announced the ten winners of the Gamesauce Challenge for the IGDA Global Game Jam!

The ten winning games were selected from the 1487 games that were developed last weekend during the Global Game Jam 2011. Each winning team has been awarded the opportunity to showcase their game during Casual Connect Europe on Thursday, February 10, 2011 in Hamburg, Germany and all-access passes to Casual Connect Europe and three nights of accommodation.

Submissions were judged based on the potential of their teams to create commercially viable projects and meet with publishers during Casual Connect Europe. Each Global Game Jam site was given the opportunity to nominate their very best project for the contest.

The Rhythm of the Stars team from Finland
The Rhythm of the Stars team from Tampere, Finland


The Winners (in alphabetical order)

Death Pizza
Turku, Finland
Sabastian Jakaus, Tatu-Pekka Saarinen, Arash John Sammander. [email]

Hamsters and Plague
Oulu, Finland
Mika Oja, Teemu Kaukoranta. [email]

The Last Fleet
Capetown, South Africa
Marc Luck, Luke Marcus Viljoen, Rodain Joubert. [email]

Ned, You Really Suck the Life Out of a Room
New York, USA
Team NED: New York, USA, Randall Li, Chris Makris, Ben Norskov, Matthew LoPresti, Roger Cheng. [email]

Planetary Plan C
Curitiba, Brazil
Henrique Schlatter Manfroi, Pedro Medeiros de Almeida, Amora B., Karen Garcia, Rafael Miranda Gomes, Rodrigo Braz Monteiro, Fernando Su, Ne Sasaki. [email]

Rhythm of the Stars
Tampere, Finland
Pekka Kujansuu, Olli Etuaho, Juho Korhonen, Aki Jäntti. [email]

Somyeol2D
Bremen, Germany
Kolja Lubitz, Jannik Waschkau, Carsten Pfeffer, Jan Niklas Hasse. [email]

Snobli Run
Kajaani, Finland
Veli Vainio & Ilkka Leino. [email]

Speck
Manila, Philippines
Marnielle Lloyd Estrada. [email]

Ultimate celebration
Rochester, New York, USA
Lane Lawley, Brian Soulliard, Devin Ford, Lawrence Jung, Kevin MacLeod. [email]

The Somyeol2D team from Bremen, Germany
The Somyeol2D team from Bremen, Germany

The Runner Ups (in alphabetical order)

Dramatic Extinction
Hamar, Norway
Stig-Owe Sandvik, Kenneth Aas Hansen, Andreas Fuglesang.

Glitchhiker
Utrecht, The Netherlands
Jan Willem Nijman, Rami Ismail, Jonathan Barbosa Rutger Muller, Paul Veer, Laurens de Gier.

How to Kill Pandas
Pelitalo Outokumpu, Finland
Antti Piironen, Anssi Pehrman, Tuuka Rinkinen, Salla Hakko, Heikki Koljonen, Hannu-Pekka Rötkö, Lauri Salo, Juho-Petteri Yliuntinen, Lari Strand, Henry Härkönen, Sina Aho.

Johann Sebastian Joust!
Copenhagen Game Collective
Douglas Wilson, Nils Deneken, Lau Korsgaard, Sebbe Selvig, Patrick Jarnveldt.

MeteorCrash
Córdoba,  Argentina
Ezequiel Soler, German A. Martin, Carla Soledad Corcoba.

Make sure to participate in the IGDA Global Game Jam next year for your opportunity to win!

logo
SUPPORTED BY