Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Wireless Networking Programming Hardware IT Technology

Mobile Game Applications Need Scripting Too 92

Posted by Hemos from the and-naughty-girls-need-love-too dept.
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."
This discussion has been archived. No new comments can be posted.

Mobile Game Applications Need Scripting Too More

Mobile Game Applications Need Scripting Too

Comments Filter:

  • Speed & Efficiency (Score:5, Insightful)

    by InfiniterX ( 12749 ) on Monday September 01, 2003 @01:37PM (#6845442) Homepage
    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.

    • Re:Speed & Efficiency (Score:3, Interesting)

      by Zebbers ( 134389 )
      what are you talking about

      my nokia 3650 runs things just fine
      including a gameboy emulator

      • Re:Speed & Efficiency (Score:1, Interesting)

        by UfoZ ( 680310 )
        Well, the gameboy emulator runs natively on the phone, and doesn't rely on the Java VM. You can get the Symbian SDK for free from Nokia and make your own apps in C++.

        I've tried a few Series 30-40 Java games and my only gripes would be horrible startup/shutdown times. It kind of destroys the "spontaneous" nature of the game when it takes 20-30 seconds to load.
      • Here is the source code for the gameboy emulator for your nokia 3650:

        http://www.wildpalm.co.uk/GoBoy/GoBoy7650_12_src. z ip [wildpalm.co.uk]

        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 emu

        • Sorry, I was wrong. The Gameboy emulator for the Nokia 3650 written in C and Assembler Code, instead of Java. It's not "100% Pure C".

          Now what are you talking about how the Gameboy emulator written in C and Assembler proves that Java runs fast on cell phones?

          -Don

    • I think the hardware will continue to get better and better. While I do not think the apps are as slow as what you are describing, I think there is room for improvement. Right now, I know there are different JVM's for cell phones based on the hardware- how much ram you have.

      What I think would be cool is to get higher transfer speeds on wireless devices. Once that is done, I can see endless applications.

    • Re:Speed & Efficiency (Score:3, Insightful)

      by gl4ss ( 559668 )
      what is your meaning of 'usable'?

      news ticker doesn't need blazing speed to be usable and neither does blogging tools.

      that being said it is possible to make, for example, an xpilot clone on 3650/7650 that runs ~20fps prettu easily(in other words dig dug and most other 80's classics can be cloned pretty well). however when writing it can be a try-and-miss effort on finding out which approach is the fastest, whether the vendors own ui is faster or not and if there are any _really_strange_ bugs(and finding ou

  • BeanShell - Embeddable, Java compatible scripting (Score:5, Interesting)

    by patniemeyer ( 444913 ) * <pat@pat.net> on Monday September 01, 2003 @01:39PM (#6845452) Homepage
    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.

    • 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.

      • 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

      • 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.

        • 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 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

    • BeanShell is already widely distributed with Emacs

      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,

    • 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...
  • 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.
    • 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
      • GSL is usually written G/S/L, and stands for "Goals/Sex/Language?". It's a common question on the "Seven Habits of Highly Effective Daters" chat rooms.

      • Implementing special purpose scripting languages with XML is a great idea

        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 d

      • Note that the original article discussed scripting as a development tool, not as an automation tool for end users. It's in this context that I like XML.

        Yes, it's clunky, but it works exceedingly well if you have the tools to handle it. GSL is the "generator scripting language", a tool made by iMatix and distributed as part of their RealiBase [imatix.com] package, a rather large and eclectic collection of OSS tools.

        Personally I find GSL extraordinary, but totally outside the scope of this discussion. I simply can't

  • All applications need scripting.... (Score:5, Informative)

    by wowbagger ( 69688 ) on Monday September 01, 2003 @01:40PM (#6845456) Homepage Journal
    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.

    • Re:All applications need scripting.... (Score:5, Insightful)

      by Kunta Kinte ( 323399 ) on Monday September 01, 2003 @02:11PM (#6845552) Journal
      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.

      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.

    • I think you're forgetting about a language.

      Windows can be scripted with Jscript or VBScript using WSH (Windows scripting host). Jscript is very, very similar to javascript (I think that javascript may actually be a subset of jscript), which is universally available.

      As far as being "a part of the standard Windows install," I suspect it depends upon your version of Windows. I know it comes with W2k, and doesn't with Windows 98, but I can't speak for the rest.

      Still, I'm not sure that this is a good thing. Windows doesn't insulate itself against scripting attacks very well at all by running parts as different users. So anyone with WSH installed could be in for a world of hurt if a bad script comes along in viral form.
      • However, in order to use scripting, windows applications need to be created with scripting capability from the start, right? Can you take any old windows app and create a script like this: "clink on that button, insert this text there, etc"? If this were possible, I would have a good application for it, testing changes in legacy applications.

    • (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)

      Ah, good ole batch files. Yes, they can do the first task you mention just fine (albeit extremely mundane compared to shell scripting).

      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 bat

    • This is an area Unix-like environments (including MacOS) need to really improve in.

      Actually, I'd like to make the argument that Mac OS X has a perfectly good scripting environment for its GUI apps - AppleScript.

      Yes, apps do need to support AppleScript on an individual basis. All AppleScript apps can speak between each other. And with Apple's recent addition of the AppleScript Studio, the script itself can have a GUI interface as well.

      The thing that is difficult about adding a scripting language to

    • Actually I think VBA comes with windows. After all, those .vbs viruses didn't seem to have much trouble finding hosts :P
  • 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

  • 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 up

  • scripted interfaces (Score:3, Insightful)

    by Anonymous Coward on Monday September 01, 2003 @02:13PM (#6845560)
    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.
    • 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/ [sun.com]. 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.
    • another reply pointed out to j2me.

      this is useless for the thing you're looking for, but you can do that in symbian(there's at least some apps like that for series60 phones).

      -
  • or is the appearance of this article and the last one a strange coincidence?
  • unleash teh script kiddies!
  • 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
  • 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
    • You're absolutely right of course. The exclamation that kept floating through my head as I read the article was, "Duh!"

  • Yes, they need scripting - but that's not all (Score:5, Insightful)

    by PierceLabs ( 549351 ) on Monday September 01, 2003 @03:03PM (#6845768)
    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.
  • ...this [wikipedia.org] done in the seventies? Everyone in the games business knows this. What did this guy get paid for this article?
  • 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 lang
    • After reading the article, I think you could do what he is after with Java.
      He really after extensability, which is a side production of well designed OO app, and the use of game created SPIs.
    • I agree with your general sentiment, but your details are a little off. Are you seriously suggesting that it takes more characters of Perl than C to accomplish a certain task? While the earliest Lisp interpreters may have been "pure" textual interpreters, almost all modern implementations compile either to an intermediate form or to native code.

      You're right about the line between "scripting" and "general purpose" languages being blurred.
      • 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.
        • Perl does seem to have more complex, feature-ful syntax than C, but that's not what "verbose" usually means in the context of programming languages. Perhaps "rich" or "bloated" might better terms to describe Perl syntax, depending on your feelings on the matter.
  • "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..

  • 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 inst

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close