Making cell phone games?

Discussion in 'Game Development (Technical)' started by Infinite Element, May 21, 2008.

  1. Infinite Element

    Infinite Element New Member

    Joined:
    Jun 3, 2007
    Messages:
    70
    Likes Received:
    0
    I recently decided I want to make a game on the cell phone, but I can't find any resources by searching on Google (they must be hiding). Can anyone point me in the right direction?

    Thanks in advance.

    P.S. If you wanted to make a game for phones across all networks, how many versions of the game would there be? Just one for each screen resolution (that phrasing seems to downplay it a little...), or do the networks matter also?
     
  2. hooble

    hooble New Member

    Joined:
    Sep 19, 2007
    Messages:
    87
    Likes Received:
    0
    If you want to make mobile phone games, you've only got a couple viable technologies to chose from, either J2ME or BREW. So if you're going to start looking for info I'd try searching for those two terms.

    BREW phones are mainly in the US, and sparse everywhere else. Also, they require a bunch of money to join the system. Or at least they used to back when I was deciding between BREW and J2ME. I haven't looked into BREW for a few years now, so my info could easily be out of date. C/C++ compiled.

    J2ME is supported by just about every mobile phone on the planet these days. Even many of the devices that have BREW support will let you install J2ME apps. Also, J2ME is free to use/develop, with no licensing fees or any required certification/testing. It's basically a stripped down version of Java.

    When compared to BREW, J2ME is more limited in the graphics/sound capabilities, and features of devices vary greatly. Maybe a BREW guy can let us know some more details.

    As for carriers, you don't really have to worry about them at all, at least not with most J2ME apps. If you want to get rid of the odd security dialog though, you'll need to pay to have the app signed, which can depend on the carrier and/or manufacturer. I've never bothered.

    With J2MEt is entirely possible to make a single build support many different devices. You'll probably need a few different builds depending on the application needs. When I write a J2ME game, I usually have 2,3, or 4 different builds, that will just about cover all the devices out there. The builds I create are...

    Midp1.0 -> Will install and run on all Midp1.0+ devices
    Nokia Midp1.0 -> Special Canvas used for Nokia's, and will install+run on all Nokia's
    Midp2.0 -> Will install and run on all Midp2.0+ devices. Uses Midp2.0 features like Sockets, mutable transparent images.
    Nokia Midp2.0 -> Special Canvas for Nokia's. Uses Midp2.0 features like Sockets, mutable transparent images.

    Mobile phones have support for certain J2ME versions. You'll only need to worry about Midp1.0 and Midp2.0, 3.0 is coming eventually. Midp1.0 is the basic version, and any app that conforms to Midp1.0 standards will install and run on any Midp1.0 or higher(2.0, 2.1, 3.0) capable device. Midp2.0 introduces new features like support for mutable transparent images, Sound, and Sockets.

    I use special builds specifically for Nokia phones, because they don't handle the softkeys in the same way as most other manufacturers. Nokia's need to use slightly different code(manufacturer specific classes) for the ui so that the application will have the same look+feel as other manufacturers.

    I write all my games to adjust themselves to the current screen size, so I've not had to create separate builds for each possibility, of which there are way too many.

    If you'd like to discuss mobile development further, I'm always trying to shuffle people over to my message board... http://forums.00adam.com , where I've got a thread or two about starting out in J2ME. I don't know anything about BREW, but if you pick J2ME or just want to discuss mobile development come on by!
     
  3. Oaf

    Oaf
    Original Member

    Joined:
    Jul 30, 2004
    Messages:
    136
    Likes Received:
    0
    Bit of a rosy picture painted there, so I thought I'd come along and ruin it a bit for you :)

    Last commercial mobile game I did, came in at 28 different versions, and that didn't cover all the handsets operators usually ask for.

    Problems come in two areas:

    Screen sizes: Unless you're going to resize all your bitmaps on the fly, you're going to need separate builds for 128x128, 128x160, 176x208, 208x208 and 240x320.

    Sounds: I think operators still insist on either sfx or music. Problems arise with different phones requiring different formats, and the fact that different handset manufacturers have all implemented the sound api in subtly different ways, or even worse, have different bugs you need to work around. These will need different builds, usually.

    Finally, I really wouldn't bother with the operators - they're in bed with the big boys now, and unless your game is in the top 10 it won't get seen, and won't get bought. So I'd suggest making what builds you can, sign up with someone like greystripe to sell ad-embedded versions, and sign up with someone like sharewire to sell the games directly from your site.

    Oh, sorry, I'm talking purely J2ME here!
     
  4. Adrian Cummings

    Indie Author

    Joined:
    Feb 15, 2005
    Messages:
    922
    Likes Received:
    0
    I agree with Oaf in the main part but both answers above are good ones from developers that know.

    Greystripe and Hovr are your best first ports of call once you have written your mobile game or app. to start with now.

    Personally (and this is just my take on it ok) I like to support each device set with the correct screen size graphics it just looks nicer and can and does lead to sometimes better distribution offers around the globe.

    Sadly this in turn can and does lead you onto many sharks in the mobile industry that will take your mobile software, sell it and never pay you a bean for it... the old timeless story itself that affects many platforms and goes round and becomes a loop it seems - it is much worse on mobile tho by far.

    The final word as ever here is you don't know until you try yourself but many have already trodden the path you are thinking of walking before you and whilst some of what is reported is total bollox, some of it is very true and very painful indeed to endure in terms of business and making money from it.

    [Yoda mode on]

    Warned at least be you young padawan :)

    [Yoda mode off]

    Oh and to actually answer your original post if still interested after all our sage advice :) here are some good starting places these days for SDK and IDE...

    SDK:
    http://www.forum.nokia.com/
    http://developer.sonyericsson.com/

    IDE:
    http://www.netbeans.org/
    http://eclipseme.org/

    For me Netbeans has become the best and quickest IDE to setup and actually use for mobile j2me coding but I came form Borland JBuilder background anyway first so not sure if that makes any difference in truth.

    Good luck!
     
    #4 Adrian Cummings, May 21, 2008
    Last edited: May 21, 2008
  5. hooble

    hooble New Member

    Joined:
    Sep 19, 2007
    Messages:
    87
    Likes Received:
    0
    AC and Oaf are right about sales and distribution. I'd like to mention that my overly optimistic 'rosy' outlook comes not from sales but purely from giving away ad-supported free games. Certainly you'll need to be a lot flashier to get friendly with the publishers, but it's far less important in the ad-supported model. In my opinion, this is because when you are selling games, your target audience is actually the publisher, but when you give them away for free, you are targeting the player.

    So I'd also chose from the start if you want to sell your game or just give it away for free. Of course you can do both...

    Sales
    -------
    You really need AAA quality presentation. Top notch graphics, and some music. This will likely lead to many different builds for different screen sizes, and much development effort simply going into reaching the desired level of polish. You need to be able to sell the game to users based on screen shots, and a short description. It helps greatly if you have a known license. The primary goal here is to get that initial sale, without people even trying your game.

    Ad-supported
    -------------
    When people download your free game, you need to convince them to keep playing. I see this as shifting the games primary focus away from the flash and polish, and more towards the replay ability. For me this means shorter development time, fewer builds and often no sound/music is needed.

    With sites like Hovr.com, and Greystripe.com, getting downloads is fairly easy, so not a lot of effort needs to be spent on marketing.

    As a disclaimer, I'd just like to say that I have made a grand total of $100.00 in sales after about 2 years making mobile games. However I make my living with the ad-supported model using the same games.

    I've got a couple games up with Hovr.com, and all the rest with Greystripe.com. Greystripe is the big boy in the land of ad-supported mobile games, and they'd be my first choice. I only just started with Hovr a month ago, but so far it seems that they have an extremely limited quantity of advertisers, which keeps the ad impressions quite low. There's also mobilerated.com, which has an ad-supported option that funnels AdMob.com text ads into the start/end of the mobile game. Since they use AdMob, there's no shortage of inventory, but I'm sure the CPM is likely lower. I haven't been with mobilerated.com for long enough to know yet.
     
    #5 hooble, May 21, 2008
    Last edited: May 21, 2008
  6. Infinite Element

    Infinite Element New Member

    Joined:
    Jun 3, 2007
    Messages:
    70
    Likes Received:
    0
    Hmm... after reading this, I would probably just want to license my idea to a mobile developer after it comes out on PC. Thanks for all the info!
     
  7. orangepascal

    orangepascal New Member

    Joined:
    Dec 12, 2007
    Messages:
    12
    Likes Received:
    0
    Ouch, you guys scared that one right out of the mobile business ;)

    Not much to add to the guys above, mobile remains an interesting arena where everyone can make a game, but not everyone can make it.

    It's at least not something you can just do right from the first go, and licensing your idea probably means you split revenue with the developer that tries to take your game onto mobiles (an over-crowded licensed/branded market with very big brands from tv-shows, movies, and aaa-games ).
     
  8. brun

    brun New Member

    Joined:
    Dec 2, 2007
    Messages:
    65
    Likes Received:
    0
    hehe yeah I think what happens is that most developers without experience think that they can jump into the bandwagon and make loads of money with very little effort. The truth is that, as said, it doesn't work for everybody and obviously in any business venture you'll have to invest time and and effort before reaping the rewards.
     
  9. Jack Norton

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    5,130
    Likes Received:
    0
    What about Flash Lite support? I've read that not many devices support it yet, but this scenario could change quickly in the next few years. Probbaly if that is true, is worth waiting to use it? (I don't know how to use java/brew but know enough of actionscript 2 to at least make a simple game)
     
  10. Adrian Cummings

    Indie Author

    Joined:
    Feb 15, 2005
    Messages:
    922
    Likes Received:
    0
    For simple mobile games it's ok but thats about it for the moment and device support is not good enough yet either in truth. In a few more years 'yes' is the short answer regards Flash Lite for mobiles as a viable alternative to j2me for decent games with a bit more depth - but for now not really unless it's 'whack a mole' or similar.

    Sony Ericsson's newer 'Project Capuchin' may be of interest to some however looking into this area for now tho, while all us mobile phone developers wait for mobiles to evolve further on that front at least.

    And on top of that there are somewhat limited (as compared to j2me anyway) distribution options available when ready to ship a finished Flash Lite title too - all just not good enough to make revenue from yet really IMHO.
     
  11. Teq

    Teq
    Original Member

    Joined:
    Sep 16, 2004
    Messages:
    228
    Likes Received:
    0
    Doesn't help that there are still a large number of older gaming capable phones around, for example the 3510i is still capable of generating a reasonable amount of sales a month.
     
  12. Adrian Cummings

    Indie Author

    Joined:
    Feb 15, 2005
    Messages:
    922
    Likes Received:
    0
    That is very true also, tho in my case I've dropped that particular trusty old 96x65 pixel device and midp1 now anyway late last year - gotta move on a little at least. Some people 'still use' these mobiles of course I know... it was a very solid and trusty device that one.
     
  13. Teq

    Teq
    Original Member

    Joined:
    Sep 16, 2004
    Messages:
    228
    Likes Received:
    0
    AFAIK the 3510i emulator doesn't work with Java 6 either, I just support legacy devices with a basic version and resize proportions accordingly, I hear what you're saying though, I find it frustrating that sales for that are as high as Series 60.2 Nokias :eek:
     
  14. Oaf

    Oaf
    Original Member

    Joined:
    Jul 30, 2004
    Messages:
    136
    Likes Received:
    0
    I wouldn't trust the 3510i emulator anyway, you really need to get it on the phone. In fact, apart from initial testing, I wouldn't rely on any of the emulators.

    I've got a drawer full of phones (I'm sure Adrian has as well, if he hasn't sold them) and handset testing takes a long as development, if not longer!
     
  15. Sol_HSA

    Indie Author

    Joined:
    Feb 27, 2005
    Messages:
    470
    Likes Received:
    1
    I might say some things about BREW. Note that this information is a few years out of date, and a little on the ranting side, but anyway.

    First off, BREW is more a business model than technology. The good side is that when you're in, qualcomm has all the distribution systems worked out, so you don't have to do all that footwork you would have to on java games. At least in theory. I did not work on the business side so I don't know how well that works in practice. Nor have I owned a BREW phone, considering I don't live in the US, so I don't know what the user experience is like.

    Okay, that was the good side. The bad side is that I got the feeling some folks had sat down to have a long meeting where they tried to think how to make the developer's life harder. There are several fees in different stages of the development process; can't remember exactly what they were, but I calculated that you're going to spend at least a couple thousand dollars to get your first title out - and this doesn't include the development tools.

    Basically there's a testing phase where you submit your program for testing, and when it passes, you can get further. This testing phase is well-documented and you can do most (if not all) of the testing yourself before submitting. After this the app goes to each operators' own testing (which I couldn't find any documentation about), and if it fails, you're back to square one. Each testing pass has a fee, so it makes sense to do a lot of testing before submitting.

    Expect to buy every single phone you wish to support in order to test on them. These phones then need to be sent to qualcomm so that they can turn them into development-enabled devices. Many (if not all) phones are different in subtle ways, different bugs here, different screen size there, and so on.

    As for the API, as an example, there were seven (7) different audio APIs in brew the last time I checked, and none of them work =). We had various strange bugs related to audio which sounded simply impossible, like when someone called in, and the person playing the game answered, the receiving end would hear the game's audio, while the player doesn't. This was fun to discover, especially since I couldn't test that firsthand..

    Now, this might be a much worse view of the field than what it really is (and like I said, this information is a few years out of date). I was doing very, very, VERY high end mobile games at the time, pushing all of the target platforms to the limit, so I found all sorts of problems "normal" programs most likely did not.

    And all said, BREW wasn't the worst platform to work on.
     
  16. Adrian Cummings

    Indie Author

    Joined:
    Feb 15, 2005
    Messages:
    922
    Likes Received:
    0
    Yes many older ones have gone back thru eBay where they all came from in the first place pretty much heh - tho I've still got some older ones here that have seen their day now i've switched to j2me >=midp2 only pretty much and newer Zeemote support (which won't work on anything less in truth anyway).

    Regards BREW: I looked into it all in detail last year regards Flash Lite at least and found the QA testing side of things to be not on the same planet I'm from LOL, so lost intertest in BREW full stop. Too much damn red tape to get thru before you can make any money unlike traditional device paths available methinks.

    This last point in fact opens up a can of worms that is beyond the scope of this thread really but if I were new coming to mobile development I'd give BREW a miss really and stick with vanilla j2me for now if that's what you want to do in mobile games.

    ...and look at Flash Lite again perhaps in about 2 years time?
     
    #16 Adrian Cummings, May 23, 2008
    Last edited: May 23, 2008
  17. Michael Flad

    Indie Author

    Joined:
    Aug 4, 2004
    Messages:
    190
    Likes Received:
    0
    My experience with Brew regarding the development is *WAY* better than J2ME. In fact we got the framework/code as compatible as to only need one single binary for hundrets of handsets. Sure there are incompatibilities and different APIs but you can get the exact device at runtime and enable some workarounds (still even without that - Bew is just a more compatible platform than J2ME).
    We of course required different builds for different asset sets but that's not Brews fault.

    The testing is a problem, though you don't need all the devices you just need a primary test for (IIRC ~$1500) and then a cheaper one for almost each single handset (even for the same handsets but for different carriers) which, again IIRC costs about $150-$250 - all our tests were done by NSTL so you only need one testlab. So you should have a few handsets and if you've got your framework right, all the other tests are done at your testlab.

    Then there's the revenue side - simply put - in theory you could make shitloads of money if you can get your game on the decks of Verizon etc. at all. But this is the only and a 100% showstopper problem with Brew. You won't get your titles on the deck and make no sales at all. Tried it for years (as it would've been really worth it given the revenues we got from a Brew release) but no chance - even if you had a game selling in the past - heck even if you still have a great selling game on their deck it got almost impossible to add another one.
     
  18. Adrian Cummings

    Indie Author

    Joined:
    Feb 15, 2005
    Messages:
    922
    Likes Received:
    0
    Yes well BREW is beyond the scope of the the original thread starting question really and is a waste of time for most here to want to even pursue in reality.

    Then with that you have NSTL LOL what a total wheeze that is with 'extra' the costs involved.

    I could go on but I won't :)

    J2me still rules for the time being (outside the US anyway) - that's just the way it is now.

    Carriers and deck mafias are a total waste of time also now the distro model is changing (hopefully for the better slowly).

    That is my sage opinion over the last 3 years developing mobile games - even in that time the whole scene has changed a lot (as has the revenue you can make from it all).

    One thing for certain I have learnt in those years... there are too many dodgy distro chains and middle men wanting a slice of your revenue in the mobile distribution chain quite honestly. That is the worst part of all about mobile games development and why it's not for everyone, you have to be thick skinned to survive at all when going beyond the good Greystripe's and Hovr's etc. into foreign distro partnerships - a lot of which is based on trust up front!
     
    #18 Adrian Cummings, May 23, 2008
    Last edited: May 23, 2008
  19. Scurvy Lobster

    Scurvy Lobster New Member

    Joined:
    Mar 11, 2007
    Messages:
    128
    Likes Received:
    0
    I haven't read through the entire thread but just wanted to comment on the original question with some of my experience.

    I work at a small but rather well known J2ME and BREW mobile games developer (most BREW development is outsourced though) and we usually support 200 to 300 devices when talking the J2ME version. We take great pride in making the best game possible for every handset, so if we support 300 devices that makes about 200 binaries. The technology behind this has matured over the last four years, so we have rather stable builds pretty fast now.

    What I am getting at is that mobile games development shouldn't be underestimated. We have 150 devices inhouse and have additional QA outsourced. Don't think that five or ten phones will get you to retail. That will probably do fine for a prototype though.

    Of course you can cut quality and live with fewer binaries but the competion is VERY TOUGH in this sector and going up against companies like Glu and Gameloft takes a lot of effort.

    Just my few cent.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer