Jump to content
  • Advertisement
Sign in to follow this  
rAm_y_

Games on non smart phones?

This topic is 1197 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does anyone know anything about this, both pre smart phone era and current non smart phones, I'm pretty sure a lot of them used/use the Symbian OS, would these games be created in Java, can anyone shed any knowledge. What languages/tools are used. Just curious really.

Share this post


Link to post
Share on other sites
Advertisement

Does anyone know anything about this, both pre smart phone era and current non smart phones, I'm pretty sure a lot of them used/use the Symbian OS, would these games be created in Java, can anyone shed any knowledge. What languages/tools are used. Just curious really.

 

Symbian is a smartphone OS(and it was quite dominant before Apple entered the market with a more consumer oriented device), apps for symbian were written in C++ and later versions(after 2010) used the Qt framework (Which made it a pretty awesome smartphone OS to develop for, it was imho superior to both iOS and Android from a developers point of view at that time but by then it was already too late.)

 

non smartphones tend to run Java Micro Edition "apps" which are far more limited, you can get everything you need for that here: http://www.oracle.com/technetwork/java/embedded/javame/javame-sdk/downloads/javamesdkdownloads-2166598.html

Edited by SimonForsman

Share this post


Link to post
Share on other sites
Yeah a lot of them forced you to use Java, but most of them had really bad Java implementations - like never garbage collecting and not optimizing your code.
I know one company who stopped using more than one class, and instead wrote very C-style code, full of switch statements instead of polymorphism.

I had friends at another company which had written their own Java->C language translator, so they could easily port their games to the non-Java phones.

Share this post


Link to post
Share on other sites
As for where to read and get started, check the forum FAQ.

The list of useful links for those has gotten shorter and shorter over the years, but a few good resources still exist. Third item down, under general wireless, are some industry hubs that look at both smart phones and feature phones. The fourth item down, under "Java and BREW", has links to help with more generic feature phone programming as most feature phones work with Java and MIDP profiles. Nokia also has various tools to build native programs for their devices.

Share this post


Link to post
Share on other sites
Also, while I didn't work on them, I think Washu had some experience with Symbian. I wish the board had a feature to notify a person when their name was mentioned, like reddit and some others...

Share this post


Link to post
Share on other sites

I worked on J2ME games.  Sonic the Hedgehog, Metal Gear, Streetfighter, FiFA.  It was mostly Java with a couple of exceptions (Symbian, BREW, and Windows phone).   It was a very cut down version of Java and the handsets were very limited so we had all kinds of hacks to get things to work.  Symbian, BREW and Windows Phone were always done as an afterthought because the marketshare was so small so really didn't get the attention that they deserved. 

 


I know one company who stopped using more than one class, and instead wrote very C-style code, full of switch statements instead of polymorphism.

 

Not just one company.  This was pretty much the only way to get the java byte code small enough to work on complicated games.  The way we did it was to organise the code into separate classes to organise code but everything in the classes was static and public.  Then as a preprocess step they got merged into a single class.

 

Some other hacks we did were:

  • merge all assets and data files into a single file with a custom header because it would make the zip compression for that jar file smaller.
  • use the C preprocessor on the Java so that we could use macros and defines to get smaller byte code
  • use a tiny subset of Java so that we could write the games as polyglots that would compile in both Java and then later in C for the symbian / BREW devices
  • Create a static array large enough for every variable in the game and then instead of creating variables just hash #define into the array
  • run the code through proguard multiple times to optimise it for size
  • Motorola devices were particularly bad for memory fragmentation so we had to through and order the loading of every set so that they would always load largest first
  • In one game it was just obvious that it was never going to fit onto the devices as even just the byte code was too large so we used our own VM and scripting language to get it to fit (Thats right a VM  inside a VM running on a slow handset).
  • Write everything in fix point math with no fix point library this created lots of really ugly code.

Other things worth considering was the differences in APIs and language features across the various handsets.  Wanted translucent sprites?  that was a Nokia only feature so for the other devices the artist would have to dither transparent piles all over the sprite.  Wanted 3D?  That would mean supporting up to 4 different 3D APIs just for the Java handsets.  Wanted your cutting edge 3D game released on a carriers deck?  Then you had to support all their handsets which meant porting your game to Nokia 3210 that could only run your game as a slideshow at less than a frame a second.

 

Even when the iPhone came out the first few games we created were still J2ME games that we converted using YACC and LEX to cross compile to Objective C
 

Share this post


Link to post
Share on other sites

Which made it a pretty awesome smartphone OS to develop for, it was imho superior to both iOS and Android from a developers point of view at that time but by then it was already too late.

 

I see you didn't really develop much for Symbian biggrin.png

Easily the most horrible ecosystem I've ever had the displeasure to have to work with.

It did get a bit better right at the end when they started using Qt, but at the time they did, the platform was already practically dead.

Too little, too late.

 

But before that? O. m. g.  Bastard version of C++, weird code guidelines and 3 different incompatible UI frameworks with lacking functionality.

Also an extremely over-engineered system which made it ridiculously slow for the hardware it ran on...

 

Symbians main problem was the business model with the London based symbian making a very incomplete "base system" and then each company (Nokia, and Sony-Ericsson (via UIQ) mainly) writing a complete own UI framework on top of that, plus lots of custom system services, and after that, every single phone project had their own special Symbian version they built up.

The changes was far deeper then what happens on Android today.

 

Compatibility across versions was a nightmare.

Weird bugs appeared, disappeared, and reappeared again.

Symbian catered to every phone projects managers whim, and didn't have much of any own agenda for their system, which made everything a totally unmanageable mess, which was made even worse because of the secrecy between competing phone manufacturers. (like having the same functionality implemented in several slightly different and totally incompatible ways)

 

And then the tools... Even worse then Android. 

Where you around when CodeWarrior was the official IDE? Jikes...

 

Well, they did try to salvage it after getting blown past by apple, by for example, integrating Qt instead of the horrible mess they had before, but it was mostly a thin layer of paint on the pig...

 

(I worked for over 5 years with all the involved companies, Nokia, Symbian, UIQ and Sony Ericsson, and some of my code was part of the Symbian platform...)

Edited by Olof Hedman

Share this post


Link to post
Share on other sites

I know one company who stopped using more than one class, and instead wrote very C-style code, full of switch statements instead of polymorphism.

We did that at Sanuk Games and Miyowa (French company), so now you know of 3 companies.


L. Spiro

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!