This is a post about a gameplay-element that affects how game objects can be triggered on a certain “heartbeat”. This relative simple component brings some interesting features.
I created a code component that can be used in Haxe Flambe framework. Flambe is a 2D game cross-platform (HTML5, Flash, iOS, Android) gaming engine.
The idea of this component is that all objects in the game listen to a global heartbeat and respond to it. Think of a rhythm in music, where elements are triggered at different notes in a beat.
I used it in my game to trigger spikes and shoot bullets, but you could also use it for other things of course. The problem I first had was that platforms were added to the level on random time, based on when player y position. This causes every platform to have its own rhythm, which makes it harder to play and a bit unpredictable for the game player. Therefore I wanted a global timer.
The heartbeat component
How to use
If you put the heartbeat in the game container Entity, you can access it from the game objects using the owner.getFromParents function (new since flambe 4.1)
I added a value called beats per minute that defines the speed. The higher this value, the shorter the delay between each beat. A nice thing about is that you can change it because it is variable. In my game, I raise the heartbeat slowly, to make the game more difficult when the player gets further. When user gets very far, cannons shoot with very short delays and spikes come up fast; the player has to react very fast. That is a cheap but very effective way to put some progression in a game ๐
You could also use this component to sync your game somehow to music, if you can determine what the beats-per-minute (bmp) is. Or you could even use it to play own samples to make simple music or compose beats.
Quite proud of our latest MediaMonks game for Guerlain, a platformer game for mobile. Build using Haxe and the Flambe framework.
The goal of the game is to collect coins, avoid the obstacles but also to impress the girls, since you’re the ideal man.
It was very fun to build this game, there were some interesting parts to work on. We decided to use small level parts, sort them by difficulty, and wire them randomly to each other. This allows to create some make it harder the further you walk. I created an own editor where the level designer could move and save the boxes while playing. This helped to create lots of nice and tested level parts in a relative small amount of time.
I also created a camera system from scratch that allows me to zoom, follow a target, lock to certain area, give some offset. I can also control it’s speed to reach the target. In the game the camera moves and stays on certain level part to give the player room to reach the end of that part, then slides to the next challenge.
An interesting part was dealing with the amount of assets and spritesheets. All the animations are created in Adobe Flash, converted using Flump to a GPU-ready format, since Flambe uses Stage3D. The game is endless and the background slowly transitions to different themes, there was no room for in-between loading of new asset packs, all stuff should be loaded at start. I had to optimize every asset if possible, while keeping good quality.
I recently created + launched my own game, “The FireFly Game“. This blogpost is about the deploy process of my first very own game online, Android, iOS and even on FirefoxOS.
Android
Building the Android app I created the game using Flambe, which has a target for Android. The Android build is done via Adobe AIR. Since Flambe uses Stage3d (GPU accelerated) for rendering, the Android version works very smooth, even on the older devices I tested. From command-line users can call ‘flambe build android‘ to get the Android application package file (APK). Since I’ve never developed an app, all things were new. Android allows you to put the .apk on your website, download and install it from there. But you can also run ‘flambe run android‘ which removes the old build, and installs the new build. This works when you have “USB debugging” enabled on your Android device. To use native features from the phone, you can use Adobe Native Extensions (ANE). I found a lot of Native Extensions on AS3 GameGears website, and I just tried some out to test it. The ads and the vibrate are Native Extensions. You can use them by copy/paste the .ane (and optional the .swc) file to the ./libs folder of your Flambe project. Most have some sample code in Actionscript 3, but the code instructions for Haxe are almost the same; I found most examples are copy/pastable. A funny thing I noticed, Haxe supports .SWC for the Flash target out of the box. The AIR Developer Tool (ADT) is using the .ane files when Flambe instructs Adobe Air to compile the Android App.
Publishing the Android app Publishing went pretty convenient, you have to buy and create a developer account using Google Wallet. You need a creditcard for this. It takes half a day or so after registration to have an activated acount. The process to upload the .apk is also pretty straight-forward. While building, you need to add an ‘id’ in your .yaml file (the flambe project settings file). This identifier will be used in URL in the Play Store. Make sure it’s unique and correct. I used ‘nl.stroep.games.firefly‘ for this, I found Adobe exports it as ‘air.nl.stroep.games.firefly‘. Well just make sure you have set the right id, name and description and version in the .yaml file of your project, this is all visible data in Google Play. You’ll need to create a set of screenshots too. Once you uploaded and put all the info in it, you’re ready to publish. It takes a couple between the publish and when its actually in the Google Play Store and come up in the search. Android download link: https://play.google.com/store/apps/details?id=air.nl.stroep.games.firefly
Web version
Deploying this one was as simple as uploading it to my FTP-account. I added Google adSense for ads to it. I found the web-version already works pretty good on mobile, but on desktop it also works very smooth. So to have it running on all devices it wouldn’t be necessary to build the app versions (hmm.. this makes you think ๐ ).
In this version I am using Google Analytics to track some events. Some funny average stats I can share (likely will change over time): – People seem to play it about 9 times in a row – The average score is 13, but the average highscore is 57 – 15% of the played games result in a new highscore – One person seems to own a DIAMOND medal (tell me who you are!) – Almost the same amount of people played the webversion on a tablet as on desktop Measuring some stats is a great way to have some insights on how people play, and it’s fun to see those numbers.
Deploying on Firefox OS
This was very fun. Firefox OS uses HTML5, Flambe uses webGL where available, with 2d canvas as fallback. Before Flambe 4.0 was released, there was an experimental build in Flambe to build for FirefoxOS. I directly tried it out, to see if it works and if I could add The Firefly Game to that store too. Now Firefox is a supported target of Flambe. Firefox OS is a Linux-based open-source operating system for smartphones and tablet computers, developed by Mozilla (of course).
Firefox (the browser) has a very nifty tool called the App Manager (about:app-manager), to debug and preview your game, it simulates almost the whole phone. You can open the App Manager in Firefox when navigating to extra > web developer > app manager from the top menu (if you’re not seeing the top-menu, press the alt-key once). In the App manager you can add a packaged app to test your game. The package needs to point to a folder on your computer. Then you can run the FirefoxOS emulator. Your app is automatically installed, and when you update your local game, you can update the game in the simulator from the App Manager.
Publishing to the Firefox OS Marketplace The process went pretty smooth. Like Android, you have to fill in the details inside the project .yaml file. These settings are using in the build manifest file, which is created by Flambe. If you want to use specific features of the phone, then read about setting permissions, which need to be set in this manifest file too. Once you have the app tested etc, you have to create a .zip file manually of the build/firefox folder content. You have to create a developer account, then you can add your new app. The app will be reviewed manually by a human. This review happened amazingly fast. I got rejected the first time within an hour. Via Bruno Garcia, the lead developer of Flambe I had some contact with an evangelist at Mozilla. We fixed some small issues together, then it was ready to upload again and it got approved.
This was a hardest one. Mostly because I don’t own a Mac. Luckily a MediaMonks colleague helped me with the whole process. You have to create a developer account, and then find your way to the iOS Provisioning Portal. Once in the iOS Provisioning Portal, you have to grab the development and distribution certificates and provisioning files. These files need to be placed in your ./certs folder of your project, and should be named exactly ios-development.p12 and ios.mobileprovision. To test your app, you can register your device in this place too. I had to hack in the Flambe build process to use the correct password. In the ./ios folder of your project (create if it doesn’t exists), you have to put the splashscreens for your application:
Filename:
Dimensions:
Default.png
320×480 px
Default-Portrait.png
768×1004 px
Default-Portrait@2x.png
1535×2008 px
Default@2x.png
640×960 px
Default-h568h@2x.png
640×1136 px
Another note, I had to use the latest beta Adobe AIR SDK (version 13), because in the upload process I got this error: “This bundle is invalid. New apps and app updates submitted to the App Store must be built with public (GM) versions of Xcode 5 and iOS 7 SDK. Do not submit apps built with beta software.” Very funny message, because I was using the official AIR SDK, and switched to a beta version ๐
Publishing to the App Store You will need to start an account with iTunes Connect. Add an app by going to “Manage Your Applications” in your iTunes Connect account. You have to fill in all the details (screenshots and details) before you can actually upload and submit the app for review. Uploading the .ipa also requires a Mac, you need Application Loader to do the actual upload. Then its up to the approval process!
I noticed Apple uses the name you used for paying the subscription as seller name. This is pretty stupid, since I used my brothers creditcard to create the account. On other places I use my own name, so I’m not sure why I ended up with the wrong name. After a search, I found you have to contact Apple iTunes Connect support to request a name-change.
I think it was a great journey to develop a cross-platform game using Haxe and Flambe, and learn how the publishing part works, and to get some nice feedback of real people. Now I have some more experience, I can focus on other fun games.
I recently created + launched my own game, “The FireFly Game“. This blogpost is about the process of creating my first very own game on different platforms, and all things that I noticed before, while and after creating it.
It started with the #flappyjam
The idea of the game was to have a case to deploy on as much platforms as possible, using the Haxe framework called Flambe. I am (like much other developers) very inspired by Flappy Bird. I found this addictive gameplay very interesting, but I also was amazed by the story of Dong Nguyen (the developer). So my game started as entry for the #flappyjam. I named the first version ‘The Flappies’, you can play that version over here. This version was developed rapidly. I found people liked to play it, but because it looked too much like Flappy Bird (even though I created all assets myself), I felt it needed more personal touch and look.
Introducing The Firefly Game
Instead of a bird that avoids pipes, I used a firefly that was flying in other direction, that avoid birds. I liked the idea of giving every character a name, a simple pixel animation and a bit of back-story to make it more alive. Because, who doesn’t like Oinky ๐ I also created a night scene pixelart theme, where the bright characters have a nice contrast.
The level is the same, every time. And it’s infinite. I used a seeded random from Flambe for this, it uses the same random principle as I described in this blogpost. I found it is a nice twist to have a level that you can learn, where you can become better every time. People are surprisingly great in remembering this pattern. When my colleagues where testing, they slowly got a better score and enjoyed that competition. Later I also added medals. You can see how much medals you’ve earned in the end page, but you don’t see the medals you did not earn yet, so there is a little mystery in it. You can share your current score on Twitter or Facebook.
I tweaked a lot on the hit-boxes since the first version. I found people were irritated when the hit-box did not feel correct. At first the bounding-box of the images was used, but after some iterations I made them a lot smaller, I found now its more up to the skill of the user and that feels more fair. I also altered the jump and moving speed a few times, I wanted it to be doable fast, so I moved the camera a bit to the right so you can see more, instead of having all centered.
Making games is about money?
One thing I notices is that people think you build game to earn money. It’s not a complaint, but I noticed this very often. People ask how it’s going with the game. Mostly they mean to say; how much did you earn. It’s a Flappy Bird clone and the original game was lucky (?) to earn a lot of money, so I understand (in a way) people think this is my goal too. But it is not my intention. Imaging you created a very nice painting, and people ask how much its worth and if its already sold. It sometimes feels like a bummer because painting is a fun process and mostly the story is worth more than selling the final product.
But you added ads, the goal is obvious
Yes, I added ads, but thats mostly because you have to pay $25.00 USD to publish on Android, and โฌ80,00 to publish on iOS. I have to invest to make use of the marketplaces and this is a simple way to get it back. I found that in this tempo, I’ll not have this investment back at the end of the year, so maybe in the next game I use something smarter to earn the money back. But again, this game for me is not about earning money. The things I learned is way more worth for me. For me the goal is to develop a game, taste a bit of the world of gaming by deploying it on some targets, and discover what it takes to make people have fun playing and how to get attention. All this stuff is important knowledge for me, because I want to try to be a better/game developer. And games should be about fun.
So how cross-platform is Flambe?
Flambe supports is HTML+Flash, and uses Adobe Air for app development. In the HTML version, WebGL for very modern browsers, 2d canvas as fallback. This 2d canvas is very fast, even in the mobile browser on low-end devices. The Flash is using Stage3D, all stuff rendered on the GPU. This Flash build is used by Adobe AIR to compile the Android and iOS version. Since it’s using Stage3d, that also renders lightning fast. Compiling takes some time though, especially building iOS is very slow.
For this game, I added 2 native extensions, for the ads and for the vibration. Beside that, I did not write anything device- or platform specific code. Overall my experience is that Flambe renders very fast and my case to prove you can deploy on multiple targets (without too much hazzle) made me happy.
If you write a lot of JSFL scripts, it could be useful to have good code-completion. FlashDevelop has great Haxe support, and Haxe can compile to Javascript. JSFL is Javascript, so we can simply conclude you can create JSFL with Haxe out of the box, and have code completion on it.
I created a Project Template for FlashDevelop, check it out:
.. displays console logs and javascript errors in a div on top of your site. Useful for mobile webdevelopment. It is enabled very fast. Works on every device and should work in every browser.
I found debugging is a bit hard on mobile devices since there is no magic button in mobile browser to see the console logs or javascript errors. Adobe Edge Inspect is not available for every browser and other remote debugging tools are also great but takes some time to setup or are not accurate. You just want to log and see what that browser on that device says.
What does it do?
It overwrites console.log, console.info, console.debug, console.error and window.onerror and displays the input in a newly created div on top of your site.
How to use?
Add this piece of code somewhere in your html-page. In the <head> before other <script> tags is probably the best place. Save document, refresh browser.
Flambe has a nice specialized component called SpeedAdjuster. It adjusts the update speed of an entity (and its components and children), and can be used for slow – motion and fast forward effects.
Sometimes it helps to see things at very slow speed. You can use the SpeedAdjuster to debug your game. I wrote a function that gives you control over the speed using [ and ] keys on your keyboard. // press [ or ] to decrease or increase speed. returns SignalConnection function addDebugSpeedAdjuster(entity:Entity) { if (!entity.has(SpeedAdjuster)) entity.add(new SpeedAdjuster(1)); return System.keyboard.down.connect(function(event:KeyboardEvent) { var speedAdjuster = entity.get(SpeedAdjuster); if (event.key == Key.LeftBracket) { speedAdjuster.scale._ /= 1.61803398875; trace(“Speed Adjuster scale: ” + entity.get(SpeedAdjuster).scale._); } else if (event.key == Key.RightBracket) { speedAdjuster.scale._ *= 1.61803398875; trace(“Speed Adjuster scale: ” + entity.get(SpeedAdjuster).scale._); } }); }
If you want to use it in debug-mode to control the entire speed of everything, you can use it like this. #if debug addDebugSpeedAdjuster(System.root); #end
Of course, make sure all your components make use of the deltatime from the onUpdate function.