New developer in training!

[vesper]

Hi there! I recently caught your reply to a blog (likely the same one the other fellow was reffering too in the other starter thread) and found my way here.

Its funny how simple information, like a short comprehensive list and some reassurances can help disuade worries and get some of us to try new things out. Namely mobile phone development. I've been interested in working on games for phones for a while but it seemed really complicated trying to figure out all the compatibilities and how to distribute the things. After reading the blog reply and the posts you've made here I'm willing to give it a shot.

I grew up on Atari/Intellivision games and Nintendo, the opportunity to try to build some basic design oriented games on tight resources gets me pretty interested. I also have a background in game oriented art and expanding into design seems pretty natural.

Do you have any advice on initial projects that could be beneficial? I'd like to jump in but there seems to be so much possibility that I feel like I have ADD

[Adam Schmelzle]

I'd make sure your first game at least requires the use of the full direction pad as well as soft-key's and fire. Other than that, you may not even want to make it much of a 'game' to start with.

The key is to try it out on every device you can find(friends, family, strangers) to see what types of problems you can run into, before diving into a real game.

Once you can overcome the following hurdles, I think it's time to tackle a 'game'. I find that the solutions to the following problems are easily carried to every future game, so it won't be wasted effort.

Things you need to look out for....
0) ***Does the game install***
1) Are the buttons all handled properly: up/down/left/right/fire and soft-keys(corners)
2) Is the screen flickering
3) Does the game perform consistently across devices of greatly varying power.
4) Does the game handle different screen sizes in a satisfactory way.

The first hurdle is going to be installing the game. Once it runs in the emulator, you're going to need an easy way to get it onto various devices. As far as I'm concerned, the easiest way to install games is through the device's web/wap browser. You'll need to setup/access a web server somewhere, but that's not too difficult. I have a dyndns.org account and point it at my development machine running a web server. This is a fairly simple process, but minor details can completely prevent installation from completing.

[vesper]

Thanks for the roadmap. ;D

A short term stumbling block in regards to those steps though is that I don't actually have easy access to any real phones. Mine is too old to even support a simple game. In my case I'm trying to get a handle on the process generally before I devote soem money to an appropriate handset and start imposing on friends.

That said, for the time being I'll have to sidestep step 0, but I'm wondering if you could clarify likely stumbling blocks in the other points. What I mean is that I have some experience studying game construction, I've developed a basic custom Java Game OS as a self project in the past.

From that angle I'm wondering if point 2 is aiming to iron out the use of Double Buffering or if screen flickering is another potential issue potentially arising from some other area I'm unaware of.

As for point 3, I could see it being a fairly broad hole to cross, but your wording suggests that the main issue would be the way I'd want to tie the game speed to the framerate/time elapsed. If there's any specific caviats arrising from the platform that are different than general (say PC) frame rate limiting I'd love to hear about it.

Point 4 seems more of a test a feel issue, assuming that the screen isn't just fixed to the smallest size and scales to the available space.

Also if anyone else ends up reading this looking for information on how to start, over the past day or so I've found that the tutorial at koderko.dk/J2METutorial/ is a well organized first step. And I've also been finding the process of analysing the structure of the JBricks demo form the Wireless Toolkit to be very helpful.

[Adam Schmelzle]

Alrighty, here's some more detailed thoughts on the above steps...

1) Are the buttons all handled properly: up/down/left/right/fire and soft-keys(corners)

The first thing to make sure you do when handling button presses, is to NOT rely on hard-coded keyCode's. The function...protected void keyPressed( int keyCode ) passes in a keyCode that is completely different from device to device. Some people try to use these keyCode's for the soft-keys as well, but that's a very bad idea as they're not even mapped as keycodes on many devices. The 'best practice' here is to use...int gameAction = getGameAction( keyCode ); where 'gameAction' is going to be equal to a public constant defined for you in the Canvas that you are using. Just do a switch(gameAction) and it'll handle your keys most of the time.

The issue here is that even when you use the 'proper' code, and check the keyCode against the constants, you can run into problems...

Example: On most Nokia's(half the world), when you use the standard J2ME Canvas the 'FIRE' constant is not mapped correctly to the center of the D-pad / select button. Pressing 'fire' may(will) result in some other button being triggered. Also, the corner soft-keys end up being mapped strangely.

Solution: To get around this, use the 'nokia' libraries for your game screen. You'll need to include the 'nokiaui.zip' file in your build path (don't need to copy source), and create a separate build for Nokia devices. When you have the nokiaui.zip file included in your build path, you will then have access to the 'FullCanvas' class, which will properly handle your keypresses on Nokia's.

Extra Work required for Nokia: Unfortunately, if you use the 'FullCanvas', as suggested by the name you are going to be drawing the entire screen area, including where the labels for the soft-keys usually go. So you need to draw your own soft-key labels. Fortunately on Nokia's the soft-keys are easily handled usinge the keyCode constants (KEY_SOFTKEY1, KEY_SOFTKEY2). That's right, you need to do a switch on the keyCode(not gameAction) to handle the softkeys on Nokia's. KEY_SOFTKEY1 being the left softkey, and KEY_SOFTKEY2 being the right. You can draw 'em any way you want to. This also means you are now creating 2 builds of your game if you want to support everything.

Other insight: You may wonder why I don't suggest using fullscreen on a standard Midp2.0 device. The reason is that it is IMPOSSIBLE to determine whether the soft-key is on the left or right side of the screen in any reliable fashion. Without knowing which softkey is on the left and which is on the right, you are going to be unable to draw the label for that softkey in the correct position (left/right) on the screen. You may start out with the emulator or one or two devices and find that it's consistantly adding your softkeys in the same positions, but switch to a different device and it's a crapshoot.

But Adam, why can't I use a single build and check for Nokia's using class.forName(String)' to determine what type of Canvas I need?

Glad I asked! Because there are some devices(minority) that will absolutely 100% refuse to load ANY application that has ANY classes in it's .jar file that reference ANY unknown classes. You can use 'Class.forName(String)' to CHECK if you have a nokia device, but you cannot include any of the actual classes that reference Nokia's libraries, so it's gonna need separate builds. Class.forName(String) SHOULD take care of these situations, because you can decide at runtime that you do NOT in fact want to instantiate your Nokia specific code, and your program never actually ever references any Nokia code at runtime. It's those rare devices that check all class/library inclusions BEFORE runtime that cause problems.

I'll get to points 2->5 a bit later...

[Adam Schmelzle]

Has anybody played my games and had problems with the buttons not working correctly? I don't hear from people that play my games and have problems, except when the advertising system can't connect to the internet.

At the moment, for point 1), the only device/manufacturer specific code I use in any of my games is done because of the above reason for Nokia's.

[vlad]

I have a Nokia, anything specific you want to test?

[vesper]

Not quite yet, but it probably won't be too long before I have something to kick around

Right now I'm just focusing on learning the API well enough to build a framework for myself. Just working on building a menuing system and making sure I can navigate from one screen to another. Then I'll likely upgrade the basic version of that to include graphics/animation and what not. I've found that by the time I can do that kind of thing with the interface I have enough understanding to build something interesting for the menus to lead to It also helps keep my projects organized since they all have similar entrypoints and structures.

[xdan]

I'd be interested in hearing more about (3) too (more specifically, would you recommend frame rate independent movement? At the moment I'm just using a fixed FPS which seems easier.)

[Adam Schmelzle]

You will likely not want to use frame rate independent movement. Here's my reasoning...

1) We've only got millisecond precision
2) The overhead associated with simply sleeping/waking a thread is several ms
3) When you use framerate independant movement, you've got to do a bunch of math to figure out how far things will move each frame. This will destroy the performance of most mobile apps.

The way I get around this problem is unique as far as I know. On my more animation heavy games ('Attack Chopper 1+2', 'Attack Breaker Pro', 'Water Stealers'), I benchmark the game when you first run it. So I run at un-restricted speed during the menu/start and then set the permanent framerate to the average(or just under the average) fps.

This way you get the advantage of having a better framerate on the powerful phones, but without the limitations of a framerate independent algorithm.

Try out '3D Attack Chopper' 1/2(menu bechmark), 'Attack Breaker Pro'(menu benchmark), and 'Water Stealers'(first run does a test shot benchmark).

[Adam Schmelzle]

2) definitely references double-buffering. The problem here is that the hardware double-buffering doesn't always work right. I use my own software double-buffering 100% of the time, and here's why...

1) I have a phone where the double-buffering flat out doesn't work right.
2) The WTK has issues with double buffering sometimes for some reason.
3) When you use hardware double-buffering, the only advantage is that you can draw to a back buffer to avoid flickering. However, you don't have access to that Image, and can't re-use it. So if you want to increase the performance of your game by only re-drawing what's changed, you can't do this directly with the hardware double-buffer. It's also 2 frames behind your currently rendering scene, so you just won't be able to re-use it well in most situations.
4) Some devices don't actually support hardware double-buffering.
5) The paint() method is called asynchronously, so it can(will) sometimes be called more than once per game tick, which would necessitate re-rendering the entire scene more than once per tick(), unless you have a stored buffer with the current scene, but then what's the point of the hardware double-buffer?

To get around these limitations I simply use software double-buffering. By drawing to your own off-screen image during your game tick(), you know exactly what's on the screen and can make small changes if that's what you want to do. When paint() is called, just draw the backBuffer to the screen as expected. You can even elect to NOT draw the buffer to the screen on every paint() call(maybe it's unchanged), since you know it's single-buffered, the scene won't flicker.

[Adam Schmelzle]

4) You'd think screen-size issues would be obvious to most people, but download a few games from sites like Hovr.com, Gamejump.com, getjar.com and you'll likely find that half of the games you just downloaded are not built properly for your specific screen size.

There are so many different possible resolutions on mobile devices, that it just doesn't make much sense to have a separate build for every possibility. Just design your game to adjust itself for the current device's rez, and you'll avoid any problems. Not only does it make deploying it to other sites a thousand times easier, but it's easier to make a few builds than it is to make a few hundred.

When uploading a game, many sites have gigantic lists of devices where you are expected to pick and chose which are compatible with your game, based solely on the MODEL of the device. That's right, they usually don't list the screen size, or even Midp version. Gamejump.com use to have a VERY handy system where you chose the requirements for the game you upload using a big list of screen sizes, midp versions, manufacturers, etc. It was fantastic, but they ditched it because 'most developers didn't use it correctly', and now they just use the giant ugly model list.

Simplifying the process of submitting the game to portals is 100% worth the effort of making the game auto-adjust. Even if that was the only reason.

[vesper]

Thanks for all the replies, seems like this will be an interesting summer project while bored at work

[Ghosty]

Apr 22, 2008 6:58:00 GMT -5 vesper said:

...but there seems to be so much possibility that I feel like I have ADD

I got ADD ;D It really sucks while making homework, can't resist to play attack chopper 2 ;D ;D