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.
It is interesting that this article appears this morning, because I have just now posted the first beta of BeanShell version 2.0.
For those of you who don't know: BeanShell is a light weight, LGPL, pure Java Java source interpreter with a minimal footprint of less than 150K (and getting smaller). In addition to interpreting standard Java code, BeanShell extends Java into the scripting domain in a natural way by allowing loose types, method closures, commands, and other obvious scripting language features. And because BeanShell runs in the same VM with your app, you can freely pass "live" objects into scripts and back.
BeanShell is already widely distributed with Emacs, Weblogic app server, Sun's NetBeans/Forte, and many other commercial apps and non-commercial apps.
With version 2.0 BeanShell adds (bugs withstanding) full Java compatibility and the ability to script true Java classes. Scripted classes appear to outside Java code and by introspection as ordinary classes but are fully dynamic and may include arbitrary scripts in their bodies, methods and constructors.
Please check out www.beanshell.org for more and check back for updates on 2.0 in the near future.
Thanks,
Pat Niemeyer
Author of Learning Java, O'Reilly & Associates and the BeanShell Java scripting language.
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
All applications need scripting, scripting needs to be cross-application (one script controlling more than one app) and that scripting needs to be available to the common user if they wish to use it.
This is one of the areas where I feel Windows fell down on the job - while COM allows all applications to make their functionality available to scripting languages, Windows does not provide a default scripting language that is universally available. Yes, Visual Basic will script things, but it is not a default part of a standard Windows install.
DOS had scripting of a sort (batch files), and people used that feature. However, DOS could not script every application, and batch files were missing key elements needed to make them anything more than linear sequences of commands. (Yes, batch files did have IF, GOTO, and so on, but try looping over a set of files, or taking the output of one file and using it on the command line of another file).
Unix has many scripting languages available to it (Perl, Python, TCL, in addition to bash, tch, et. al.), and at least one of them will usually be installed by default on a modern system. They can script command line apps like nobody's business, but unfortunately the more modern GUI apps provide much less scriptablity. CORBA and Kparts might help this if they were more commonly available. This is an area Unix-like environments (including MacOS) need to really improve in.
Granted, J. Random User may not want to get his hands dirty writing scripts, but think about it - if you, the person JRU turns to for help, could KNOW that scripts were available, how much better you could help the poor guy out.
www.eFax.com are spammers
Scripting on handhelds? For action games surely you jest.
This is my sig.
a lot of the best games out there are deployed via wap and sms
and he didnt even mention them
obviously this article was to push developers to use j2me!
also xml is great for translating between different mobile devices
back in the day we didnt have no old school
The previous poster rightly complains that Java is slow and impracticle on cell phones. And you propose to add a layer of interpretation? Totally impracticle.
BeanShell... pure Java Java source interpreter
So, it's not only slow as molasses in Antartica, it's actually even slower? Giving you 3,4,5 nice abstraction layers on a platform (the article is about cell phones) that is slow in pure assembler? Gotta check that out.
I choose to remain celibate, like my father and his father before him.
Implementing special purpose scripting languages with XML is a great idea, and works quite well. What is GSL? And what do you REALLY think about it? -Don
Take a look and feel free: http://www.PieMenu.com
BeanShell is a general Java scripting and extension language. It just happens to be small enough to be useful in some embedded applications.
If it's too slow for a particular application then just compile that code. That's the beauty of a Java *compatible* scripting language... see?
Pat Niemeyer
In reading the article, while agreeing with pretty much everything, I found myself getting more and more baffled by why the term "wireless" kept appearing. I couldn't find anything that had anything to do with wireless comms at all. It was all about developing new apps, but there was nothing at all mentioned in which the wireless nature of your machine was relevant.
I mean, I'm sitting here typing this on my Mac Powerbook G4, which has no wires attached at all, and is getting to the Net via the Airport upstairs. But other than the driver for the NIC, I don't see anything anywhere that needs to know that the machine is wireless. It's the Internet, after all; who cares how the bits get to the other machines. Well, yeah, the guy writing the device driver for the NIC cares. But why would anyone else?
Speed? A dial-up phone connection is even slower, so that's not it.
Portability of the machine? Why would a program inside the machine know or care about that?
This guy seems to think you need to develop software differently for "wireless". What the hell is he talking about? I gotta admit I'm clueless.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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.
or is the appearance of this article and the last one a strange coincidence?
So, it's not only slow as molasses in Antartica, it's actually even slower?
Where do you get off saying this? Java hasn't been slow in ages. Repeating what others have told you is not the same as basing your opinions on fact.
I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.
To work with a set of files, try something similar to this in a batch file:
@ECHO OFF
FOR %%f IN (*.txt) DO TYPE %%f
There are work-arounds for using the output of a program to another command line in a batch file, but they involve a psuedo-command batch file to
set the output to a temporary environment variable. Quite ugly in fact, I dare not scrawl such funk here.
Obviously, shell scripting methods are preferred over batch files.
unleash teh script kiddies!
Hack your mind out of its sandbox.
definately, we have viruses on every other platform, and even some in the moble device platform, but just think about how easy it would be to write a virus once they all have some scripting language. YAY!!
Desktop PC's and web servers have gotten much much much faster, while Java has improved marginally while getting much much much bigger. But cell phones are still and will always be extremely limited in memory and speed, compared to desktop computers and web servers. Cell phones are NOT like desktop pc's or web servers. They run on batteries, and they're designed to be slow on purpose, so they use less electricity. Cell phones are necessarily slow, by design. So Java really is SLOW on cell phones!
So, they want to flood the market with developers who make crappy games and insecure applications for the mobile phone, hence creating a market that the phone makers will make millions off of. Quarter-a-game Arcade on your phone, with cheaply produced games on demand, with phonebook on demand for a price, in otherwords.
It boggles the mind at what kind of scams will be born out of this one, and what kind of privacy issues will come into the scene; Buisnessmen need their cellphones, but, they spend hours gaming on them instead of working, so how do we keep them from gaming? Exactly...
Thank you God, it's a great time to be alive and to be a hacker. >:)
Candy-Coated Knowledge
For creating mobile applications, scripting represents Park's secret weapon. "It sounds like an odd thing to do on small wireless devices, but I actually use a simple scripting engine," he says.
People have been using scripting on small devices forever. Perhaps people still remember Microsoft Basic running on the Apple II, a 48kbyte, 8bit machine? Forth and Basic have been two of the most popular interpreted languages. And, in fact, scripts often reduce size and memory usage of programs.
Oh, and in other news, the Pope is Catholic, and breathing air tends to keep you alive longer.
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.
http://www.wildpalm.co.uk/GoBoy/GoBoy7650_12_src.z ip
It looks to me like it's written in C, not Java. So how does that support your argument that Java on cell phones isn't slow?
Since you're such a big Java fan, why don't you port the Gameboy emulator to Java, and find out first hand how fast it runs and how much memory it requires? Please report back -- it will be very interesting to know how much bigger and slower the Gameboy emulator is, after being rewritten from C to Java. Good luck!
-Don
Take a look and feel free: http://www.PieMenu.com
...this done in the seventies? Everyone in the games business knows this. What did this guy get paid for this article?
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Now what are you talking about how the Gameboy emulator written in C and Assembler proves that Java runs fast on cell phones?
-Don
Take a look and feel free: http://www.PieMenu.com
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.
In my life I've downowded and installed hundreds (if not thousands) of Emacs distributions for at least a dozen of platforms. And I had never had a chance to find BeanShell there. Where do hide it? Or is it possible that you have just mistaken Emacs with vi? How dare you! Oh, by the way, what is the model of the wireless phone that has Emacs in it - I want that phone now!
On a serious note, Java is specially designed to be not scripted - statically typed, eager evaluation, run-time only after a compiler. Every attempt to bring scriptability to Java is making it even slower and even requiring more memory. I've tried BeanShell, Jacl, Jython, Kawa - none of them are good for mobile aplications. All by exactly the same reason: Java itself is the worst case of scenario for embedded applications. Of cource due to its resource requirements.
What's wrong to use scripting language directly, without Java? If you are addicted to imperative semantic (let's say you worked too long with C/C++, and Java and "program" for you is a sequence of commands) then use Python: compact, fast (enough for scripting, at least much faster than any scripting exte4nsion for Java), OOP, widely distributed (not with Emacs, but with many operating systems... just kidding). If you don't have such "imperative" addiction then try Erlang: that langauge has been specially designed for being used in mobile (at first in wireless, but now it's not limited to) applications, it's compact (more compact than JVME), fast (faster than JVME, often as fast as C++), high-level scripting (aka functional-logical) language for disctributed and mobile applications. IMHO ideal choice.
Less is more !
Sure, scripting is easy, but so is Java. Now, you're probably not going to come up with these monster projects for tiny cell phones (yet) so the lack of scalability in most "scrypt-y" scripting languages.
And anyway, isn't the line between "Scripting" and "Compiled code" kind of getting blurred. I mean Perl is far more verbose then plain C. Scheme and Lisp (which are designed to be interpreted textually) are more difficult for more people then Java.
To me "scripting" these days basically means a language that makes it easy to write and modify quick little one-off applications, while "programming languages" are designed to scale to huge projects. But that doesn't mean that "Programming languages" can't be used for small one-off apps.
autopr0n is like, down and stuff.
One of the cooler things about Using the JVM as a scripting platform is that you can write a simple script->bytecode JIT, and have the actual JVM compiler recompile your bytecode into actual machine code.
But I doubt most cellphones have a JIT...
autopr0n is like, down and stuff.
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.
"No.. no! You need to set your phone to not execute scripts from uncertified SMS! And remember to always disable ActiveX MMS components!"
Mmmmm future..
My life is one big siesta in which I'm dreaming I wished my life was one big siesta.
Your phone probably supports J2Me, so you might be able to write code in java and upload it to the phone. Check out http://java.sun.com/j2me/. I'm not sure how much of the cell's functionality is exposed to the jvm. But if you can get to the Camera and do IP you should be set.
autopr0n is like, down and stuff.
ok, wrong time and wrong place to say this: but as a v1 user, I have to say -- BeanShell rocks my world. Thanks for some amazing software!
Errr, most Mobile processors run bytecode natively.
I totally disagree. The resulting "scripts" are just as unreadable as plain code, while taking millions times longer to execute.
If you need a scripting language -- pick an existing one. TCL is _the_ scripting language. Python is close, but has a messy C API. Perl? Well, may be, although I tend to think of it as a "write-only" language (you can't read it)...
But -- for the sake of us all -- don't invent a new wheel, and certainly don't wrap it into XML -- it is a _data_ description language, not _code_ description.
In Soviet Washington the swamp drains you.
>The only pussy round here is the pink taco.
Who's the 'pink taco'? Commander Taco?
If you go and search for GSL, look under its old name, "gslgen".
Ceci n'est pas une signature
And whooooosh, there goes the article flying way above most posters head. Where did he say he thought using Python or any main stream scripting language for developing entire mobile apps on today's hardware was a great idea?
...."
I believe he was talking about domain specific scripting language doing high level abstraction stuff. That's not the same thing as having the full script compiler (text interpreter) and a general purpose language on the phone. That probably refers to using stuff where a few script instructions invoke speedier compiled code with simple conditionals. Stuff like
"if (keypressed up) move ship up",
not "if (inkey blurb blurb) plot pixel 1, plot pixel 2,
or even "if (inkey blurb blurb) erase ship, ship position = ship position - 1, draw ship".
High level really means that. A small (and these can be really small, a _few_ k is often plenty) bytecode interpreter with special purpose high-level commands can do wonders for productivity and can be plenty speedy. It's a very attractive technique for developing software.
-
Listen. Strange women lying in ponds distributing swords is no basis for a system of government.
I didn't mean that it took more code to write something in perl then in C, but rather that Perl has much more syntax.
autopr0n is like, down and stuff.
Oh great, just what my cell phone/PDA needs. Java and Visual Basic based viruses...
I am a programmer, and maintainer, of a large Swing application (used by many hundreds) in Sweden. We had to go to extreme measures to bring the app even remotely up to speed (2001). Never allocate a frame before you have to, pool Swing objects, and so forth.
Even so, our program was VERY slow compared to the VB predecessor. We nearly lost the contract.
1.2 and 1.3 helped a lot. As in slower than a 2 tonne chunk of granite versus a 1 tonne chunk of sandstone. We now have 1GHz+ machines, but we're still talking about 5-10 seconds to to bring up a complex frame that took ca. 0.1 seconds in the VB implementation. 10 second garbage collects are not unusual.
I guess you are going to say that Swing is known to be slow. What the hell should we use? AWT won't cut it, external packages like SWT are impossible. We're firmly up shit creak here (which is why I'm so cranky :-).
For extra credit: Write a small essay on how JIT:ed Java can be faster the C++. Then perhaps a piece on how C++ can be optimized farther that pure C, followed by a write-up on how modern C compilers produce faster assembler then a human programmer ;-)
I choose to remain celibate, like my father and his father before him.