Messages

I vote for JJS for the new team leader! Seriously.. Awesome stuff JJS.

Hi guys, I have been searching hi and low for this and I figured if there is anyone out there that can help me with this, it would be the AGS community.

Basically I am looking for an Embeddable scripting language for C++. I have looked at AngelScript, Gamemonkey, ChaiScript, Gecko and LUA as well as Squirrel. I am not really satisfied with them to tell you the truth. If anyone has any idea's, I would really like some help on this. I remember there was SeeR years ago and I really liked that scripting engine, however, its no longer available or supported. So just so you guys know what I am looking for in this:

*Free or very cheap.
*C++ Language Syntax.
*Cross-platform to Desktop OS's and mobile ones.
*GPL, LGPL, Artistic License, etc... You get the idea.
*Small footprint.
*Embeddable.
*Classes and Inheritance
*Exception handling
*Asynchronous support.
*Decent Speed.

Any idea's

I think you have to download the git archive yourself and compile it. Look here:
https://gitorious.org/skygoblinags/pages/Home

I just also wanted to throw this in as well for future ports:
http://allegrogl.sourceforge.net/

[STEP 0: VERY IMPORTANT: Development Forums]

I decided to participate in this source code discussion. Unfortunately I haven't read this whole discussion because I came in late and there is a lot to read. So consider this a new start to the discussion if you would like.

Anyway, here are my idea's of where we can go from here:

STEP 0: VERY IMPORTANT: Development Forums
We need to have some sort of structure for this whole process, otherwise things will get messy and we will be going nowhere with AGS. We already see several repositories for AGS on gitorious besides the official SVN and we have seen several users contribute their own versions of the Editor. This could make things confusing and one version that we like can exclude a feature we want from another build. Lets stop this now. The first thing we need is a restructuring of the Using AGS forums and the addition of the Development forum, followed by an official development team with a team leader.

How would I restructure the forums? Well for "Using AGS", I would strictly make the Technical forum an advanced user forum for feature suggestions and for how to perform advanced operations in AGS. I would then rename it to "General AGS Discussion". Remove the beginners forum. I would then add a "FAQ and Tutorials and Beginners" forum in "Using AGS" and move those topics from the plugins forum to the FAQ forum.

I would rename the "AGS Games" category to "AGS WIPS and Releases" and move the "Templates, modules and plugins" to that category.

At this point I would then add a development forum which would consist of the following:
A. - "Development Discussion" - used to discuss libraries to use, what code to add/edit/remove and other things all related to development. Public Forum.
B. - "AGS Source Code" - A place for the official team to release daily builds of AGS alpha and Beta editions and also updated archived source code. Public Forum.
C. - "Bug Fixes and issues" - a place to post all errors, bugs and things needing to be fixed. Public Forum.
D. - "Private Development Forum" - A place for the official development team to discuss how to code AGS and what official approaches to take next. Private Forum.

STEP 1: Which of the many distributions to use
There is the official SVN version but then there is the gitorious builds. Personally, JJS has developed the best build of the AGS engine and suggest using his repository. His repository works well with many OS's and his latest build is meant to build for Windows, Linux, PSP and Android from the get go. It has the essential feature that all AGSers would like: Portability.

STEP 2: Source Clean up
We should take JJS' repository and begin the clean up work on the source. Perhaps splitting up ac.cpp  and other similar files as well as improving code execution and performance. Commenting should also be added efficiently. One other thing to do is probably also use update versions of the libraries that AGS uses such as Allegro.

STEP 3: Documenting
For better control from this point on, the source code and normal conventions should be documented so that the community can expand on the development properly. This should be done at all times.

STEP 4: Testing
After cleaning the source code, it would be good to test the new engine rewrite with several games on all the OS' supported. Once thats done, we can fix the bugs and move on to the next phase of development.

STEP 5: Improving the basic framework of the engine
I know portability is a priority for many, but honestly, improving portability performance and limit issues, we need to work on the basic framework of the engine. Once thats settled, we can then begin to move on to different things. How would I improve the framework? Like so:
1. - I would begin adding support for several resolutions, in particular all those that would encourage commercial development and those needed on portable systems such Android, Windows Phone, Palm Pre, IOS, etc...
2. - Limitations. One of the many things that you hear complaints of are the limitations on rooms, objects, etc... Do all these limitations need to be removed or edited, possibly not. What limitations to take care of will depend on the community.
3. - GUI's and text parser would be next since thats main functionality of the engine.
4. - The scripting engine is something else that the community may want to edit.
5. - 64-bit inclusion.
6. - Graphical engine.
7. - File resources - how are sprites split up, etc...
8. - Misc items such as using different libraries and such.
9. - Improving the way Plugins are handled so that plugins can easily be developed for all platforms.
10. - Integration of 3D file formats, and other file formats as well as acceleration for future development. Even if 3D is not a feature to add for a while, lets atleast get the framework in there because I am certain it will come.

STEP 6: Bug checks
Needed before we move on to the next step.

STEP 7: Performance enhancements
With all the changes, performance can lag. Perhaps at this point it would be wise to look into improving performance.

STEP 8: Improving current portability
Lets face it, the current ports could always use some working on. If we port the engine to another OS before we make the current ports stable, something will eventually break. We want to make it as simple as possible to be able to take this source code and allow compilation for any of its ports with few issues.

STEP 9: Creating a very stable and current Mac Port
At this point libraries would need to be researched that would perform well with what is currently in AGS. I would suggest having the engine function from MacOS 10.2 and up would be ideal enough of a port.

STEP 10: Windows
No doubt several distributions of Windows can play adventure games, even advanced ones. However, for some reason, Windows does not play nice with itself. Meaning, something that would work for Windows XP will stop working for Windows 7. We need to stabilize AGS so that it can work for Atleast Windows 2000, Windows XP, Windows Vista, Windows 7 and the upcoming Windows 8.

STEP 11: Linux Distribution
With the various distributions of Linux, we need to either make the port universal or develop several other ports for it.

STEP 12: Bug Testing
Once again, lets make sure that nothing is broken and that the new Mac port is still functional.

STEP 13: Porting to handhelds
At this point we can begin porting to the major platforms for handhelds and phones. For instance, we already have PSP and Android. Next would need to be iOS, Windows Phone 7, Blackberry, Palm Pre WebOS, Windows Mobile, PSP Go and Nintendo DS/3DS. You might ask, is it really necessary to port to these? No. But eventually we will want to. Lets keep this in step. OpenGL ES and Phonegap would work best to port to these various other systems with minimal code change.

STEP 13b: Other ports?
At this point, I really do not feel that AGS needs to be ported to any other system than the ones above. However, some might disagree with me. Again, I strongly discourage Step 13b, but if we cant get past it, we need to consider it I guess. Some might want to port to the Nintendo Wii, Playstation 3 and X-Box. If that is necessary, I suggest the following:
A. - We can make it so that games are playable for the Nintendo Gamecube so that it can be played also on the Wii, or we can just make it for the Wii and have it also be supported for the next system that is released.
B. - Create a Playstation one version of the game engine so that it can be playable on all three systems: PS1, 2 and 3.
C. - Create a version for X-Box 360 or for the original X-Box so that it can be playable on both systems.
D. - Scrap all those options above and create a DOS version of the engine so that those systems can play adventure games on DosBox.
E. - All of the above.

STEP 14: Bug Testing again
Yes, its getting annoying, but it has to be done. Trust me. You will thank me later.

STEP 15: Error Logging feature
Looking for bugs in the future can be simplified if there can be implemented an error logging feature into the engine for every time it crashes.

STEP 16: AGS Run Game option
I like this feature and it should stay. Perhaps we can compile older versions of AGS, such as 2.5, 2.6, 2.72 and 3.0 and up so that we can run mini-games or internal-games within the updated version of AGS.

STEP 17: Seperation of Compiler and Editor
This has been long awaited for by many if not all AGS members. Basically, many have wanted to have the whole studio seperated into three components: Editor, Compiler and Engine. So at this point, we can start making improvements to the compiler so that it can be more efficient to use.
A. - The compiler should be able to compile all project files written in text, including room settings and such. It can also compile sprites and other files for our needs. This would basically work similarly to how AGAST and MAD use to work. An editor would write the project out to seperate text files and then the compiler would compile it. This would allow the building of custom editors, interaction editors and portability of the editor.
B. - Make the compiler cross platform to support Mac/Windows/Linux and then the IPad, Android Honeycomb or later, Blackberry Playbook and HP Touchpad.
C. - Create a feature in the compiler that can compile the source code to byte code and that can make the AGS sources unable to be decompiled.
D. - The ability to cross-compile.

STEP 18: Bug Testing
You heard me.

STEP 19: A revised editor
At this point we should consider what future possibilities AGS could have implemented and how the editor should reflect that, such as having 3D characters and objects and how one would edit that in the editor, Better Syntax Highlighting, a Team integration system so that users can work on a project together remotely and other things just to mention a few. However, I think the editor should also better reflect the state and portability of the current Engine. I think it should also be more modernized offering translations, panels and even a way to test the way objects and characters look in a game. And one thing that is also popular in many of today's suites: Theming. I certainly think that the AGS Editor should be Themable.

I also think that the AGS editor should be ported to other OS' as has been requested and asked for for many years now. So perhaps libraries that can be used such as JUCE and QT 4.5 or even WX Widgets should be considered. I would consider a port of the editor to the same ports of the compiler.

Two final things (Yes, I know now that some of these are suggestions) I would like to see return is the animation editor and also the interaction editor for us newbies to the C++/C# programming language.

STEP 20: Backwards compatibility
I have heard the mention of this and to be honest, I am all for this. I hated the fact that for my Simpsons Template, I had to convert it up for every version of AGS to get it to work with the latest. EG: from 2.6 to 2.72 to 3.0. I think its good to be able to have a feature which can upgrade any source version to the latest version of AGS. Lets face it, AGS will evolve constantly and eventually AGS 3.2 will not work with AGS 3.6. So to change that, we could use a system which can convert any older source to the new source. Visual Basic .net sort of used this, so why not us as well? Or another way to handle backwards compatibility is by using source scripts file extensions. For instance, a room file called room1.rm will work for AGS 4.0, however a room file that can be called room1.rm25, room1.rm26, room1.rm272 or room1.rm30 will allow for the developer to develop games using AGS 2.5, 2.6, 2.72 and 3.0 respectively.

STEP 21: Bug Testing
Yep, its important.

STEP 22: Feature additions
Now with the important stuff done and the groundwork of the future of AGS established, we can begin adding new features to it. An area I would like to see added in would be the addition of features that were done in plugins such as particles, paralax scrolling, TCPIP, etc... Then we can move on to other new features such as 3D characters and objects. Each feature should be worked on one at a time. and tested until it is working perfectly and portably. Then it should be documented in the AGS Manual along with a sample code inclusion. After that, we move on to the next feature.

STEP 23: Bug Test
Last one, I promise.

STEP 24: Demo Game
Update the Demo game to work with this version of AGS and make sure it works across all platforms. The demo game will be updated along with each new version of AGS to demonstrate the new features developed.

STEP 25: Website
Revamp it a bit to reflect the new AGS.

STEP 26: Release AGS 4.0
And the rest is history as the development team continues to improve on it and add new features and ports.

I hope this was a good write up, it only took me 3 hours to do.

Yeah, I kind of implied the same idea. My ideal dream of this whole project would be seperate editor, compiler and runtime. Atleast then someone can just port the compiler and engine to different OS's and then editors could be written by different individuals.

This is what I see in the license:
JUCE is released under the GNU Public Licence, which means it can be freely copied and distributed, and costs nothing to use in open-source applications.

This is what it means to me:
AGS Editor and AGS engine are two different entities as far as I am concerned. Both are open source. The above states that it costs nothing to use in open source applications. It also states it can be distributed freely.

As far as I am concerned, JUICE would not be used in the games being distributed or sold. Only in the already FREE editor. As far as the editor goes, to me its similar to an app such as Eclipse or Visual Studio. Its mainly used to develop the game. Not run it. Its components are not used in the games itself. So the way I see it, it would still be a viable option for the AGS editor.

If worse came to worse, perhaps we can raise money for the unlimited license.

See, this opens up the editor to be made for Windows/Mac/ Linux as well as some portable devices such as the IPAD and Android tablets for game development on the go. Its a good first step in using code thats highly portable.

Website: http://www.rawmaterialsoftware.com/juce.php

What is it:
JUCE (Jules' Utility Class Extensions) is an all-encompassing C++ class library for developing cross-platform software.

It contains pretty much everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound.

Supported systems:
JUCE can target the following platforms:

    Mac OSX - Applications and VST/AudioUnit/RTAS/NPAPI plugins can be compiled with Xcode for OSX 10.4 or later.
    iOS - Native iPhone and iPad apps can be built with Xcode.
    Windows - Applications and VST/RTAS/NPAPI/ActiveX plugins can be built using MS Visual Studio. The results are all fully compatible with Windows XP, Vista or Win7.
    Linux - Applications and plugins can be built for any kernel 2.6 or later.
    Android - NEW! Android apps can now be built using Ant and Eclipse, with the Android NDK v5 or later. (This is still a work in progress, so some features aren't still to be finished).

For all the platforms above, the code that you write is the same, and you don't need to worry about any platform-specific details. If your C++ is portable, then you should be able to simply re-compile your app to run it on other OSes.


Design and coding style:
In designing JUCE, I've tried to make it:

    Literate - class, method and variable names are clear, self-explanatory and consistent. It's vital in such a large library that when you look at a class, it should be obvious how it works; and when you use a class in your own code, the result should be as readable as possible. The best way to achieve this is by using well-written names.
    Coherent - a library needs to be predictable enough that once you've got a feel for the way things are arranged, you can navigate around it without any surprises. If you need to do a particular task, you should be able to guess what the classes to do it might be called and find them quickly. (Having a single person write the entire library helps with this!)
    Cross-platform - platform-dependent code is all confined to a single area and kept out away from public view. When you include juce.h, you only include pure C++ classes, it won't pull in any platform-dependent headers. Wherever it's possible to use a pure C++ technique instead of native functionality, I've done so.
    High Quality C++ - having been a professional C++ coder for 15 years, and having studied all the available C++ guru literature, I think I'm finally starting to get the hang of it! Every class in the library is intended to be a good example of the best possible coding practices - so if you spot anything dodgy in there, don't hesitate to let me know!



Integrating into a project:
Adding JUCE to your app is very simple - the easiest way involves simply including juce.h in your files and adding a single cpp file to your project. No need to compile any libraries or worry about dependencies. Ideally I'd like to have made JUCE an include-only library like the std c++ library.. that's not actually possible because of the platform-specific nastiness that it has to deal with, but to be able to add a complete multi-platform library to your app in only two steps is a pretty good result!

Of course JUCE can also be built as a static library and linked into your application in the traditional way. Or you can use it in its 'amalgamated' form, where the entire library (all 350,000 lines of it!) has been cunningly compressed into just two (large!) source files. Having only two files to deal with means that you can easily add a local copy of them to a project and check them into your source control system, avoiding any external dependencies.

To further simplify the process of building across multiple platforms, the Introjucer will automatically generate all the compiler-specific project files you need to get the same app running in Xcode, Visual Studio, etc. Just use the Introjucer's IDE to build your project, and it'll take care of the hassle involved in keeping several different IDE projects in sync with each other.



License:
JUCE is released under the GNU Public Licence, which means it can be freely copied and distributed, and costs nothing to use in open-source applications.

If you'd like to release a closed-source application that uses JUCE, commercial licences are available for a fee - click here for more information on pricing and terms.

JJS, any chance you can create a customized editor that would compile a game into an APK with the AGS engine?

Or possibly a way to create an APK with a config file that indicates where a game can be downloaded from sort of how some EA games do it. This way we can all submit our games to the marketplace, even commercial ones.

Hey JJS, any chance that we can get an updated build of whats on Gitorious since I still cant seem to build using c++?

Cafepress.com
Painted4u.com

Is it just me, or has many in this community become more hostile towards eachother? Come on guys, we are all in this together. Are EEe ESS PEE EEE SEE TEE EEE guys. 

http://www.adventuregamestudio.co.uk/tracker.php

Amazing job as always!

Yeah, and just so anyone knows, the two best apps to get for android tablets is Sketchbook Pro and Adobe Photoshop Touch. The two together will run you around $12, but at the same time, you have some quality tools on a tablet. Sketchbook pro is great for actually creating and editing art, while the adobe product is great for touch ups, edits, and special effects, etc.. You go between the two and its as if you had a quality art package right on your tablet.

As far as stylus go, for either ipad or android, the best type of stylus to use are Gomadic type stylus for capacitive touch screens that focus on precision. Get one of those and it would be as if you had an actual pencil and paper. Of course, those cost a lot more than a regular stylus. It might run you around $40 to $50.

For my adventure games blog I have fixed the site a bit.

I started two new blogs, one is related to adventure games and the other to Android Devices. I posted my first article which is actually a nice cross-over article between the two. If you want to take a read, I will try to post a few times a week on each:

http://longliveags.blogspot.com/
http://androidgetsit.blogspot.com/

Was this done with your new android tablet by any chance?

I am sure the ipad has some great drawing apps. I just don't know of any.

Lol. Hope you get it. I would have personally waited for the next asus tablet coming in december. Lol