Jump to content

Jeru

Web Development Team
 View Profile  See their activity

  • Posts

    5.197

  • Joined

  • Last visited

  • Days Won

    27

 Content Type 

Posts posted by Jeru

  13. Seeking a Coordinator for the Credits Screen

    in Announcements / News

    Posted

    We get a lot of people asking if there is any way for them to contribute to 0 A.D. without having existing background in C++ programming, 3D modeling, web design etc. So here's your shot: We are looking for a new team member who will be in charge of overseeing the credits screen and compiling the list that will show up on it.

    Credits page coordinator: Help the 0 A.D. development team document who did what for the project since its inception. You should devise a format for the 0 A.D. credits screen befitting the project's collaborative nature and put it up for internal team review. You should thoroughly mine various sources of information to generate a credits list that fellow development team members can agree with. You should reach out to people who may have contributed to 0 A.D. in the past and are unlisted in the credits. Also, you should help devise a system for people who believe they should be listed to ask to be included and have their request evaluated. Good people skills, good written English skills, and attention to detail are a must.

    This is an important role because as 0 A.D. is a non-profit initiative, the people who have contribute to it receive literally no compensation other than recognition of their works. We want to give each contributor proper recognition, with as few false positives (freeloaders) and false negatives (unsung heroes) as possible.

    This role is for hardworking people who are undaunted by the prospect of going back to records from 2003 or even 2001 and compiling lists of names and nicks of people they have probably never met online, but may have been pivotal to 0 A.D.'s development. The person who gets this volunteer position will have to work with existing partial lists, ask old-timers to bring up memories, mine SVN logs, run forum searches, etc.

    Interested parties are invited to apply as detailed in the application form. Thanks in advance!

  18. Just announced: Age of Empires Online

    in Announcements / News

    Posted

    i think 0ad is a good way to show where rts games could have gone instead: less dumbification, more user-made content! (that's what all this '2.0' stuff is about right? :) ('web 2.0' etc.) so why shouldn't it work for games too?)

    Web 2.0 and cloud computing and all that stuff would have never been possible without free and open technologies and standards: HTTP, Linux, Apache, MySQL, PHP, (X)HTML/CSS, JavaScript, RSS/Atom, open browsers, ...

    Perhaps 0 A.D., and particularly the 0 A.D. game engine, can bring forth a similar movement among computer games.

  21. Why chose Javascript for scripting

    in Game Development & Technical Discussion

    Posted

    Thanks for digging that up, Jeru, I was always curious about this :)

    You're welcome.

    For a contemporary observer, it's really quite striking how developed the project was in many respects as early as 2003. It's quite evident from the level of discussions, the documentation, the social interactions and decision-making processes, etc. Consider that this is back when other collaborative projects like Wikipedia were in their infancy.

    That is one of the secrets of 0 A.D.'s success, probably.

  22. Why chose Javascript for scripting

    in Game Development & Technical Discussion

    Posted

    A post by Zeusthor from March 2004:

    Version History:

    7th April 2004 - Gee - Review, OK.

    25th July 2004 - Stuart - Indexed.

    Summary:

    Why we settled on Javascript as our scripting language.

    SUMMARY OF SCRIPTING LANGUAGE DECISION

    by Jeffrey Tavares (Zeusthor); edited by Stuart Walpole (Acumen)

    11th March 2004

    OK, now that the fog of war has cleared away from language debates and Javascript has claimed victory over our lands... err, forums ... it's about time I came up with a little recording of how we came to that choice, for future reference.

    Lua was going to be the language until I came along which may have bummed some of you, but some of you might agree that it's for the better that we changed :). Lua gave a bad taste in the mouth of Svede and I.

    Python was discussed twice within 0 A.D's long life during early 2003. In early 2004, Ferite started to show its true colours. When things started to look golden for Lua again, olsner presented Mozilla's Javascript Engine (SpiderMonkey). I, of course, bent towards not coding in Lua, investigated SpiderMonkey some more and pushed its acceptance.

    So, what made Lua so bad, you say? Back-end wise, Lua is superb. It's fast, small, compatible, and easily embeddable. As there were more programmers than scripters, this made it an easy choice.

    When I joined and took a look at it, I honestly took the effort to read some of the manual and get to know it, but my first impression was bad and my last impression was worse.

    The syntax was too forgiving: you may or may not use parentheses, semi-colons, etc. Would your English professor give you the choice to miss punctuation if you felt like it? This would have presented code readability issues as scripts got complex.

    The second big reason why I didn't want Lua was the meta tables concept which is supposed to replace arrays, classes, and the whole lot of stuff. I'm sorry, but there is no way you can create a Swiss army knife to replace programming concepts and expect it to be a better solution. Call me stubborn and close-minded, but I didn't like the way things were done in Lua.

    With Svede agreeing with me, I knew I wasn't too far off in judging it the way I was. So, he had me find an alternative and so I did.

    The first alternative was Ferite. I spent a few hours looking through google, sourceforge, and freshmeat. It was the only one deemed "acceptable" for my standards, probably because it was very similar to C#.

    I read the language manual in full, and did some speed reading of the backend manual and thought it was able to compete and advertised it in the forums to see what the programmers thought, which started a civil war.

    In the end, Ferite's developers didn't keep to their word on release dates and weren't dependable. The engine was trivial to implement, took a bit longer to understand, and to this day, hasn't been ported to Windows even though the main developer stated a release near early January of 2004. Despite the language features, I had to let it go because the engine wouldn't put up and the developers didn't put out.

    Along my opening of Ferite, Python popped into the discussions somehow. Python was obviously powerful, and has proven to be successful in many applications. I don't have much to say for Python because it wasn't actively in discussions.

    A Python scripter, Oluseyi, provided us with an assessment of Python, and concluded that if the system core was scripted (minimal data passing/conversion), or we were using parallel execution threads, then the features and robustness of Python would make it a good choice. We're using the scripting language as a simple extension mechanism for the core, so he advised it wouldn't be an appropriate choice.

    We all ended up choosing Javascript because it fulfilled backend and frontend requirements set by the team. It has been proven in two game engines, the browser, and a 3D development application, which gave us a sense of security along with the fact that it's being used and developed by Mozilla.

    Javascript is a well-known language which will help public acceptance when the game is released, and it is fairly easy to implement.

    Alan has been working hard to do some real testing of its capabilities especially speed and it has proven to fare well under anticipated conditions (although this was questionable at an early stage).

    It seems like we will be staying with Javascript. It is stable, powerful, fast enough, recognisable, and progressing (2.0 is on the way).

    • Like 1

  23. Why chose Javascript for scripting

    in Game Development & Technical Discussion

    Posted

    There was a huge argument/fight over it in 2003-2004. I just looked it up. Lua was considered alongside Ferite, which was the state-of-the-art language then but was not yet mature.

    I'll copy-paste some posts from a thread where some programmers first wrote they liked JS:

    Backend functionality (from the Scripting Backend Functionality thread)

    FSMs:

    1) Multiple script contexts. Check.

    2) Ability to get/set a script variable value from within the engine. Check. (JS_LookupProperty)

    Global variables are properties of the "global" object.

    3) Ability to call script functions from the engine. Check. (JS_CallFunction)

    4) Ability to call engine functions from the script. Check. (JS_NewFunction)

    Data Structures:

    1) Ability to create variables, arrays, and objects. Check.

    2) Ability to expose complex engine data structures and classes (possibly with a custom interface).

    You would create objects, and add methods and properties to them. I am unsure whether it is possible to assign a JS property to a C++ getter/setter.

    General:

    1) To pause scripts during execution and, later, resume them.

    There's a debugging API (it is enough to drive the Venkman Javascript debugger used in Mozilla, so it should do it)

    http://lxr.mozilla.org/mozilla/source/js/s.../src/jsdbgapi.h

    I'm unsure whether another script can execute at the same time, sharing data with the aborted script. You can have several JS contexts (each of them bound to one thread at a time), but the docs doesn't say whether the different contexts (in different threads) can share their global object.

    2) To restrict access to any unsafe features of the scripting language, if applicable: File I/O, network access, system diagnostic, etc.

    JS supports a system similar to Java's security system. I haven't looked too much into it - but there's a framework for it, and I guess the framework is heavily used in mozilla (why else would it be there?)

    3) (Preferably) To run like the proverbial bat out of Hell.

    Unsure - haven't actually used spidermonkey anywhere (except my everyday usage in Mozilla). I think we should (have) run some speed tests on JS too.

    Spidermonkey also has unicode-versions of most (if not all) APIs

    Embedding seems to be well-documented. Whether it's as easy in implementation remains to be seen.
    I looked through the frontend functionality post, and JavaScript basically supports the works.

    Unknown whether JavaScript supports file/library inclusion natively, but theoretically it should be possible to import a C++ function that parses a file and adds all the stuff to the scripts namespace.

    I just spent a pleasant afternoon trying to embed JavaScript. I'm impressed with how easy it actually is: From downloading the source to having functions, data, classes working within a script in about 3 hours.

    As for the language itself, it feels just as C/C++-like as Ferite, or more so, and it seems far more likely to be around in five years time.

    I've also checked against our backend lists: JavaScript supports Regex, Unicode, and most of the other requirements we had, and is the only one so far to have the security framework. The only thing that I'm uncertain it will do is the pause/resume of scripts. Also, there's a fair amount of JS tutorials on the web for learners, though most of them use an internet-based point of view.

    I found another thread from '05 on the topic with posts by Philip (Ykkrosh). He is still on the team so you can pick his brain on this topic.

    From the frontend functionality requirements thread:

    >> Automatic Conversion: Data should be automatically converted when copied between variable types, especially when working with strings.

    >> Basic types: No need for doubles, unsigned etc.

    * int

    * float

    * string:

    We really need string/array functions. XS kept scripters limited with options and even having to create workarounds because they lacked this.

    I mean a REAL string class, NOT c-style strings

    all major string features normally found needed, including automatic conversion and concatenation

    * boolean:

    * custom objects:

    STRONG OOP, inheritance, etc

    Real (or as real as possible) OOP: I want classes, objects, inheritance, and all that good stuff. It doesn't have be complete and standard OOP though.

    I find this EXTREMELY important whereas im basing most of my design upon this.....basically im allowing anything "related" ot the game (GUI objects, chat, certain messages, unit/building/object attributes etc etc to be used in an almost trigger fashion (condition/effect)...i have found OOP not only beneficial to this, but almost necessary

    for example:

    CODE

    if( button1.is_pressed() ) {

    unit1.attack += 5;

    // somehowe find a scriptable and clean way to make this change back after so much time without too much lag

    //(this is a special ability)

    }

    (I know from WC3 scripters thet WC3 allows scripts in the editor that allow for is_pressed() type ideas...)

    As for inheritance, this is required for the whole object setup etc

    Lastly, but not least, we will need to be able to make custom objects of some sort possibly....not quite sure yet tho.....extending hard-coded ones might be enuf, but im thinking they wont

    * Null value:

    NOT necessary, but nice.

    * const:

    keyword or whatever the language would call it (ferite calls it final).

    * array:

    In AoM this was surprisely used a LOT...however since there was no array available, scripters needed to make pseudo-arrays that were horribly sloppy, inefficient, difficult, etc etc....often scripters would opt not not to use arrays due to this very fact. If im correct the pseudo-array was rather an ugly/pseudo- meta-table. Go here for more info on this: http://www.woadcreations.nl/articles.php?g...&artid=1#arrays

    Arrays can be used in various items ranging from actual game data code to AI queues to random map and scn scripting....thus I feel proper and easy/clear array syntax and representation is a MUST. smile.gif

    * Tables, DBs, multi-dimensional arrays:

    I can see quite a few uses for these, including in AI and random map or scenario scripting....mainly to layout the map and identitfying coordinates/positions..

    * Queues, Stacks, et al

    Ive seen numerous usage of these, including for message queueing and random map and scn scripting. If at all possible, i would be preferable that these be 'dynamic' altho if not possible, this might be implemented via a good array system.

    * regex:

    Its too much to explain all the uses of this in scenarios and AI, etc etc, the most important use being parsing chat dialogue....adds a new and powerful element

    GENERAL:

    >> Conventional coding: Typical C/C++/Javascript/perl/php/java syntax, functions, types, objects, control statements and scoping.

    >> Ability to allow scripters to create their own modules/function libraries.

    >> Error handling: Error messages, debugging tools, etc etc for creating a debugging tool like XS had would be a very welcome sight!

    LIBRARIES:

    1) Library Inclusion: ABSOLUTELY MUST ALLOW THE INCLUSION OF SCRIPT FILES/LIBRARIES INTO ANOTHER SCRIPT. svede can glady rant about this as his biggest problem with XS.

    2) Math Library: Access to sin, cos, sqrt, etc in the engine, so scripters don't have to write their own.

    • Like 1
×
×
  • Create New...