So even though I wasn’t planning on it, I just published yet another minor update to Beats 1.x as Beats 1.7.5b. Changelog? Added Amazon Fire TV support (Beats-style only), add more speed multipliers, removed AdMob, and fixed a few crashes. Interesting, not-so-obvious question: What do all these changes have in common? Answer: They are all related to the problem of Android fragmentation. Actually, so was most/all of the changes in Beats 1.7.4b and 1.7.3b. So here’s a rant about why.
How fragmentation lead to Beats 1.7.5b
Lets look at the root causes of each of these changes and how they relate to Android fragmentation (we’ll get to that topic later in this post). Note that some of the exact version numbers and dates may be off since I’m recalling everything from memory, but the sediments and reasonings should be more or less accurate:
Amazon Fire TV
The Amazon Fire TV has two sources of input: the game controller and the remote. Note that a few years ago, Android did not support TVs, or non-touch/non-mouse devices for that matter. As such, Beats was developed with the assumption that a touchscreen was always available (in actuality, Beat 1.0a to 1.4b supported keyboard input, but when I revamped the graphic and touch input routines in Beats 1.5b, I dropped it because it was a pain maintaining and the Android emulator was getting more and more unbearable to test with). With the Amazon Fire TV (and supposedly more future mainstream TV devices running Android but without a touchscreen), that previously safe assumption was broken. Now while I could have just said “meh, no support, oh well”, one loyal user with an Amazon TV reached out and volunteered to help with testing. Plus, I was pretty curious myself despite having no plan on getting one.
So after doing some documentation reading and some ugly hacking around with the 2-year-old Beats source code, I got D-pad support working via Android emulator. Thank goodness I upgraded my computer a few months ago because I’m 99% sure my old laptop wouldn’t be able to handle the 4.4 Android emulator, even with Intel’s HAXM acceleration enabled. Of course this change doesn’t really add anything to the majority of my users (manufacturers have stopped releasing Android phones with D-pads/trackballs for quite some time) and I don’t plan on releasing Beats 1.7.x on the Amazon store (which is quite a lengthy, bureaucratic process), but it was nice to know about and just taught me to not be surprised when even the most basic of assumptions get broken in the Android world.
This is an interesting topic. When Beats were first being developed, there were no such thing as Android tablets. In fact, there wasn’t so much a mainstream consumer concept of a tablet at all (other than Wacom drawing tablets and extremely expensive pen tablets running Windows and used mainly by rich students/businessmen for taking notes). Thus, it was assumed (again, a relatively safe assumption back then) that phone physical screen sizes would more or less stay the same (maybe just increase in DPI). Given such, Beats’ speed multiplier was based purely on unscaled pixels (pixels per millisecond). The reasoning behind this was that, given two similar-sized devices held side-by-side, arrows would fall at the same pixel speed downwards (not a good reasoning today, but was the best choice back then). When Android tablets started popping up featuring Android 3.0, the speed multiplier algorithm was updated to multiply by the screen size category (Small, Normal, Large). And then Android introduced the concept of screen size vs screen DPI, and then it went downhill from there.
Suddenly, all sorts of combinations were popping up from various manufacturers. xxhdpi x Normal, mdpi x XLarge, hdpi x Large, etc.. Any previous assumption about the display dimensions and physical size had been broken. I could have easily changed the speed multiplier logic to use scaled pixels instead of unscaled pixels or done something related to the physical size of the device’s display, but the last time I made a speed-multiplier-related change (in Beats 1.6b I think?), users were confused and massively complained so I reverted the change. Recently, some of the new Samsung Galaxy Tabs released have huge 10.1″ screens and are running hdpi or even xhdpi resolutions, meaning unscaled pixels per millisecond would be slow. Not wanting to deal with the massive user confusion/complaints about changes to the fundamental mechanics of the game, I decided to just throw in a few speed multipliers. Next time around, I’ll know better during the designing phase.
I added AdMob integration early on back before it had been purchased by Google. The initial reasons I added AdMob integration were: 1) it was really easy to do, 2) it helped me learn about integrating third party plugins and APIs, and 3) it kept Beats free and gave me a bit of pocket cash for all the work I put in (as much as I hated ads, I was a still a poor college student). When Google bought AdMob, they promised they would keep the service as is and maintain it. Which they did nicely for the next 4 years. Until very recently when they dropped the “upgrade to our new Google Mobile Ads SDK or else” bomb. And so I said why not and as part of my 1.7.3b update. But then in came the crash reports and user complaints. “App crashes on launch”, “app blackscreens with no response”, etc. Previously, AdMob was an independent library (a simple .jar that gets compiled in), but the new Google Mobile Ads plugin communicates with Google’s system services, which is supposed to be implemented and running on all Google-approved Android devices. Except it looks like it wasn’t, or at least not cleanly.
Looking through the crash traces, looks like a lot of random devices were getting permission or access errors relating to Google services, especially older devices. Searching around didn’t do much help, so I just threw the AdMob initialization code in a simple try-catch-swallow and that worked in Beats 1.7.4b. For the most part. Turns out, many Android 2.2 devices don’t even have such a kind of service, so I’d actually have to remove the references from the layout XMLs. Not wanting to deal with so much forking, I decided to just completely remove AdMob in the new Beats 1.7.5b. No more ads finally, yay! Though that does lead to the despairing question, why are people still using Android 2.2 phones… (more on that later in the Beats usage stats breakdown section).
During the initial development of Beats 1.0a, Matt and I had a brief discussion on whether or not to use Android’s native Canvas drawing routines for our custom graphics or to use the (mostly incomplete at that time) OpenGL drawing routines. Given that this was during a hackathon and the documentation for Android’s OpenGL ES port was very, very lacking, we opted for native Canvas drawing on a simple blank View which we know would work. Far from optimal, but okay given the simple graphic demands of Beats. And it did for a good long while and stayed that way until Beats 1.5b. Sometime before 1.5b, manufacturers started releasing new devices with larger screens and I started noticing significant performance hits with drawing on a standard View (ie. under 30fps). Digging around the (very lacking) documentation, I discovered that some of the SDK samples instead used SurfaceView for their drawing. I tried it out and suddenly, bam, a solid 50+fps everywhere.
It was great and I thought that’d be the end of it. But then came Android 3.1 Honeycomb, where hardware-acceleration support for drawing was introduced (phones and tablets were starting to get dedicated GPUs, gasp!). OpenGL ES drawing would gain the most benefits but GPU acceleration was also promised to be ported over to standard views as well (I was also in no rush to yet again rewrite all the graphics-related code, which had become quite an unrecognizable mess by that time). Testing on the few tablets I could get my hands on (eventually bought a Samsung Galaxy Tab 7″ just for this), Beats still ran reasonably well (~45fps), so I figured I’d just go and do nothing, as I’ll eventually get GPU acceleration for free.
Turns out, this would never happen. I kinda got more and more surprised when I started hearing users report that they were getting low framerates on the Samsung Galaxy S4 (top-tier phone at that time with a powerful GPU), but I didn’t have access to any of those devices so didn’t really act upon it. Only recently when I migrated Beats’ source code to Github did I decide to take a closer look and was quite surprised. Indeed, Beats was struggling to run at 30fps on the Galaxy S4 even with multiple settings turned off, and there was definitely no CPU bottleneck anywhere. Profiling told me that the problem lied in the SurfaceHolder.lockCanvas() which was returning extremely delayed. I was expecting a slightly slower response due to the larger screen compared to my older smaller screened phones, but not on the magnitude of a few hundred milliseconds.
So once again, I dug through the documentation, only to discover that apparently Google had no plans on supporting hardware acceleration for SurfaceView. So funny enough, the old slower regular View, if hardware accelerated, is now faster than the non-accelerated SurfaceView on some devices. And so, in Beats 1.7.3b, I added a new setting which would check if hardware acceleration support was available on regular Views and if yes, use the old pre-Beats 1.5b code instead of SurfaceView.
That fixed things for most devices, but I suddenly started noticing a new never-before-seen crash: “java.lang.UnsupportedOperationException in android.view.GLES20Canvas.clipPath”. Turns out, the clipPath call used for Hold notes is not guaranteed to be supported with hardware acceleration up until Android 4.3 (API 18), and I definitely saw it working on some less-than-API-18 devices I tested on. Oh, yet another case of inconsistency/fragmentation across devices. And so in Beats 1.7.5b, I threw in a simple try-catch clipPath check in the hardware acceleration setting logic. Far from a proper, clean solution, but keep in mind Beats 1.7.5b was never planned to happen in the first place…
How bad is this Android fragmentation?
Simply put, it’s still pretty bad. As of the moment, we are currently on Android 4.4 (API 19), with Android 5.0 on the horizon. That’s an entire 19 API updates, covering 9 different OS names (ignoring Android 1.0 and 1.1). Beats was first started back in 2010 when Android 1.6 was still the most common Android OS version and Android 2.2 was just starting to appear on new phones. The initial release of Beats supported Android 1.5 (API 3) and up. The normal trend with version numbers of actively developed software is that of a steady upward trend, with most users on the latest versions and little or no users on the earlier versions. Except in reality, this is not the case.
OpenSignal did a great numerical analysis and report of the Android fragmentation issue using real data collected by their apps. Below are some screenshots of their July 2013 report, alongside some of Beats 1.7.x’s data from Localytics and Google Play.
“Don’t worry, lets just pick the top 5 most popular Android devices and we should be good!” Think again. A general good rule of thumb when it comes to software development is to go to where the users are. Build, target, and optimize for the most popular configurations such that the majority of users will have the best experience. Once you’ve chosen your targets, optimizing and testing becomes much easier. Unless your targets don’t actually represent the majority. Which happens to be the case for the Android ecosystem. Even totaling together the top 10 most popular Android devices will just barely cover a quarter of the market, with the top device (the Samsung Galaxy S3) not even accounting for a double digit percentage.
For Beats 1.7.x, it just barely reached 5%. You can try to be “smart” with your strategy all you want, but at the end of the day, there’s really nothing much you can do other than “just throw more money at it”. Unfortunately, for indie developers like myself, that isn’t an option. With only an LG Spectrum 2 in one hand (not-at-all popular, low-tier phone) and a Samsung Galaxy Tab 7.0 (a first generation Android tablet that struggles with the web browser) in the other, I can only blindly hope my changes and bugfixes work every time I push out a new release. Either way, if you were previously dreaming of a world where your app runs perfectly on all these hundreds of different devices, I’d recommend you give up now. I did at least, for now…
For Android, brand usually implies system-app level changes and UX changes. Each manufacturer and carrier will do their best to push onto users their unique/modified version of every core app (think email, messenger, photo gallery, camera, etc.) that may not always adhere to the same expected contracts that the stock apps follow. As you can imagine, trying to call intents to and from other system apps can be a pain when you have no guarantee what the resulting behaviour will be (works, fails, or maybe even a crash).
But looking at the chart, it actually isn’t all that bad. In fact, brand fragmentation is the kind of fragmentation you’ll be most thankful of (not being as bad as the others). Over half the market runs Samsung hardware and Samsung hardware. That means you can expect some kind of standard set of hardware features for at least 50% of your users and also that 50% of your users are running some butchered version of Android bloated with TouchWiz. Well, 50% is better than <10% at least. Thankfully, Beats doesn’t really have any external requirements (i.e it’s more or less a standalone app that doesn’t interact much with other system apps) so I actually haven’t run into this issue very often. That said, just the fact that I don’t own a Samsung phone puts me in an annoying hard spot, especially when I see comments like “why does Beats suck so much on Samsung device XXX?” (which was the case with the Galaxy S4 and lead to the hardware acceleration change above).
OS fragmentation is arguably an Android developer’s worst nightmare. Most bugs/changes are due to changes/discrepancies between Android OS versions. One bug in one OS version might get fixed in the next version, and one crucial feature might only be available on the latest OS version. If you are developing for iOS, great! Over 90% of your users are running the lastest OS, so you can rest easy and target that, knowing that eventually those on older versions will upgrade (or just not care enough and won’t actively use your app anyway).
But Android is a completely different story. Over the past 5 years that Android has been in the market, There have been a number of distinct “eras” – Android 1.0/1.1 (no codename), Android 1.5/1.6 (Cupcake/Donut), Android 2.1/2.2 (Eclair/Froyo), Android 2.3.x (Gingerbread), Android 3.x (Honeycomb), and Android 4.x (Ice Cream Sandwich, Jelly Bean, KitKat). Each of these eras signified drastically different feature changes as well as hardware changes: Cupcake/Donut was a hybrid of old dumbphones with QWERTY keyboards and trackballs, Eclair/Froyo was the first real generation of touchscreen-only phones, Gingerbread was the start of real “smartphones”, Honeycomb was the introduction of tablets, and ICS/etc. was the start of the unification of phones, tablets and recently “phablets”.
So logically, everyone should be running 4.x right? Unfortunately, wrong. With Android 4.x came the introduction of minimum hardware requirements (finally, thank you Google!) and a list of minimum features requirements. Tablets were still relatively recent and met hardware requirements so most got 4.x upgrades. For phones however, instead of bumping up the standard, there was a long period where manufacturers opted to keep releasing new devices with older OS versions (most likely due to cost reasons) and at that time, Android 2.3.x was still the “golden” OS that worked and worked well. Not to mention, unlike iPhone users who happily throw money at the newest generation iPhone every year, Android users were more or less happy with what they had: a working phone running a solid OS that could run apps and, you know, make phone calls.
There was no reason to throw away perfectly fine hardware, and that’s what many users did. In fact, a good 20+% of them, who even today continue actively using their phone and play Beats 1.7.x. That percentage will never increase of course and will only go down over time, but as OpenSignal’s trend graph shows, it won’t be disappearing any time soon. Which sucks, because both my devices run 4.x either – Android 4.1.2 stock on the LG Spectrum 2 and CyanogenMod 9 (based on Android 4.0.4) on mthe Samsung Galaxy Tab 7.0. That aside, the fact that there are still Beats users running Android 1.5/1.6/2.1/2.2 worries me… If you are one of those people, please please consider upgrading your OS (or installing CyanogenMod if possible) or buying a new phone.
Now Android fragmentation has long been (and still is) a frustrating challenge to developers. And actually, it’s not just an issue for small indie apps like Beats that only get an update here and there whenever I happen to have the free time. It’s a major maintainability and costing issue for any company developing mobile apps for Android. Earlier this year, my team at work made the decision to raise the minimum OS requirement to Android 4.0.3 (API 15) because the cost of testing and backporting new features was far too great. And to be honest, even though the percentage of Android 2.x users out in the market is still a significant 20+%, it’s a declining percentage. Sure, one can throw more money at the problem and buy more devices or hire more developers to ensure all features work nice and smooth on that dying 4-year old Android phone running Froyo or Gingerbread, but is it really worth it? Why not just spend that effort focusing on adding more new features or whatnot? For an indie developer like myself who works on Beats alone and doesn’t even own any Android device under 4.0, it makes even less sense. The trade-off just isn’t worth it.
So does that mean I’ll be dropping Android 2.x support for Beats 1.7.x? No, simply because it already mostly works and I’d hate to be a jerk to that loyal 25% of my users. I recently dropped support for Android 1.6 (API 4) when upgraded to the newest set of Android SDK+tools package – there were so many errors and warnings that I honestly didn’t want to spend the next 2-3 hours debugging legacy code from Beats 1.2b or so. After release, I did pay extra attention to feedback but seemingly no one complained, so it turned out it was a safe drop (though that worry really never should have been there in the first place).
What this does mean, however, is that with Beats2, I’m going to start being a lot more strict on minimum requirements and have them set in stone so that legacy support issues and bugfixes like Beats 1.7.5b won’t have to happen in the future. For the time being, I’m still okay with supporting Android 2.3.4 and up (the Unity 3 game engine actually declares that it supports Android 2.0 and up but I’m skeptical), but if things turn out troublesome during the initial beta testing phase, expect me to bump that requirement up to Android 4.1.2. As a single indie developer working on a game during his spare time and (ambitiously) targeting multiple platforms (Android, Windows touch+mouse+keyboard and eventually iOS and Windows Phone), sometimes it’s just better to bite the bullet and fight against the market.
While migrating a bunch of old projects to GitHub, I decided to check if the old Beats 1.x app still compiled with the latest SDK and work. Unsurprisingly, it didn’t, with tons of new warnings and errors. While cleaning up the errors, I decided to revisit some of the annoying bugs that people have been emailing, and the result is Beats 1.7.3b.
There’s no new features in this release, but there’s a few frequently asked bug-fixes/improvements. The game also now supports hardware acceleration (new setting in the Display section), so it should run at a smooth 50+fps on the Samsung S3/S4 and various other high-end devices that were somehow struggling with framerate (for the curious, this is because hardware acceleration never ended up being supported for SurfaceView). All libraries and translations have also been updated, and the Turkish language has been added thanks to Cem Filiz. Additional thanks to the Chinese Baidu/QQ group who’s constant asking of “When will Beats2 be ready” lead to this update
Here’s the changelist: Beats 1.7.3b FINAL – 
- built against Android 4.4 (API 19)
- support hardware acceleration
- fixed scoring-while-paused bug/exploit
- fixed restart on rotation bug
- fixed crash when #MUSIC is empty
- tweaked tap-registering window (early taps no longer ignored)
- added tr translation
- updated fi, pt, pt-rBR translations
- updated UHL, AdMob and Localytics libraries
Like with Beats 1.x, Beats2 has also been migrated over to GitHub. Back when I started the project, I was expecting Google Code to be The Next Big Thing (TM), but I ended up quite disappointed. While a long-term user of SVN, I decided it was probably a good time to learn and adopt git, whose forking capabilities would definitely benefit Beats2 if anyone else wanted to contribute. Thankfully, the GitHub for Windows program made it extremely painless (the last time I tried setting up git on Windows was pretty annoying).
In addition to taking care of the code migration, I’ve also recently finished setting up the new Beats2.net website, which looks MUCH better than BeatsPortable, thanks to everything I learned while building Keripo’s Corner. I’ve also gone ahead and created a new Beats2 Facebook page which I’ll be using to post more regular updates (go ahead and like it!). Unfortunately I had to close the old BeatsPortable forums due to spambots, but expect a newer and much nicer Beats2 forum to come up once the game’s ready for community discussion/feedbacks (I’ve also learned alot about phpbb over the past few months).
Otherwise, the plan for Beats2 is the same as before. I’ve more or less decided to settle on keeping the V2 design of Meiro~D for now, but theming/artwork/character designs come later. For now, it’s just time to crank out the code
It’s been a while since the last website update. Beats 1.x has hit an amazing 2 million users/downloads with an average of 9-10k users daily, so I figured I might post something. I’ve been busy with a lot of non-Beats related stuff (vacation to Japan, working at my new job, moving into a new place, playing MMORPGs, catching up on anime, etc.) so there hasn’t been much solid progress, but here’s what I have.
What is Beats2?
Simply put, Beats2 is the spiritual successor to Beats 1.x (aka “Beats, Advanced Rhythm Game”). Tentatively, it’s full name will be “Beats2, Multi-Style Rhythm Game“. The first goal of Beats2 is, like it’s name indicates, creating a rhythm game/simulator that supports multiple play styles/modes. This includes not only the DDR-style from Beats 1.x but multiple others derived from the many popular rhythm games that we all love (see below). Beats2 will not be a clone, however. Unlike StepMania, I plan on focusing more on fun, touch-focused rhythm gameplay rather than simulation accuracy (DDR is for the feet, not for the fingers!). The second goal of Beats2 is creating a multi-platform rhythm game. Beats 1.x was written for Android and ran only on Android. Beats2 will run on not only your phone, but also your tablet and your computer. If it has a touchscreen, it should run Beats2 ; ) In other words, Beats2 will be the free, open source rhythm game that will let you enjoy your favourite rhythm game style on whatever device you want ^_^
Beats2 will support the following rhythm game styles:
- Beats: This is the DDR/DJMax/Beatmania IIDX style that you are most used to. Notes falling from the top of the screen to the bottom. This was Mode #1 in Beats2 Prototypes. It’ll start off as 4-button only, but I plan on adding 5B, 6B, 7B , 8B, and even 9B (Pop’n Music) if I can design the screen right.
- Technika: This is based on my second favourite touch rhythm game, DJMax Technika. Stationary notes appearing with a slider that moves back-forth across the screen. Mode #5 in Beats2 Prototypes was loosely based on this, but I will do split screen for Beats2. 3-button and 4-button only due to screen size.
- Square: This is based on my favourite touch rhythm game, Jubeat. Notes appear at fixed locations on a grid. This was Mode #4 in Beats2 Prototypes. It will be 3×3 and 4×4 grids.
- Taiko: This is based on the fun arcade game, Taiko no Tatsujin. Streams of notes come flowing in one line while you hit “drums”. Gameplay-wise, it’s pretty much 4-button Beats, but just with a different layout ; ) 2-button and 4-button only.
- Mai: This is based on the not-well-known arcade rhythm game, MaiMai. Notes fly out from the centre of the screen to the edges. This was Mode #2 in Beats2 Prototypes. While I don’t think it was really popular as an analog rhythm game (with a very shallow learning curve too), I think it’ll work well on a touchscreen, as Beats2 Prototypes’ data suggests.
The following rhythm game styles will NOT be supported (unless enough people ask of course):
- Ouendan: This is based on the popular Nintendo DS game, Osu! Tatakae! Ouendan. Notes appear in patterns anywhere on the screen. This was kinda like Mode #8 in Beats2 Prototypes. Beats2 will NOT support the Ouendan style, however, as there is already a well established clone of the game called osu!
- Diva: This is based on the (in my opinion, silly) arcade/PSP/PS3 rhythm game, Hatsune Miku: Project Diva that focuses on VOCALOID music. Notes come flying in from all across the screen. Beats2 will NOT support the Diva style for two reasons. 1) There is already a work-in-progress simulator called Project -Project Dxxx-. 2) It doesn’t make much sense from a touch-based rhythm game perspective; the location of the flying notes have no relationship to the buttons being pressed. If anything, there’ll be plenty of VOCALOID simfiles for the other rhythm game styles anyway.
- Reflect: This is based on the recently released arcade rhythm game, Reflec Beat. It is a 2-player game where you play “Pong” with your notes. The gameplay/mechanics I find a bit confusing and it’s not well known outside Japan, so not focusing on it.
- Vortex – This is based on the recently released arcade rhythm game, Sound Vortex. It is 6-button Beatmania IIDX, but with two slider knobs. Since the slider knobs don’t make much sense for touchscreens, I don’t plan on implementing any special play style for this.
The only simfile format that will be supported initially will be the StepMania .sm/.ssc formats. This is purely because there are already many, many simfiles out there in this format. Beats2 will mainly use it’s own .ini-based format similar to osu!’s (i.e. time=note-type) designed to be flexible and compatible across the multiple styles. I may add a few format converters depending on demand, but I don’t plan on commiting to anything more than .sm/.ssc (maybe .dwi, but we’ll see).
The following platforms will be supported:
- Android: I have both an Android phone and tablet, so expect Beats2 to work on both
- iOS: Don’t have an iPhone/iPad, but I’m sure I’ll find volunteers when the time comes
- Windows Phone: Don’t have a WP8 phone, but know a few people who do
- Windows (Store): I have a Surface RT and Surface Pro, and my laptop runs Windows 8, so expect Beats2 to run on x86, amd64, and ARM
The following platforms are not planned be supported (may be depending on demand and difficulty)
- Mac OSX: I’m not exactly fond of Apple products, but if someone wants to help with the port…
- Linux: I dual-boot Linux, but this really depends on the Unity game engine’s level of support
- Consoles: I have an XBOX 360 and PS3, but this also really depends on the Unity game engine’s level of support
- Web/browser: Depends on whether or not there’s enough donations to support running the servers, but very low priority
The following are highlighted features for Beats2
- Multi-style: As mentioned earlier, one goal of Beats2 is to support multiple styles. This also means that your simfiles will be playable in multiple styles as well! The same 4-button Beats-style simfile can be played in Technika, Taiko, and MaiMai styles (Square will be a special case, haven’t thought that one out yet). Further down the road, expect a “Remix!” mode where you will be able to switch between styles on-the-fly ; )
- Customization: Who doesn’t like customizations? Expect Beats2 to allow for custom themes, custom noteskins, custom sound effects, custom backgrounds, etc. All in easy-to-edit .png/.ini file formats. Can’t figure out StepMania’s confusing theme format? Neither can I, so you won’t have to either!
- Online scoreboard: Probably the biggest feature request of Beats. Didn’t implement it back then because there were many issues with the scoring system in Beats 1.x, but Beats2 will use a revisited scoring system, so I do eventually plan on activating an online, global scoreboard.
The following are potential future features for Beats2
- Online battle: Play against your friends to see who can get the higher score, or who can screw up first from all those “Remix!” attacks ^_^ How this will work will really depend on what kind of netplay frameworks I can find for Unity.
- Song importer: After experimenting around with the Dancing Monkeys simfile generator, I’m pretty confident that I’ll be able to implement something that can generate simfiles from imported songs (e.g. MP3 goes in, Beats2-ready simfile comes out). Not sure if I will be built into Beats2 or if it’ll be a separate program or if it’ll be handled by a server, but expect something cool ^_^
- Song store: This will depend entirely on external support. I’d like to have some kind of song downloading store where you can browse and download/buy the latest/greatest songs (and have the song importer generate the simfile). Would be nice to hook up with Soundcloud, Beatsport, iTunes, AmazonMP3, etc.
- Kinect: I experimented a bit with the Kinect before. It was pretty cool, so I might try it again later. Same goes with other fun hardware – I’m always interested in hardware hacks.
- Unity 4: Rather than being written specifically for a single platform (e.g. Beats 1.x for Android), Beats2 will be developed ontop the Unity 4 game engine (currently at 4.2.0). This what allows for the game to be cross-platform as well as support a lot of other features that I wouldn’t know how to do myself otherwise.
- NGUI framework: After experimenting will multiple different 2D frameworks for Unity (e.g. 2D Toolkit, ex2D, and Orthello), I settled on NGUI, mainly because it will make developing the UI much easier and supports 2D sprites (which most Beats2 graphics will be)
- Google Code: The Beats2 source code will be hosted on Google code. The project is open source, but only the parts written by me (i.e. the proprietary NGUI libraries will need to be imported separately). Not 100% decided on the license yet, but it’s safe to assume it will be Modified BSD unless otherwise specified.
- SVN: Because I’m stubborn and because I’m the only developer for Beats2. If enough devs decide to join me later, I may move to git, but for now, sticking with good ol’ svn. Once Beats2 development reaches a beta-testable state, I’ll be using the forums for beta releases.
- Website/forums: Once Beats2 development reaches a beta-testable state, expect a revamped website and forums. The current WordPress and phpbb forums are pretty bad, I admit orz
In terms of game design, I have the game design roughly spec’d out and will be following that. Haven’t settled on the theme/graphics or default songs, but that will come much later (and will require some help from the community). Meiro~D will be the game’s mascot, though her character design isn’t finalized either xD
Meiro~D original design (V2) or newest (V6)?
Well this isn’t really a proper demo, but I might as well post something that you can try your hand at. I literally just threw together some graphics, generated a simple simfile with Ariea Creation’s “Love Is Energy (Instrumental)”, plugged in some C# code that I was already working on, and compiled for Android and Windows.
The result is what you see above and in the video at the top of this post – Beats2 Test Demo, running on my LG Spectrum 2 (Android phone), Galaxy Tab 10.1 (Android tablet), Surface Pro (Windows 8 tablet), and Dell XPS L702x (Windows 8 laptop). Here are the download links if you want to try it out:
- Android: http://beatsportable.com/static/testing/beats2td-v1_android.zip
- Windows Standalone (x86): http://beatsportable.com/static/testing/beats2td-v1_standalone-pc.zip
- Windows Store (x86): http://beatsportable.com/static/testing/beats2td-v1_store-x86.zip
- Windows Store (ARM): http://beatsportable.com/static/testing/beats2td-v1_store-arm.zip
The Windows Standalone does not support touch (Unity 4 limitation), but you can use SD-KL split or the arrow keys. For the Windows Store builds, right click the .ps1 file and select “Run with Powershell” (note: you MUST have a developer license to install/sideload apps this way). The Android build is just a standard unsigned .apk file. The source code, for the curious, can be found in the beats2n branch: http://code.google.com/p/beats2/source/detail?r=33
Enjoy and look forward to more Beats2 updates in the future!
Post your comments and feedback in the forum thread here!
Been super busy with school (just graduated earlier this year) and work (just started right after that), but I’ve finally got a break to come back and revisit Beats. Reinstalled eclipse and the Android SDK, updated a few libraries, fixed a few bugs here and there, and tested it on my Samsung Captivate (running CyanogenMod 10, nightly) and Galaxy Tab 10.1 (running CyanogenMod 9). No new features since I’m working on Beats2 now, but feel free to send me patches if you want! Here’s the changelog (note that r16 is based on the open-source code):
Beats 1.7.1b FINAL – Changeset [r16]
- Android 4.x ICS support (tested on CyanogenMod 10 nightly)
- all speed multipliers effectiveness DOUBLED, please adjust your settings!
- fixed Graphics zip delete error
- updated AdMob to v6.2.1
- updated Immersion MOTIV Haptic Effects to v188.8.131.52
- updated all translation
Post your comments and feedback in the forum thread here!
A day late but oh well. Happy New Years from Keripo!
Since the last update quite a bit has happened but here’s the rough plan for 2012. There will be two projects: Beats2: Prototypes and Beats2. In a nutshell, I decided to make Beats2 development a part of my senior design project for university (think “undergraduate thesis”), the result of which will be a paper entitled “Designing Rhythm Game Interfaces for Touchscreen Devices”. Prototypes will be a demo app that will be used for conducting a study comparing various rhythm game interfaces (i.e. think DDR vs Beatmania IIDX vs DJMAX Technika, etc.) with the results of the study and the basic game engine later being used for Beats2. A general overview of the project can be found here and the current progress report can be found here but details are highly likely to change over the course of the semester (they already have at the time of this post). Here’s a quick rundown of things:
- Beats2: Prototypes = simple demo app comparing various rhythm game interfaces
- Beats2 = full fledged rhythm game using the same basic game engine as Prototypes
- Will be developed using the Unity 3 game engine
- Unity 3 plugins: ex2D for graphics, Immersion’s MOTIV plugin for haptics, FingerGestures for input?
- Target platforms: Android, Windows, Web Player
(iOS and Mac OSX targets will depend on level of interest/testers, other targets may come later)
- Prototypes expected to be complete by April, Beats2 will be worked on after that
- Source code license will depend on plugin licenses, so project may not be allowed to be fully open source ; (
On a side note, although I have long stopped working on Beats 1.X (which was always meant to be nothing more than a small personal project for fun), the Android Market (limited) and Localytics (more accurate) reports for the past year went far beyond my expectations. Especially considering that Beats was and always will be an indie project; I’ve done pretty much nothing to promote the game so I’m assuming popularity arose from word of mouth. Here’s the numbers:
(Note: Beats 1.0b was released sometime Oct 2010 but these numbers only reflect Feb 2011 and after).
- 420k+ direct Android Market downloads
- 4.6/5.0 average rating (out of 3.7k+ ratings)
- 640k+ unique users (includes non Market downloaders)
- 5.5mil game sessions, average duration of 12 minutes
- Most users: China (44%), Japan (19%), USA (15%), South Korea (8%)
All in all, 2011 was a great year, lets look forward to an even better one in 2012!
Download (Beats 1.7b FINAL)
Facebook (like the page and spread the word!)
Beats2 (will be updated more frequently as the semester goes on)
Donate (Unity 3′s iOS license is the same price as the Android license: $400 >_<)
Post your comments and feedback in the forum thread here!
Summer ends and university starts again. With the change comes the release of Beats 1.7b FINAL, the last version of Beats, Advanced Rhythm Game. This also marks the open sourcing of Beats and the starting point of the Beats2 project!
Beats 1.7b FINAL is almost the same as Beats 1.7a-r570 (Beats 1.7b FINAL is r575). For those who haven’t been keeping up with the Google group, here are the changes since 1.6.2b:
- tablet support!!!
- improved screen updating and scaling
- modified sliders and guidelines for osu! Mod
- smarter osu difficulty selection
- custom loadable graphics
- new SM-based default noteskin
- updated with Immersion MOTIV Haptic Effects, Version 3.4.73
- more touch-friendly main menu
- rearranged settings menus a bit
- translation update
- removed MobFox
While there are still a lot of unresolved bugs and minor feature requests, I will no longer be updating Beats but focusing on Beats2 (which will be far more stable and feature-filled). Instead, I have open sourced Beats 1.7b FINAL under the Modified BSD License. The source code can be found alongside the Beats2 source code here (svn/trunk/beats). If you wish to use the source code for your own projects, PLEASE read the ReadMe.txt first. Beats2 will be a completely new rewrite and also have a desktop version as well.
For those who have troubles running Beats 1.7b FINAL due to memory issues (e.g. some older phones running Android 1.6 will force close due to a RAM-related graphics-loading bug), you can always download older versions here. Otherwise, hope you enjoy the final release and look forward to Beats2!
Post your comments and feedback in the forum thread here!
To start off, it seems that sometime earlier this month, Beats hit 250k downloads on the Android Market! (this doesn’t include downloads from the Downloads page and other locations of course). So here’s the obligatory thank-you picture!
While I’ve been quite busy over the summer with work, I did manage to get my hands on a new Samsung Galaxy Tab 10.1 running Honeycomb (3.1). Which means, yes, the next release of Beats will support tablets! In addition to hacking around to allow for proper scaling, a few other changes have been made in the development build, including customizable graphics (new StepMania-based noteskin is used but the original graphics are still available), updated UHL (vibrations will hopefully work now on more devices), and work-in-progress sliders on osu! Mod! Check out the demo video below:
Beats 1.7b is planned to be released sometime before September, but you can get the latest development build from the Google groups link below. Make sure to keep check with the Changelog page to see what to expect in Beats 1.7b. Don’t forget to visit the Translations page to help make sure Beats 1.7b will be fully translated into your language!
Look forward to the next release!
Post your comments and feedback in the forum thread here!
UPDATE: Demo video and full report released and new downloads available. See here for more details or see below:
Finished up writing the full report with instructions, etc. Includes all relevant documents, source code modifications, photos, and of course a video of the actual demo ; )
For installation instructions, download all the files in the “install/” folder and skip down to “5. b)” in the report.
For the final project of one of my classes, I modified Beats so it would take input from an XBOX Kinect. The result is a Kinect hooked up to a Beagleboard-xM running Android and playing Beats. It was all proof-of-concept of course as everything ran with extreme lag, but it was pretty cool nevertheless and fun! Here’s a pic of my lab partner mastering Tetris (Rock Version) on Beginner:
More pictures are posted posted on the Beats facebook page here!
For more info, see the (currently still being updated) blog here. The modified, signed APK can be downloaded here. The patch file (for inspection-purposes only) can be found here. The modified ofsample demo used for calibration can be downloaded here. The (possible?) source for the demo can be found here. Make sure to recompile your Beagleboard’s Android kernel with ‘CONFIG_USB_DEVICEFS=y’ and add ‘mount usbfs none /proc/bus/usb -o devmode=0666′ to your init.rc file as per instructions found here.
Post your comments and feedback in the forum thread here!
To deal with managing the various translations/localizations of Beats, I have uploaded the strings to crowdin, a collaborative translation tool that supports Android.
If you are interested in helping out with the translations, please visit that site and start translating! In particular, I am strongly looking for someone to help out with Japanese translations. Once translations are complete, I will release a quick Beats 1.5.5b update which will include some of the updates on the Changelog page (particularly a setting allowing you to explicitly change the game language).
As always, make sure to join the Google group to keep up with updates. Happy translating (and happy Easter to those who celebrate it)!
Post your comments and feedback in the forum thread here!