Skip to content

Archive

Tag: Mobile

1. Where to start after downloading the SDKs?

Having a standalone project manager is a good way to invite developers in your mobile world.

So I downloaded the SDKs (see my previous article) and now I’m trying to find out how fast I can get ‘hello world’ working on a simulator. Here’s what I got so far.

  • Nokia: there’s a getting-started section on the Nokia site. This is a step by step thing which would be great if I wanted to use NetBeans. I don’t know which IDE I’ll use. I guess I’ll download NetBeans to keep it simple, stupid. Over slow bandwidth, I’ll be waiting.
  • Sony Ericsson – can’t find a getting started section online.
  • Samsung… Here they have a getting started document that’s not really hard to find, and, apparently, a NetBeans/Eclipse free project wizard. Now, that seems easy enough.

After literally 10 minutes, I got HelloWorld running in a Samsung device simulator.

2. Hello 3D world?

It’s nice to show how to perform I/O operations. It’s even nicer when we know where to find the code samples.

So I decided to stay with the Samsung SDK for now, and try to get 3D stuff running in the simulator.

JSR184 Mobile 3D Graphics API is a tutorial with source code, explaining how to make a 3D app with JME.

It’s a pity the archive linked from the article only provides a .jad file, not the source (plus I run out of luck trying to run this directly.

Never mind, let’s see what we can do with this.

It turned out that the example fits in one file, with a bunch of inner classes. This failed gracefully, throwing a URI exception.

I uncommented a few lines just to get a clean run. Nice black screen. Then I poked around, and finally I got my hands on all code samples, neatly bundled with the SDK (yea, all the nice examples pop up when you choose, ‘Open Project’ in the Samsung SDK tool, but the tutorial doesn’t say that.

I kind of liked the so called Pogoroo example. It’s not very far from the kind of data I want to display, and blender has an .m3g exporter. So I guess I’ll need to slow down a bit and actually learn something.

After rounding up SDKs and solutions on several mobile platforms, I hit a no brainer: why not Java?

Virtual success

In 2006, the write once, run anywhere motto felt bleak if anything. I had become an experienced Java SE developper with little or no interest in developing java applications, let alone opportunities. I know it’s down to personal experience – well that, and all the trouble people seem to have running java apps and applets on desktop platforms.

App stores everywhere

I can’t absolutely tell if the app market is taking off beyond iOS. We might as well pretend there’s only one App Store (capitals).

It will take off, sooner not later, and every mobile device manufacturer seem busy setting up their own store, designing tablet PCs and introducing touch enabled device.

Another thing that they all have in common is JME. Java ME seems to be the only platform that actually runs everywhere (except on iPhone, but read here and here).

Have another cup of Java

Some advantages of Java over C/C++ over Objective C are somehow static, not much has changed in the past 10 years or more:

  • No memory management (no zombies)
  • No pointers (no address errors)
  • No .h files

I know what you’re thinking. Java is too slow to make 3D games, right? Well we’ll see. Objective-C is too slow to make 3D games anyway. All critical code sections have to be written in C or C++.

Straweberry and Cream

Needless to say, every other manufacturer somehow ship JME with their own SDKs and a string of proprietary APIs. I suspect 90% of the code will remain ‘cross platform’ so I guess finding out the easiest to use SDK maybe a decent way to get started. I collected a few links to developper portals / java pages.

Games and devices

Pocket Gamer is an excellent resource for learning about mobile gaming beyond iOS. They have reviews of the latest-hottest games and publish the list of devices they use for testing games, along with top 10 mobile gaming devices roster.

Yea. That, and a Merry Christmas. WTF.

Before glossing lightly over a topic that some iPhone developers will undoubtedly find heretic (after all, we’ve already tasted the forbidden fruit) … … there’s one thing I’d like to share.

In 1999, I stopped developing on TOS. I’m not sure why. The most likely reason is that I left my parent’s home, and I suppose there was no special reason for me to buy another Falcon 030.

Well frankly speaking I’m not sure what has so dramatically improved since TOS.  The only really good piece of IT news in the meantime may be that mobile OSes aren’t all based on overlapping windows anymore. Apps were running nicely too with 512kb RAM or so (yes, kilobytes). Most definitely good enough for the 2D oldies leading the app craze.

Anyways, I feel helpessly agnostic about devices and operating systems, so I decided to have a look at the Ovi store. It’s not the first time either since about a year ago I was hopping my merry way on Nathan road in Hong Kong, gazing at a fresh bunch of OpenGL-ES2 enabled devices.

Apparently publishing on Ovi costs 1 euro. Feels like a trick-no-treat thing (will they soon announce 1.5 million registered developers?(1)) Fortunately I’ve  acquired the ‘Oh let’s not get another $1 krapp’ reflex that saved me from (what may not have turned out to be) a tedious registration process.

The store itself looks pretty decent. Considering originality isn’t every other distributor’s forte, we’ll forgive the ‘not invented here’ design inspiration.

Mind, it does feel quite difficult to navigate between Ovi stores. Switching the URL to .us/co.us/.com doesn’t help as they keep geo-locating me somewhere else. Yeah maybe I don’t live in the US after all. I won’t quote an idiotic article suggesting Nokia should have relocated to California. One link that you might bookmark (because it may not have changed in the past 5 years): the Qt developer portal.

They have a blog too, and there’s a demonic article I really want to read: Nokia’s app store sees explosive growth, still sucks. To set things straight, note the author of that article didn’t quote app download figures either (but see here, here and here).

I feel obliged to mention that Ovi means sheep in latin. Maybe that’s why nobody speaks latin anymore.

I was happily discovering that there is a beta version of Qt compatible with MacOS, when I somehow remembered that I’m typing this from a makeshift workstation involving:

  • A weeny 1366×768 display (anchored to a weenier 1024×600 sidewinder)
  • 16 GB SSD(1.25 GB available)
  • A 16 GB watchamacallit flatkey.
  • Intel Atom N270
  • 0.99 GB RAM (really)
  • A neatly compact K340 keyboard. Please look-up the brand as I’m not the fan – nice buy though.
  • An utterly indestructible wireless mouse (yea, topping a Wacom tablet) that, for all I know, survived the Y2K bug, 3 heartbreaks and 4 or 5 home-movings,
  • (No, it isn’t a mobile handset)

Qt vs JME?

If I search my memory carefully, I should be remembering that Qt was in Nokia’s oven when I first downloaded their Java SDK. Here we go, now they have two SDKs instead of one. A quick look at a pretty comparison chart shows that Qt only runs on so-called smart-phones (as in, the recent ones). Am I missing something out… ?

All directly leading to a dilemma…

With a Playstation phone (Ericsson) and the X7 Sushi lined up for 2011, if I got a device at this point, my choice would be somehow conservative (pick from a somehow outdated selection?)

But no, actually I don’t really fancy JME. Why not try something almost fresh? After all I already was a laggard when I boarded the iOS crew.

Hitting the hard-line…

Maybe the first thing I should have done is downloading the SDK downloader. At little less than 1GB, the SDK itself is a baby mammoth. Apparently the Android SDK is just about a 100 MB.

I can’t promise I’ll go further than hello world this time. It’ll be down to docs and examples I’m afraid, not market share (to be c’d?)

(1) Read the so called demonic article. I can’t believe I even guessed the figure right.

I hit a low this weekend, feeling exhausted and dispirited (is that a word?). Finishing a game is exactly what you’d expect. A b**ch to get done with, never mind fixing bugs.

The fact is, the later stages in my game didn’t receive the attention they deserve. Now they do, and that’s good.

I’m putting together a little advice about game graphics. Maybe little use to you if your budget exceeds 10 000$. Otherwise we’re probably on the same boat.

What makes game graphics look rich?

Our perception of game graphics seems largely based on three simple dimensions:

  • usability. Graphics are part of a game’s user interface. Poor ergonomics when producing graphics can mean any number of annoyances that can ruin the fun of playing, including, but non limited to:
    • user can’t differentiate walls from the ground
    • user can’t find their way our 3D world
    • user can’t distinguish items from decorations
    • user can’t see gaps between platforms
  • countability. A detail isn’t a detail if it can’t be counted. Twisting a curve this way that way isn’t terribly useful. Adding a couple of spikes on a flat landscape is.
  • nameability. Anything that a player can name ‘counts double’. A scene full of details is ‘just full of details’. A village with a horsecar, a well and a church has 4 countable elements. If the well has a roof, you can make it 5. Tiles on the roof? 6.

The bottom line is that being a great artist isn’t necessary, and might in fact work against producing rich game graphics. Graphics for gaming is craft first, art second.

The above rules don’t invalidate whatever we hold to be principles of design. In fact I would rather assume that basic design principles (this blog’s not the place) have been assimilated before considering the above.

Drawing on a piece of paper, I like to express an idea quickly, with as few strokes as I can. But I don’t really think a game scene ever has enough details. Even if you can afford throwing in enough details to crowd a scene, getting everything in (and visually tuning your stuff to avoid the crowded look) is just what you want to do.

What will cost you dearly?

Before I started making graphics for a game, I mostly cared about organic modeling. Fair and square, I concentrated on trying to make human faces. I still don’t think it’s a bad idea and, in fact I would maintain that’s exactly the first thing to worry about. However…

  • Making game graphics that interact nicely with a game engine, especially an immature game engine, can be difficult or just frustrating. Making an engine that can support just whatever graphics are brought in can be… …a nightmare. The best approach is to keep it simple (consider squares for a start… don’t underestimate all that can be done with just flat, square terrains).
  • Every type of object you might want to model brings it’s own challenges. If you’re new to this, then like me you’ll have something surprising to learn about why natural landscapes are hard to make; why even square buildings with square doors and window frames can be a nag… …and so forth.

What’s not a problem (anymore)

Face and vertex count. I don’t know about textured games. All I know is that the amount of faces and vertices you throw at an iPod touch 8gb isn’t a major issue. Overlaps are an issue. So you can make a smooth, detailed model, but not stack huge faces behind each other. In 2010, even mobile 3D needn’t be rough and blocky.

Save your time and your buck?

Given the above, here are two golden rules that can help producing rich graphics in reasonable time:

*Use simple shapes*
Literally. Use cubes. ball, cylinders, circles. Simple extrusions. It’s not just saving you time; it’s making graphics easier to read for your players.

One argument against simple shapes is that simple shapes don’t amount to anything recognizable. Well they surely do. A plane means nothing. A ball means nothing. A ball above a plane means a whole world, viz. the sun, earth and sky.

*Don’t work against your 3D tool*
As a 3D artist, my 3D tool doesn’t interest me very much. Especially not the features. Every other feature seems to be doing some other stupid thing that doesn’t help creating great models.
As a game creator, I love my 3D tool. Every little feature and function can be used to achieve a slightly different feel. So instead of just using simple shapes, or spending hours fighting with meshes and bezier curves, I can make my graphics more fun and engaging in a few clicks.

While my iPad is waiting to get a programmer’s attention, I ordered a Diga pen to try out drawing software. I doubt whether that’s gonna be much use but… …Just using this thing as a testing device or a reader would be a little limiting, right?

If I started 3D graphics programming targeting a desktop platform or XBox Indie, I would have felt hopelessly intimidated. Also, I would have gotten bogged down into textures and shaders.

Instead I started on the ITouch. By far one of the most powerful mobile platforms (not counting the PSP, likely no worse than the DS), it’s still a weeny tiny computer with little memory and processing power to boast. Here’s what I’m learning:

  1. Read/Ignore advice about what to use and what not to use. File it. It’ll be useful later when you really need it. Optimize a beautiful scene, not an empty screen.
  2. Live with polygons and normals and make the better of it. Textures are great to paint flags. You wanna make a 2D game or what?
  3. Keep game logic where it f*****g belongs. 1% to 10% of your processing time. Game logic includes NPC management, camera management, animation and simple physics.
  4. Hack from game engines (hey, I should really look into doing this!). Don’t use a game engine (unless you want to hand in low quality material right on time). Guys writing game engines are really, really, experienced and smart but… …their engines cater for too much to be either easy to learn or practically faster than anything custom built with minimum care.
  5. Write your own export routines for a start. Scripting 3D tools is easy and avoids importing and parsing stuff you don’t even want to know about.
  6. Don’t under-estimate GL transformations. Anything that moves/rotates, looks a different size, is nice and cool. Bone/Frame interpolation is nice, but GL won’t do it for you.
  7. Learn procedural methods. Anything you can evaluate at run-time without disrupting game play is something you can reuse at will, never need to load and hardly need an artist for.

What’s the conclusion? I wouldn’t code on a 10 years old PC. Too damn stupid. I wouldn’t test on a net-book – kind of lame. Starting on a mobile platform makes me feel happy, because mobile gaming has a bright, beautiful future. And the best part is, when I scale up, I’ll be fearless.

Happy coding :)