Slashdot Mirror
Mobile Game Applications Need Scripting Too
An anonymous reader writes "Mobile game developer Tom Park believes that scripting for wireless devices is important for proficiency sake. And with the need to scale mobile applications across so many different platforms, proficiency is everything.
Read his thoughts on scripting, as well as his ideas on wireless application development's future."
I wish that wireless applications would get at least a little bit faster, first. The J2ME software for my cell phone runs like molasses in Fargo in February. I've tried three different phone models, and they all simply cannot run things well enough to be usable.
I don't know if it's strictly a hardware issue or what, but I know that I certainly have written off mobile apps for at least the near future until I can get a phone in my hands that can actually run things well.
What's true for the Sims and mobile apps is just as true for business applications.
The first trick is to define a language that expresses the highest level of abstraction you can, thus giving your developers the most powerful modeling tool they can get. The second trick is to do this economically. Hehe.
My team does just about everything with scripting, using XML languages as the scripting language and a code generator (GSL) as the metaengine. It's a good combination that lets us hit any level of abstraction we need to. Using XML is a bit clunky, but it gives us a single syntax (and single parser) for all our scripting languages. GSL... well, that's another story. Let's just say it does this kind of thing wonderfully.
Ceci n'est pas une signature
Right.
That's a separate issue though. Unix needs a universally accepted binary component protocol. We need one badly.
Traditionally we've always used libraries to share functionality amongst seperate programs. But libraries make it difficult to make decisions at runtime, and discovery of shared libraries at runtime is primative at best ( LD_LIBRARY_PATH, etc. ). Most component archs/protocols offer a registry for finding exported interfaces, ie. functionality, at runtime. The application just needs to know the version of the interface it requires. eg. the application asks 'I need SpellChecker Interface v 0.5, does anyone provide that?' A KDE module may respond, a Java module may respond or a GNOME module may respond.
I believe GNOME with bonobo, KDE with kparts, and JCP with Java's Corba/RMI need to get together and work out a baseline common binary component standard. That's wishful thinking, granted, but doing so would do the linux community a world of good.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
i wish my phone had scripted menus and interface. you could change anything in the menu, add your own custom functions, etcetera.
like taking a picture and uploading it to your web page and then bringing up a form for you to enter a caption.. or to run an executable to turn your voice mail into a text summary.. the possibilities are endless.
i'm sick of hard-coded phone interfaces built for a particular type of user who is most often Not Me.
Having written a fair number of applications for cell phone J2ME and Symbian let me just say that all of the folks out there trying to blame Java for the woes of their cell phone being slow are barking up the wrong tree. The problem with speed is a function of the trivial amount of CPU that's available in the phone at this point. That is something that's getting better over time - as is the issue with RAM in the phone. Wireless applications need better CPUs, better input devices, and a better data network infrastructure (in the case of cellular networks) before they need scripting. That's not to belittle the position or to say that it isn't something that's important to someone out there - but the current condition of the phone from a technology standpoint is not well suited to to imposing a scripting engine that requires scarce resources. One has to look at the reality of the market as it exists and the devices within it before trying to add more stuff to it. Today as the devices stand - the vast majority of them just don't have the resources necessary to handle scripting. The situation is improving and one day we'll be at that point (12-18 months from now) - but today adding scripting to the resource starved devices is just not a good move... especially given that someone would in many instances have to download 150k of scripting framework onto the phone - a size larger than many wireless applications. When you consider that wireless users pay for this by the meg (or in some cases by the K), it becomes pretty clear that the market isn't yet ready for that.
I don't have too much experience with current mobile devices, but I'd say that they need a bit more processing power/memory/etc under the hood before any really good, serious scripting can be done for them. The cell networks also need to become a good bit more reliable(at least in the US). My parents still can't get proper coverage for their cell phone at their home due to geography.
So, while you(and the main article) make some interesting points, I think that it's a bit too early to talk about scripting.
The article also strikes me as being a bit of a propaganda piece.
Actually I think VBA comes with windows. After all, those .vbs viruses didn't seem to have much trouble finding hosts :P
autopr0n is like, down and stuff.