It doesn't give you the right to basically rip them off.

it wasn't a rip off - i was so close to even open sourcing the whole thing, the reason why i did not is because it uses a common library which i own to cross-build on multiple platforms. in fact, we even have a linux version, i just never booted a VM with linux during this 36 hour period, otherwise, it would be FIVE platforms. we did this as a dedication to the game, not to profit from it we were going to release it for free, no adverts, no catches, 100% free, as in beer. it is a tribute because SCEE never seems to license content outside of their own hardware, as we have seen in the past - 10 years ago we chased down who owned it, with no avail. it has gotten complex. since then, the only versions have been for the PSP or PS3. nice to see them locking the IP to their own platforms, rather than even being open about discussing other platforms (which technically compete with their own). who's best interest do they have?

some commenters here simply blurt out comments without thinking at times, and it has made slashdot degrade a lot over the last 10 years - it is a sad pity actually.

every lemmings clone that has used the original files or name and left alone every clone that has not.

we have NOT used the original files, in fact - if you read the blog, you will see how we actually generated the levels using bitmaps and text files for configuration, all built without the original lemmings DAT files (yes, you can use them - but we did not). right now, it comes down to the Lemmings trademark with video games and the look for feel issue.

nice to get slashdotted twice in a week - the website still seems to be up this time around.

since i am on vacation (in egypt) for two weeks - i had to simply withdraw the submission and downloads from the application catalogs and own website, since sony gave a 48 hour window, i can deal with it in more detail when i am back from vacation. as for the intellectual property, no original code was uses (in fact, the palm os version was my own implementation) the only thing that is definitely "used" is the name (Lemmings) and the original EGA graphics from the game. even the levels are redesigned in the event that they are not workable with one player mode and the limitations of the palm os platform

IANAL - but since no original files are used, in fact everything is re-created without reference to the original source code, the only infringing rights here are the use of the name "Lemmings". there have been a number of copyright cases dealing with the look and feel - so it can go either way, intellectual property rights come down to if a jury believes there is confusion between the original and the remake.

i will try to open discussions with SCEE (Sony Entertainment) about getting an official license for the game, in fact, we were looking for the original license holders back in 2001 when we did the palm os versions - but it was in flux between Take Two Interactive, Sony and no-one knew their ass from a hole in the ground. the good news is now SCEE are claiming ownership, so we can now talk to them - and we have proof of concepts made, so if they play nice, this title will officially come to these platforms, if not - then you can start saying how evil they are.

lets see how the discussions go!

Then how do you target BlackBerry and Android, both of which use Java?

android - NDK (native development kit)
the library portion i provide is actually still Java; but with JNI calls to the real meat of the code.

Or how do you justify to your boss the lost sales from not targeting these platforms?

i support android - i have demo versions in place - so, thats not an issue. as for justifying it to my boss? i am my own boss - justified. but you do raise a valid point.

90% shared code? so what? (Score:-1, Troll)

is it me - or are some of the slashdot moderators total idiots? either apple or microsoft fan boys. when i was your age you were probably still in diapers. obviously they miss the point. oh well.

If you are writing different libraries for each platform -- that's not 100% code re-use

sure it is. if you use libc - is that code re-use? i have done a library for a generic platform for developing on top of. it is a library; that as a developer you dont have to write - you just use it.. just like openGL, libc, mathlib et al

You're not "just distributing" the same binary for each platform.

unless there is a universal "thick binary" standard; you are going to have to ship different binaries. thats how it is.

What are you using for graphics, sounds, storage, etc. on each platform?

graphics - you can generically define graphic sets based on DPI. scaling, layout design. it is not difficult to play with different resolutions. as for audio; worst case; you have PCM audio.

You're doing this without a bunch of #ifdef's?

yes!

How are you accounting for different screen resolutions, graphics hardware, touch capabilities, and other hardware difference?

very good design. :)

but seriously - a good architect design can allow you to dynamically detect, load and work with functionalities across platforms. abstraction is dangerous - as it typically defines a common denominator. like web technologies are being dynamic in the way they work (ref: RESTful) - you can do the same with programming.

i've been working with mobile platforms for 10+ years and i've played with almost every platform out there. i avoid .NET and Java like the plague for mobile applications - the end results are very slow and just doing deliver what i want from a programming environment.. sure, i need to do more effort - but the results are better.

this is what i do for a living as well. if you want to discuss more offline - you can reach me via the contact me section on my website.

i've been writing code across many platforms with 100% code reuse - more importantly, not using a runtime - all my applications are native. just write a few basic entry points; put the platform specific points in a library and then all your applications link against this. you then end up with native binaries for each platform - just distribute. this is not news - most developers have been able to do this for years (including myself). i can build applications for windows, linux, macosx, iphone, windows mobile, symbian series 60/uiq, palmos, moblin, maemo et al by doing this and i've been doing it since 2003.

i think this information is out of context. it is very unlikely developers will be abandoning platforms like the wii, ps3 et al - they will most likely be looking to use the iphone as a complimentary development platform more than anything else. there is just as much business everywhere; and if everyone was moving to the iphone - i would probably get out of it :) i was there from the beginning as a hobbyist - and it already is getting flooded and saturated.. it is a pity honestly.

10.3 was powerpc specific - and you can see from the screen shot that they are using pearpc - a powerpc emulation engine.

what would be much more interesting is to port iphone os to the n900 - it has an ARM cpu and should be able to run about the same speed as the iphone itself - that is more a challenge. putting msdos on symbian, android, iphone os, windows mobile is simply a matter of porting dosbox or so; when will someone take on the true challenge :) take a recovery image and flash it to an ARM device with similar specs.. should be doable :)

wow.. you surely must not get it.

what do you think the JVM is written in? JIT support is NOT available on mobile implementations typically . your confusing the advances in desktop Java vs the mobile versions.

C does not require any virtual memory / exception handling.. and most C++ support requires you disable it anyhow. if you screw up your memory access; of course it'll reset - thats something you'll learn as a mobile developer.

actually; the platform i'm built has layers for:

- palm os (68k)
- palm os (arm)
- tapwave zodiac (drm specific)
- windows mobile / pocket pc
- vtech helio
- symbian s60
- symbian s60 (3rd+) (binary break)
- symbian uiq,
- ebookman
- gizmondo (gaming handheld)
- sony psp (homebrew)
- windows desktop (95+)
- linux
- moblin (drm specific)
- mac osx
- iphone / ipod touch
- android (in beta now)

the platform is just a target when we compile :)

for android; we have a thin Dalvik application that gives us a window; from there - we have a native call using the NDK to render the framebuffer that we show as a window within the application itself.

you would NOT build different versions for droid, htc hero, G1 etc.. as long as they use the same CPU architecture (ARM in this case); the applications will work across the various devices.

depending on the phase - we have the various platforms running at the latest version; the key point is our applications use a common source code base - so, adding/removing a platform does not require any changes to the application itself.

if you have further questions - please don't hesitate to contact me. we've been building this layer for over 8 years now - and we have seen platforms come and go! our framework has been used commercially; but as a platform - you don't see it when it is being used.

my point is he shouldn't be complaining about good debugging environments. be happy and thankful he doesn't need to deal with printf() for debugging.

for applications you intend to sell on the app marketplace, you use C++?

YES!

actually; we use C basically - on iphone; you need to have some objective-c wrappers to handle the device specific execution entry point. on symbian; you need C++ classes for the the framework base.

you do need to re-compile your binary for every PLATFORM (not device). if you want to see it in action; check out http://www.mobilewizardry.com/multi-platfori/atariretro/ (commercial applications) and http://www.mobile1up.com/ (iphone, desktop apps) - this is what i specialize in. when i hear about platform fragmentation i laugh. be a good architect - and your problems are solved.

all our applications BUILD NATIVE - so, there is no runtime environments required and we have binaries optimized for the platform. when a new platform comes; we simply rebuild utilizing the tools and/or minimal custom coding for the execution frameworks

Java is he answer to platform fragmentation?

no it isn't - it is in *design* - not in practice.

Java provides the classic write once run anywhere; have you ever tried to build a J2ME client? do you know how many skews you have to build to support all the phones? so much for write-once-run-anywhere.

secondly; since mobile devices are underpowered - you need speed/fast applications to make them useful. Java runs on top of a VM - VM's are slow. you are looking at 20x speed slowdown; and there is no JIT (just in time) compilers available on mobile phones.

Java belongs on the desktop and server - not in the mobile space. you can argue as much as you want - i left Java programming to get into mobile development back in 1999. i've got years of experience within this area; surely more than the author of that article.