next »

[Skomakar'n]

Bottoms Up!



-----

LATEST DEMO: http://www.royalrailway.com/BottomsUp/

ANYTHING BELOW IS NOW QUITE OUTDATED.

Link to demo.
Thread in which the demo was announced.
Facebook group.
Twitter for small updates.

I uploaded a nine minute long preview of the demo of the game to YouTube, so that we also have something to show to people who might not feel like downloading the demo before seeing the game in motion.



http://www.youtube.com/watch?v=DzM39SAPIPQ

'Bottoms Up!' is a game that I, together with Erik Schröder, am currently developing primarily for the iOS, including a HD version for the iPad, but also for Windows, Linux and Mac OS X. The demo linked to above is for computers. We are aiming at a release some time this summer, and are doing as much work on it as we can.

The game revolves around taking the character, who is a person riding a giant bottle of Champagne, from a start point of each level, and to its goal. The bottle is controlled by an arrow moved by the mouse, or, for the iOS devices, a finger. The length of the arrow when the mouse button or finger is released determines with how much speed the bottle will be launched, and the angle of the arrow is the angle of the shot.

For each level, the player is given a certain time limit as well as a limit of the amount of shots that can be made. Should the player use all shots without reaching the goal, or should the time run out, that's a loss, and the player will have to try again. There are also level elements that could lead to an instant failure, such as chimneys, into which one should avoid falling down in order not to get toasted.

We have a little story line as well, even though it is not an important part of this physics based platformer puzzle kind of game:

It is New Year's Eve, and it is getting close to midnight. Charles did not know what he was getting himself into, when he bought the biggest bottle of champagne in town; even bigger than himself. In the wrong end of town, with a long way to drag this giant to reach his friends to ring in the new year and spread the champagne, he realises that he is out of luck, and that he will never be able to get there before the clock strikes twelve. Unless... He figures that it would be worth it to let some of the fluid get spilled, would it only enable to show up with some of it on time, and determines that he will use the pressure in the bottle to let the foam quickly take him all the way that he has to travel to get a happy, new year.

I am the programmer, and the artist, as well as the one who originally pitched this idea, and my name is Adam Emil Skoog. My colleague is Erik Gustav Schröder, who makes the music and the sound effects, and helps me with the overall concept and design of the game in general. We have recently registered ourselves as a company in order to hopefully turn this into the initial game of our own little studio.

The computer version will probably stay free, while the one for iOS will be ridiculously cheap. We are aiming at about thirty levels to begin with, and are planning on releasing additional ones as downloadable content as we go after the game has been released. We will also integrate it with Facebook so that users can post their results to their walls, and we are planning on setting up an online highscore board of our own.

If the game happens to do well, and actually earns us any money, we will consider porting it to Android systems as well.

The best way for you to get a good idea of the game, other than the above screenshot, would be for you to simply download the demo and try it out. It's a rough version lacking many things that are now on the schedule, or already implemented, but it should still give you the general idea. It is definitely a playable game, but perhaps a bit short on levels. The demo is available for Windows, Linux and Mac OS X.

The actual development log will follow below.

[Skomakar'n]

Post 1 - May 3rd 2011

Fun with the level editor:
http://www.youtube.com/watch?v=vEcRTTCF3FM

Now, as the game has already been under development for a while, this post will be very much of a jump right into the current progress, but I will try to give you at least a little background to begin with. The original demo was released in connection with New Year's Eve between 2010 and 2011, because of the theme of the game, which plays out during this very date (not during any certain year, though). This was when we posted the announcement thread, which, I am sad to say, received almost no attention at all.

We continued working on the game, and today we have the game up and running in the iPhone simulator as well, but we have not yet applied for any license to try it out in an actual device, although this is something we should be able to do pretty much whenever we feel like it right now. We have our company registered.

The last few months have been devoted to making the level editor, which is a crucial tool for Erik to help me build levels, and for me to be able to do so without a lot of time and tears wasted. I don't want to find out that a level design doesn't work out after I've spent several hours carefully placing everything by hand-written numbers in the level files. Using the editor, which is almost at version 1.0 now, and definitely usable, we can have our concepts up and running within minutes.



The initial interface, as seen in the image above, that one is faced with as soon as the editor is booted up, is the one where tools can be selected for the current level, and settings can be changed. There are also buttons for the creation, playtesting and saving of levels, and clicking Load/organise leads to a different subscreen, where the order of the levels can be changed, and saved levels can be loaded or deleted.



The image above is the actual editing mode, which can be entered by pressing tab from the tool selection screen. Everything is easily placed using the mouse, and operations available include selecting objects, moving them around, deleting them, copying and pasting them, and a lot more. To the left, there is a toolbar containing buttons, all with tooltips, for most of the vital actions, which all also have hotkeys on the keyboard. To the right, there is a scrolling listbox containing every object in the level.



Above, we can see one of the newest, and greatest, additions to the program; zooming. Being able to zoom out in order to uncover more of the level and getting a better overview of it, is extremely handy, and makes it a lot easier to work with big obstacles, like houses or scaffoldings.



The above image is one of two little sketches I made while staying the weekend in a cabin in the woods just outside of Oslo in Norway. It's a concept for the level selection screen for the iPhone/iPod Touch (and thus possibly Android) version of the game, where one can flip between the levels using a finger.



Finally, the character as seen in the demo does not look the way we imagined him when we set out to make the game, but we didn't have the time to draw and animate any sprite for the final character by the time the demo was supposed to be released, so we created the little, pink placeholder one that can be seen in the demo, and the screenshot in the main post of this thread. Above is a quick and dirty sketch of the Charles we really imagined when we first started working on the game.



Last night, I actually had a go at creating the sprite for the real Charles, and this is what I ended up with. I am pleased with it myself, but it seems some people still want the pink blob to stay. I'd love to get some feedback as to which one you'd like to see in the final game. We are definitely planning on putting the demo Charles in the game as some kind of Easter egg no matter what, though, and as a suggestion not completely unserious, I even made this:



Would this work out?

Any replies would make me happy!

[Erik Schröder]

Hi, I'm the composer and... sound guy.

I'm uncertain about if I should re-arrange the music for the final game, but one thing's for sure - I will make some real "finish the level" music and not just... chimes.

[Skomakar'n]

Post 2 - May 5th 2011

Not much has been done today, but a friend of mine was kind enough to compile the demo as a native executable for 32 bit Linux, so those users won't have to run the game through Wine anymore, which is great news.

As the structure of level files has been slightly modified since the demo was initially released, I had to update some things in all files, including moving the goals and crates slightly. I wrote myself a little C++ program to automate this process to save some time.

A download link for the 32 bit Linux version has been added to the same download page as before:

http://operaroyale.com/bottomsUp.html

[Skomakar'n]

Post 3 - May 17th 2011

First off, our company now has been successfully reregistered after changing our name from Opera Royale to Royal Railway. We have gotten ourselves the domain name, and now have a placeholder site at http://www.royalrailway.com/ and the old download site still remains up and running for now.

I did it! The first complete version of the level editor (version 1.0.0) is done, on time! First off, here is a picture of the second level loaded into the editor, and zoomed out, with a piece of scaffolding selected.



One thing that one may notice, is that the crates are a bit off, and not appearing to be in very good positions. Some of them are even inside of the lower scaffolding! This is because this is where they were, and are, in the downloadable demo of the game. They were all placed with hand-written code, and it appears I didn't get them exactly where I wanted them to be. I didn't notice when playing the demo, because they can't be seen at the beginning of the level, and they fall to the ground right away. This is one of many things that our editor easily allows us to fix before we release the final game.

The features are quite numerous, and many of them have already been described in the previous update on the progress of the editor. Most of the work lately has been bravely fighting bugs as though they were dragons living deep in the darkest cavities of my RAM memory, but some more additions have also been done since the last time.

One of the latest additions have been to save more types of actions to the history before. At first, the actions saved to history were adding or removing objects, moving them around, locking or unlocking layers, or moving layers up or down in the hierarchy. Now the editor also saves selections and deselections, as well as changes to objects after they have been added (such as changing the size of a scaffolding, or the colour of a house, that already exists in the world; the option box for this can be seen for the selected scaffolding in the top-left corner of the above screenshot).

Both of these additions caused a couple of quite mind-boggling bugs along the way, but it seems my efforts to get rid of them have been successful.

The editor had already had a grid for a while, and when adding new objects, it was already possible to snap their position to the grid by holding the S key while moving the cursor. However, when moving already created objects, the grid was of no use, and holding S did nothing. This now works.

An indeed very puny, but still so nice feature to have been added, is that it is now possible to scroll through the layer list or the list of saved levels using the mouse wheel. This was the last step needed in order to make the scrollbars feel exactly like those native to most modern operating systems.

Another small but nice thing is that the layer box now automatically scrolls to display the last item that was selected, so that if we, for example, decide to select a background house at the top of the list, by right-clicking on the house in the world view, when the list has been scrolled to somewhere in the middle, so that the layer is not currently visible in the list, the box will scroll there, to make sure that it is.

One might not always want to have the sound in the game turned on when playtesting. If one is working on a level for a long time, playtesting it a lot, it might get tedious to hear the music getting restarted all the time, or one might just simply want to listen to one's own music. Because of this, a new button has been added to the main screen, which can be clicked in order to turn all sounds off. The button has been played right next to the one reading "Load/organise", as can be seen in the next screenshot:



Pretty much all of the features that we want are in there now, and for versions to come, the main additions will be the new "tools" (level elements, such as houses or crates) to come, as more things than the original player bottle, the goal post, houses, crates, chimneys, scaffoldings, fans and icicles will be added to the final game.

I will need to make some kind of tutorial or documentation of the editor for my colleague, Erik Schröder, but it doesn't have to be too extensive, and hopefully won't take up too much time.

We can now continue with other things, such as planning out new features of the actual game, as well as the menu interfaces for the iPhone/iPod Touch and iPad versions, which will have to be slightly different, because of the different dimensions we have to work with. There is also Facebook integration to be taken care of, and actually putting the menus into the iOS versions (we are currently only working on the version for iPhone and iPod Touch; we will adapt it for their larger sibling later on).

I also need to refine the graphics for the iOS version, as they are currently simply scaled down versions of the original ones, which won't look very nice without a bit of fine-tuning by hand. This will probably have to wait until the very end of the development process, though, as this is not an important factor as far as the playability of the game goes, but it is of course an æsthetically important move that we will make sure to make before the game finally ships at the end of this exciting journey!

As always, keep coming back here, to check on our updates, and don't forget that I also post smaller updates to my Twitter account and bigger ones to our Facebook group.

[Skomakar'n]

Post 4 - May 17th 2011 (after having slept)

This morning, while sipping some coffee, the caffeine probably crept its way into my brain, for I had a lesser revelation. I pitched my idea to Erik, who liked it, and so I can announce it to all of you.

The level editor is working. I've said this. Now, releasing it for everyone to use could probably be quite popular among the people feeling a bit creative, but we want to take this one step further than allowing you to create custom levels for yourself.

We want to turn this into an entire network. We want you to be able to register an account at a devoted website of our own. You will then be able to use your username and password to upload your creations to our server for approval. The approved levels will become available for download, and can be fetched right from the game, both for iOS and PC, free of charge. If you log on to your account at the website, you can find a list of your downloaded levels, and will be able to rate them, giving it a thumb up or down.

This way, levels can be ordered by popularity, according to the number of given thumbs up, and they should also be able to show up in order of the number of downloads or by how recently they were created. We might also feature our personal favourites. One will always be able to see the name of the creator, and on the website, the name can be clicked in order to find their profile, so that more levels by the same creator can be viewed.

It should also be possible to search for levels, using either their name or the name of the creator. When uploading a level, a unique name will have to be selected for the level, and if it is already taken, another name will have to be picked. This way, it will be easier to tell levels apart, and to find old favourites again.

We are planning on releasing official packages of our own, too, which will get some extra focus and be more clearly and visibly featured than user created levels.

Approve?

[Skomakar'n]

I uploaded a nine minute long preview of the demo of the game to YouTube, so that we also have something to show to people who might not feel like downloading the demo before seeing the game in motion.



http://www.youtube.com/watch?v=DzM39SAPIPQ

[Skomakar'n]

Post 5 - May 24th 2011

Not a big one this time, but why not show you what little has been done in the past few days?

Most of my efforts have been planning. I've been trying to find a good library for the network part enabling us to upload and download levels from our server, as MySQL++ appeared to have some nasty license issues in the case of this particular game. I haven't decided on anything yet, but I will be looking into curl when I find the time.

As we are going to put helpful arrows in the levels, to guide the player into the right direction of the goal posts, I've now added a tool for this into the editor:



The arrow buttons are used to select the direction of the arrow, and the "Paint" button denotes that the arrow will be put as semi-transparent "paint" on the wall of a background house, while, if clicked, the button changes its text to "Sign", meaning that a sign, much like the goal post, with an arrow on it, will be placed. Because of this, we will of course have to change the motif of the goal post, which would look like another arrow sign if used in its current state.

Here are some wall paint arrows I have made so far, put on the body of a background house for clarity:

[Skomakar'n]

Post 6 - May 25th 2011

During the past two days, a few things have been done. To begin with, I changed my mind about the way I wanted to integrate these arrows into the game. I figured that the wall paint and sign idea was a bit too inconsistent, perhaps not clear enough, and actually kind of ugly. Erik and I decided just to use the same arrow graphic as for the arrow above the goal posts, making it possible to place such arrows pointing either to the left, to the right, up or down. The appearance of the tool was thus changed to something simpler:



This is a screenshot of an arrow in each direction placed in a level, alongside the goal, which also has an arrow above it, just like before:



Here is also a screenshot of an arrow placed in the original, second level, from the demo, to show the new feature off in a more probable setting:



Today, I created forms with focusable textfields and buttons for the editor, so that levels can have titles assigned to them, and so that a login screen will be possible to implement in the future. The textfields are quite simple, but when they have focus, the keyboard can be used to type text into them, and the arrow keys can be used to move the cursor. The backspace and delete keys can be used to erase text. It is possible to set a limit for the amount of characters that a textfield allows, and password fiels, that display everything as asterisks, are also working. If the content exceeds the width of the textfield, the text will scroll horizontally.

Textfields and buttons in a form can have focus or not. Textfields must have focus to be written into, and buttons must have focus if you want to submit them using the return key. The tab key can be used to change which object should have focus. If no textfield or button has focus, the first enabled element will be selected when the tab key is pressed.



While textfields have support for many international characters, such as æ, ø, å, ä, ö, ü, þ, ð, ç and accented vowels, they don't seem to detect Greek or Cyrillic characters (and at the moment, there even appears to be a bug in the library I'm using for input, that causes such characters make the program crash in OS X). This isn't really a problem, though, as the only characters that will be allowed for titles are A-z, 0-9, .,:;-!?'*_ and spaces, and usernames and passwords will probably be even more restrictive. If invalid characters are typed into a textfield, it becomes red, and one is not able to submit the form. Level titles have a limit of 16 characters.

After getting the textfields to work, I actually implemented the possibility to assign titles to levels; levels with no title will be displayed using their file name in the level, and levels with a title will be displayed using their title instead. Titles are changed from the organisation screen, where a textfield and a button have been added for this purpose.

[Skomakar'n]

Post 7 - May 27th 2011

I graduated from school today, and Erik gave me a 'Bottoms Up!' T-shirt!



We've also been suggesting a lot of new ideas, but not all of them have been thoroughly considered yet, so that update will have to wait a little longer.

[Skomakar'n]

Post 8 - June 6th - 7th (midnight) 2011

Following and preceding the days of my own graduation from school, graduations of others, and a meetup for some fora of which I am a member that lasted for a few days, took time from work, but I've been working for the last few days now, and it's time for a new update.

The last few days before my graduation, I created a text file to use as a change log, documenting not only changes that have been scheduled and thus also exist on file anyway, but also any minor or unexpected news; in short, every single change goes into this file.

From now on, most updates will have the latest content of this file pasted at the end. A lot of the content of the updates will mention many of the things listed in these logs, of course, but the logs can be seen as a summary, and they will of course also contain minor things that did not go into the text.

So, what have I done during the last few days? Well. First off, I decided to implement the message system that Erik and I had been thinking of. We wanted to be able to show messages to the players the first time that they would encounter something new, such as a fan, or a scaffolding, so that we can give them an explanation. I also decided that there should be a set of messages shown the very first time that the game is played, explaining the point of the game, and what the player has to do.

To begin with, I created a new file in the data folder to store what has been seen before, and what has not. I then created the message system class, that reads the contents of this file when a level is loaded, to determine which messages to show, and then updates the file to make the game remember that these messages should not be shown again.

I added arrows to navigate back and forth between the messages, using the same graphics as for the navigation arrows that already existed in the menus of the demo from January.

The graphics are still rough placeholders, but this is what it currently looks like:



The currently empty box to the left is supposed to hold an image related to the message, such as a picture of a fan, for the message explaining fans. The first time the game is played, the explanation is split up into several messages, with their own images for clarification.

I then had Erik come home to me, and we recorded some more material for our development movie. Of the ideas that were suggested the last time that he visited, at the time of the last update, we decided to start implementing the one about statues that one can knock over.

We decided for them to stand upon pedestals, which would remain static and unmoved while the statue itself would fall off and and, depending on its shape, act accordingly, obeying the laws of physics.

Two types of statues were made that night, which was last night. First, we tried out a simple statue, of the kind that is probably most commonly seen in a town; one depicting a human being. It eventually ended up looking like this, as I devoted time into making the final graphics for it today:



After a collision with Charles, the statue will thus fall over:



This is what the temporary graphics looked like, whipped up in a minute to initially try things out yesterday:



The second type was a round statue, in the form of an Earth globe on top of a pedestal, which rolls over upon impact with the bottle. The implementation is done, and these are also working in the game, but there are still only placeholder graphics to show:




At the same time, I also added a tool for this into the editor. The button graphics are still the same as those for the icicle tool, so there is currently no real point in showing it, but there is a counter on the top of the tool, just like there is in the icicle one, where one can change the number to change which kind of statue to place.

I'm planning on changing the button graphics dynamically as this is done, to instantly display what kind the current number represents, and will make the number keys hotkeys for this in the build mode, accordingly.

Different types of statues are still considered distinct objects, though, and one will not be able to select and edit statues after they have been placed; if one decides to swap the standing human for a globe, then the statue will have to be deleted, and the globe placed instead.

While I was writing this message, Erik also ordered the iOS development program from Apple, so we should be able to get ourselves into a more genuine testing environment not far from now, too!

As promised:

CHANGELOG:
-----------------

2011-06-04:

* Added a rough system for showing messages before levels. The level remains paused until the last message has been read. Messages will only be showed once, and are meant to introduce the player to the game the first time, and to introduce new types of obstacles or helping elements the first time one of them appears in a level, such as a fan. A text file is used to store new discoveries. The graphics are still placeholders.

2011-06-05 - 2011-06-06:

* Added statues that can be knocked over. They stand upon pedestals, that will remain standing when the statue falls over. Colliding with one of these obviously reduces the speed of Charles greatly.

* Globes working in the same way were added. These are the first circular, physical bodies in the game.

* Made it possible to place these using the editor. A counter tool is used to determine which type of statue to place. They can not be edited afterwards, as the types are considered distinct.

* All of these things still only use placeholder graphics, which were created. The tool currently uses the same image as the icicle tool.

* Finished up the final graphics for a statue, and defined its collision shapes.

* Fixed the bug that had caused Charles not to be squashed flat against scaffoldings for the last few months, and used the knowledge of this error to make squashing work for statues too. I made sure to update the iOS version too.

[Inanimate]

You've got a really unique style here, and the game sounds about as unique as well. Best of luck with development! I'll be reading avidly. 

[Skomakar'n]

Post 9 - June 7th 2011 (after having slept)

Getting accepted into the development program was a quick process, and after having slept through the night since yesterday, I woke up to find out about these great news this morning.

I had a bit of initial trouble registering my device (an old iPhone 3G running iOS 3.1.3, as I haven't installed the latest SDK to be able to try it out in my iPhone 4), but after a while I got it working, and was happily struck with the sight of the game actually booting up in the iPhone. It crashed right away, though, and after locating the source of the error, I consulted my iPhone programming guide, and it did have an answer.

I tried again, and there it was! It was incredibly slow (at an FPS of about 4), but the game was actually running perfectly well in every other sense. I turned off particles and stars and got up to about 20-25 FPS, and that's where I'm still at.






I just finished my first step in optimising the particle system, and now I'm running with foam bursting out of the bottle again, at about 12-14 FPS, at least, which is a good, first step into the right direction. The new system doesn't support transparency or scaling yet, though.

I'll keep working on making the game run faster, and I'll get back to you all with more updates soon!

CHANGELOG:
-----------------

2011-06-07:

* Got the game running in an actual iPhone 3G device running iOS 3.1.3. This involved solving a bug when loading levels; it appeared that one can not modify data in the standard resource folder on the actual device; one has to do it in a temporary folder. This fixed it.
* Optimised the particle system a bit, in order to make the game run at a more decent speed. It's not acceptable yet, but a lot better.

You've got a really unique style here, and the game sounds about as unique as well. Best of luck with development! I'll be reading avidly.  

Thanks a lot!

[Skomakar'n]

Post 10 - June 12th

So I decided to let go of my laziness, and actually install the latest tools, that I had already downloaded. So I did, and registered my iPhone 4 for development as well, and within no time, I got the game running on that device too, with a smoother frame rate of about 40-45 FPS.



The initial work on the optimisation was to try to work myself around the system for drawing images in Cocos2D (the graphics library/framework that I'm using), which I had never been really fond of anyway. Cocos2D draws everything in the form of individual nodes, where each image has its own object, even if they all share the same texture. The concept is a good one in theory, but I don't like the way the creator of Cocos2D decided to implement this, because it results in worse performance than necessary.

My solution was to create my own type of node, inherited from the sprite node of Cocos2D, in order to override the draw step with an implementation of my own. I added a fake draw call, which would accept a couple of settings for position, rotation and so on, and store this until the draw step. At the draw step, I went through all of these sets of information, in order to draw the image at each desired position in one step, from one single node, with one texture.

Initially, this didn't actually do much for performance, but it definitely didn't decrease the frame rate either.

Today I've been a bit more daring regarding the quest to force the frame rate into an acceptable direction, and I have been reading through quite a bit of the source code of the graphics library that I'm using in order to find out where the bottlenecks could be hiding, in combination with the profiling output of Shark, which is a lovely profiler that found out about while searching for solutions the other day.

Shark comes with Xcode, and so I already had it installed on my computer, without even knowing. This is the main interface of Shark:



Once I plug in my iPhone, after having set the mode to iPhone profiling, Shark will detect my device (called 'Skomakarn') and allow me to select a running process to profile. In this case, the box just says 'Everything', as the game wasn't running when I took this screenshot, but had it been, I would have been able to pick the name of my game from that list, and press the 'Start' button in order for the analysation to get going.

After collecting data for a while, Shark will interrupt the analysation and begin to process all of this data, which takes a couple of minutes, and once this is done, the program pops up a second window, containing all of the information I need:



This is a list of which calls and parts of the code that consume most of the processing time, listed by percentage. I can expand or collapse them through the arrow icons, and get into the nasty details of those chewing monsters, to find out which functions I should take a closer look at.



Other tweaks in order to increase the performance of the application, have included more hacks into the graphics framework, and playing around with the settings of the particle systems, which I have also simplified to some extent, making them a little less gorgeous, but still good-looking enough for that small screen, and perhaps even good enough for the bigger one of the iPad, or of a computer.

CHANGELOG:
-----------------

2011-06-08:

* Aligned the foam with the bottle perfectly. It was a bit off before.

* Added transparency support to the new particle system.

2011-06-08 - 2011-06-09:

* Created an alternative drawing system by adding an Image class of my own, that makes sure that only one node is created for each image that should be drawn. This is only needed when the image is not going to be drawn at more than one place. It didn't do much for the FPS in the case of regular object (although it might have decreased RAM usage), but worked wonders for the particles, and the game now runs at about 10-11 FPS instead of 4 with everything enabled.

* I kept optimising, and it's now running at about 20 FPS with everything enabled. Parts of this fix involved putting more than one foam particle into the image, rendering a lot less images each frame, and swapping the NSMutableArray instances for std::vector objects where objects have to be accessed a lot in real-time. I've also made sure not to update labels unless I have to, and I have tuned down the accuracy of Box2D.

* Installed the newer iOS SDK, and got the game running on my iPhone 4 as well, and the iPhone 4 simulator. About 40-45 FPS at the moment. Noticed that if the iPod is playing, booting the game will fade that music out, and fade the game music in, just like I wanted.

2011-06-09:

* Noticed a bug in the latest build of the game, where fans would boost you off at speeds way too great when the resolution of the game had been changed. I checked in the fan class file, and noticed that I hadn't taken frame rate into consideration when applying forces to objects within the air stream. I added this, and this seems to have fixed it. I did this for the iOS version too.

2011-06-12:

* Made the particle system, both for iOS and PC, emit particles at a frame-independent rate, emitting more particles during low frame rates, to make up for all of the particles that were supposed to be emitted between the current and the previous frame, to make the stream of particles look smoother even during times of low framerate. This did, however, end up in a little drop in FPS overall for the iOS version.

* The profiler helped me realise that the messaging system of Objective-C is actually quite slow, and so I tried to remove any instance of value assignment through usage of messages in real-time, replacing them with statements directly modifying the synthesised members (for example replacing a line like [image setOpacity:x]; with image.opacity = x;). This did give a small FPS increase.

* Removed some of the functionality from the particle system for the iOS version; changing opacity or scale is no longer supported, but constant scale and opacity can still be set. It still looks very nice. I also added support for a flag for particle systems to recycle their particles, meaning that they only create new particles until the limit has been reached, and then just keeps resetting each particle as it dies. This works well for static emitters, such as those creating the wind streams of fans, but less so for moving emitters, like the one spurting foam out of the moving bottle. The flag is thus not used for the latter one.

* Found out that the Cocos2D call nodeToParentTransform of the CCNode class is a slow call. I went into ccConfig.h to set the defined CC_NODE_TRANSFORM_USING_AFFINE_MATRIX to 0, and also made sure to call setDirty:NO before each call to transform before drawing a sprite. I also pre-stored every value I would need, returned by boundingBox, as this function calls nodeToParentTransform. This resulted in a few more frames per second.

* Added a flag to set whether to bind the texture with OpenGL before drawing to the sprite, so that when I'm about to draw the same sprite several times, I only bind the texture once, and not for every re-draw. This increased the FPS even more.

[Erik Schröder]

Bottoms Coming Up!

Chapter One: Parte Prima

Hi, Erik here. I'm the official noise maker (among other things) of Royal Railway and this project. We thought we'd start posting some episodes (currently in text form) where we want to tell you how we made the world's greatest demo for the world's greatest game. We'd like to call this series "Bottoms Coming Up!" It'll of course not end with these few text-based chapters, but through the entire time until release. We'll also start making some "making of" videos in the near future. I thought I'd start by telling you how I made the music, since it's obviously the best part of the game.

I had a real hard time getting started with the music. Before the game was even a game in any form, I had misunderstood Adam's vision – I thought that it was supposed to play like a Shoot ‘em up, but without the shooting of course, so I had some adventurous music in mind. I had come up with two songs (which sounded a lot like "Super Mario Galaxy") before I learned how he'd originally thought the game would be like and I became sad.

Adam sent me some music samples from "Super Meat Boy" - I disapproved. Nah, the game had a cosy wintry theme so I wanted the music to match that. Keeping in mind that the game is time-based and very frustrating at points, I didn't want the music to contribute to even more stress, but at the same time it couldn't be too calm either. I tried to think about games with similar music of what I had in mind and I immediately thought of "Yoshi Touch & Go" for the Nintendo DS.

I decided to actually steal the rhythm of the "Sky Area" song and even the instrument of choice for the part that was supposed to drive the song (though in the end I did split this part into two different instruments). The first draft of the song is available beneath marked "Version 1", but Adam thought it sounded too "happy", so I changed an F# note to an F note and voilà; I could change the song to a minor key, second draft is marked "Version 2". I made these snippets quickly in FL Studio on my PC (which I use for regular use) because I was too lazy to start up my MacBook Pro.

Version 1
Version 2

Since I'm Mr. Lazy, it took a couple of weeks before I finally opened up Cubase on my Mac and actually start producing my music which had already been finished in my head for quite some time. I find the hardest part to be selecting the instruments and make the "foundation" sound good. I probably spent a few hours with just the accompaniment (the guitar and the bell sound). Then it was time to choose the instrument for the main melody. Originally, I had music box in mind (tee-hee, "Yoshi Touch & Go"), but I went with flute instead. Although, I did get a music box in there somewhere! Well, to be politically correct it's a glockenspiel.


The flute.

One of the things I like the most about the song is the bass, which was heavily influenced by the bass in "Dragon Roost Island" from "The Legend of Zelda: The Wind Waker", Yes, to summarize – this song is just one big rip-off, but since it's awesome – it doesn't matter.


The bass.

If you are interested in what I used for the making of this song, here's a list:

Music & Audio Software
Cubase 5.5
Adobe Audition 1.5*

Virtual Instruments
HALion Sonic (Bright Acoustic Steel, Crystal Bells, Big and Silky, Glockenspiel)
HALion One (Percussion, Acoustic Bass VX, Expressive Flute, Latin Percussion)
Battery 3 (Basic Kit)

* I used Adobe Audition to do some post work on the audio file such as normalizing, boosting and limiting. Since then I have upgraded to both Adobe Audition CS5.5 and Cubase 6.


The entire project.

The Final Product
Bottoms Up!
Bottoms Up! (Alternate)