Messages

Hi Amelie,

Thanks for the comments. Well, I  don't think I have been gone long enough to make a reply on that thread. I also do not think I am well-known to tell you the truth. Long time member... Yes. I have been here since the beginning with when AGS was AC. With the exception of m0ds and very few other people, I may have been here one of the longest. Actually, I think I was here before m0ds. At the very least the same exact time. I certainly am not completely gone from this site and the forum. In fact, I log into the forums at least once a week if not more. I post every couple of months. So I am not exactly inactive here. I just have a full time job and children, so it becomes much harder to be involved in online projects anymore. My current project is here: sw-bfs.com but that is very slow going and not an adventure game. I actually very much look into AGS and keep up to date with it. However, it has been a while that I have been working with Adventure Creator and Unity. My preference is always AGS, however, AGS seems to be at a stand still(Or slow moving at the very least). If things picked up a bit and the engine progressed to the point where we can fully integrate our games into more OS and move past the old restrictions once and for all, I would certainly be using AGS far more than any other engine. I am nostalgic for it after all. Thanks for asking about me though!

First off, I am not making this game. However I am very impressed by it. I know I don't post here often these days, but this merited a post. Its not an AGS Game(Sorry), but the graphics and feel of the game are stunning! Take a look here:

http://www.adventurecreator.org/forum/discussion/2198/mold-working-title
https://moldgame.wordpress.com/
https://www.facebook.com/moldgame

I was thinking on a broader scale...
1) more resolutions
2) no numbered limits
3) already set to port to other OS
4) more stability with an already in place engine that uses OpenGL and direct
5) more extensible plugins.
6) an editor for Mac
7) and yes , because it is free too.

Even if unity removes a feature or their pricing plan, you can still keep it going for Unity4. I don't know. Thought I had something going here for a sec...

I know this sounds crazy, but I have been working with the free version of Unity3D and I am getting used to it. It takes a little learning, but I am getting the hang of it now and it really is quite something. Especially when it comes to porting. I was able to get all my little test projects(Albeit crappy with no real purpose- just for learning) to work very well on my Android device, my brothers iPhone, My windows/Linux Box, my friends Mac and on the Blackberry/Windows Phone 8 emulators. I didn't have to change any code to make it work on either, at least not for what I was doing anyway. Unity accepts plugins of all kinds (Look at Adventure creator) that can do so much with its games and tons of assets that are real nice. Unity is tailored, whether intentionally or not, to work well with 3DS files, Blender, Maya and Reallusion products.

Now before you think I am nuts, even though you probably all do already, we had discussed the option of creating AGS from scratch. Why not start with this? One development team can work with the old AGS to add support for playing older games and possibly porting to a few other OS just so we have something that can play our old AGS Games. Perhaps this team can even collaborate with SCUMMVM. Or if this team would like, they can begin porting AGS to run within Unity if they really wanted to.

However, another team can begin working on creating a new AGS in Unity. My friend was showing me Adventure Creator for Unity and I just kept thinking that AGS could do this. Now hear me out on this. I think I am on to something. As I will mention again later on, Unity makes a perfect platform for AGS to be developed on as it already lays the groundwork for us when it comes to Graphics, physics, logic, compiling, etc... You can read XML Files which the .AGF files are. You can create drawing and editing plugins within Unity. Unity has a dialogue system which can be easily crafted to match ours. Unity can create custom GUI's which we can turn to our adventure to make Adventure GUI's. Unity even uses C# as a scripting Language which our current AGS Editor is made in!

So then if we go this route, why can we call it AGS? Is it REALLY AGS Then??? The answer is YES. The reason is Simple. Because we make it so that it mimics 2D game creation just as AGS 3.3 and below did, even allowing our project to import AGS projects into Unity and continue game creation from there. We call it AGS because it will be a free plugin. We call it AGS because the plugin will make the interface look like the current AGS editor. We call it AGS because it is worked on by the AGS community. We call it AGS because it will still be Open Source. Basically, even though we would need to learn a little about the Unity Interface and set up, the rest will be exactly identical to AGS in every way.

What are the pro's and cons of this??? Well...

Cons:
Unity will only allow you to sell games royalty free if you make less then $100,000 in a year. Then again, if you make $100,000 within a year, you better buy the darn license!
Unity takes a little bit of time to get used to.
Unity will not have AGS Script capabilities without it being hardcoded into the plugin.
The AGS Development team may need a little time to learn Unity and plugin development.

Pro's:
Unity Editor is available for Mac and Windows
Unity's Engine is available for Mac, Linux, Windows, Android, iOS, Blackberry, Windows Phone 8, X-Box, PS3, PS Vita Beta, Nintendo Wii, Flash(Although this may be discontinued in version 5) and the web. All that with little effort to port your game.
All the main graphical features are already taken care of (Shaders, resolution, Physics, etc...)
Unity can make use of plugins and extensions(Such as LUA plugins, pathfinding tools, GUI designers, etc..).
Unity is completely free to use unless you make $100k.
Unity has an Asset store which a user may buy or sell assets royalty free.
Unity supports custom Scripting called UnityScript as well as Monoscript, Javascript, C# and Boo.
Unity has over 2 million forum users which can aid adventure developers much how the AGS forums have.
Unity already has many other features hardcoded that AGS has, but just needs to be tweaked into an interface we are familiar with(Scripting, pathfinding, dialogues, GUI's, Translations, Voice files, etc...)
With what Unity supports, AGS has potential for growth (A real Particle system, Camera tools, 2.5D support, etc..)

I know this sounds crazy, but I am just trying to think outside of the box. I think we really have something here. I know the odds of this happening are slim to none. I probably will be flamed for it here too... but I would regret not trying. What do you all think about that? Is there potential for this?

Monkey, are you able to provide just the AGS library files in a zip? For some reason my ndk only compiles the arm version which probably is enough anyway...

No. I believe the instability was fixed in the latest commits to the git.

Well some good news. I managed to get a good compilation  for my APK with OBB's, I may post a tutorial either tomorrow night or the next night. Thanks to M.M.'s version of the APK he used to package "Only the Good die Young", I was able to modify it slightly and use Google's documentation to fix whatever errors were being caused as I was having a bit of trouble compiling it due to Library name changes on Google's part which is not documented on their developer site. Thank goodness for StackOverFlow.com. Anyway... I need to recompile the latest 3.3.1 build on Git and upload the Sources for all of you to try and package your own APK.

I will mention right now that you will need Eclipse and you will also need to download the Android SDK. When you download the SDK, be sure to download (from the SDK Manager) the Zip File SDK, The downloader library, the Google Play Licensing Library(Formerly the Marketing License SDK), and the Sample Downloader Activity project. When the SDK Asks you to install to a directory (Against much advice that is mentioned on the web) install it to the default directory. Take note of that directory as we will be going to it often. As for the rest... You will have to wait for me to post the instructions. I may need to make some screenshots for you. I tried to make the process as simple as possible for everyone. If enough people can easily take care of compiling an APK, I may write up a cross-platform APK Packager via B4J.

Please be advised in Advance, this is not a final method of packagint the APK. This is just a preliminary test. Once I know my instructions and the small mods I made to the Android Source work for a good number of people, I will make some other changes so that you can have a more customizable app for android.

Give this one a shot: http://www.adventurestockpile.com/ags330.apk and see if that works. It is using the latest repo from 3.3.0 Master.

An OBB file is an Opaque Binary Blob file which can be whatever type of file you want it to be.

As a case in point, I have published a beta build of a standalone app that uses an OBB file for the game, and it works just as well as using the launcher app. The problem is that the engine itself is bugged. I've tried quite ferociously to track down the offending code, but debugging an issue which has never manifested on any device I've tested has proven to be practically impossible.

I remember you had mentioned that you had done this. If I am not mistaken, you can make a zip file and rename it with the .obb extension. My question is: Did you simply create the obb files, point the base directory to the default OBB directory and let it run? Or do you do the whole Salt Hash thing, downloader service packaging, etc...? The compiling the downloader service is what is giving most of the trouble.

If you're interested in the reported cases of crashing I'm referring to, send a message over to Chris at Himalaya Studios and inquire as to why Al Emmo hasn't been released to the Play Store yet. Because honestly both of us would have loved to seen that squared away months ago.

I remember one case that had mentioned this, maybe two. I didn't realize it was so widespread which really is a little concerning and I would love to know, just out of curiosity, if the same thing is happening on the iphone builds. Anyone have any reports on that?

That's the other issue. There is more than one issue to tackle. Obb packaging is one thing, getting it to be a streamlined process for a user to compile can be another if they don't have android development experience. And of course someone needs to really look at android code itself to make AGS work better.

I am working on this. The Android packaging and expansion programming is the issue. I am almost there. I'm just going slow because of real life stuff, but I am close.

If you give me till tomorrow I will make a new build for you.

Nice job!

I totally get CW. There's praise and then there is too much. But the point is we appreciate all the work that CW, CJ, JJS, and everyone else's name is not abbreviated

- What kind of system/engine do you want to get done?

Like AGS v3, only better.
A free, open-source engine and accompanying dev tools to make traditional (bitmap-based) 2D adventure games in any resolution from 320x200 and up, to run on a variety of platforms (targeting Windows, Mac OSX, Linux, iOS, Android), with enough power and flexibility to accommodate most of the ideas and ambitions found among AGS game developers.

- What kind of users is it aimed for?

-Current AGS users
-Amateur and hobbyist adventure game creators
-Semi-professionals (often working in teams)
-Small commercial indie developer studios

It should be accessible to newbies (e.g. easy to install, run and start working with), and not have too high a learning curve for people without much programming experience.

The players of the produced games would generally fall into two camps:

-Enthusiasts (those familiar with the engine, somewhat computer-savvy)
-General audience (for whom we may assume basic computer and computer game-literacy but no more)

- What kind of general features should it have?

Well, it should generally have the features and capabilities AGS currently has (though not necessarily offered in precisely the same way).

Possible exceptions:

DELETED - NOT THE PART I AGREE WITH.

Functional enhancements over the current AGS version (with possible implications for the architecture/library choices) would include:

-More flexible graphics rendering (e.g. resize, switch windowed/full-screen on the fly)
-Improved graphics rendering in general (performance, consistency, compatibility, hardware support)
-Better/more convenient multi-platform support, particularly for porting/deploying games on iOS/Android
-Improvements to the scripting language (or replace it with a different language) and script organization
-Improved compile speed, better efficiency in updating game projects
-A better file format for compiled games (per Calin and BigMc)
-Better support for patching games (without breaking savegame compatibility)
-Unicode support

Stuff like support for shaders, filters, subpixel rendering, etc. are also worth keeping in mind. Support for vector graphics and 2.5D games should be at most a secondary concern, IMO.

ALSO DELETED AS NOT NEEDED FOR MY POINT.

I agree with these answers. I think the question, as CW pointed out, should be that we realize what the final goal is. I think for that, it is important that we do have a vote on what we want out of AGS. As for the development libraries... As end users we may have a preference, but the developers need to decide on that. So the developers alone should vote on that. If it helps get us going in the right general direction, without reading through hundreds of posts, would this link help us at all: http://pub46.bravenet.com/vote/vote.php?usernum=3951325376  ? It is a survey of some basic functionality wanted from AGS and it is directed 90% at game developers/players and 10% towards development. The 10% of that comes with the intent that if someone could help, in which way and with what languages. Take a gander at it and see what you think. Maybe this can start to give us a clearer idea of where to head. If you think other questions should be on there, let me know and I will add it.

I agree with a do over in rewriting the engine. But it doesn't need to change what AGS is necessary. For instance, I still think the new  editor should work nearly identically to how AGS 3.3 would work. Maybe some small differences would enhance it of course.

My idea would be this:
*Rewrite the engine using SDL as it is far more portable and works on more OS. As much as I hate to say it, Allegro does not seem to be what AGS needs. SCUMMVM itself is a testimony of what SDL can do and its portability.
*Develop it having LLVM in mind(I think that is what the software is called. I am at work and cant look it up now). The reason why I would use this is so that the project can also be compiled into HTML5 and Javascript so that the engine can work in our browsers. The benefit to this would be that we can then use Phonegap to compile the engine to many portable systems such Windows Phone, iOS, Android, WebOS, Symbian and Blackberry.
*For scripting, I would go with Angelscript. It is the closest language that matches AGS' original SeeR language and what it is now. I would go with that primarily. It is also highly portable. Something I thought of with AGS was that it can also include a secondary language, which would be LUA, giving the user more options and more power. I had seen this with another engine and I can't remember which one it was.


The big change for me would be coding the editor. I would like to propose using B4J(http://www.basic4ppc.com). There are a few reasons why I propose this:

1) It has a basic.net style programming language. This makes the language very similar to C# allowing many developers to participate in this, including me.
2) It is portable to Mac, Linux and Windows and basically anything that can run Java without changing any code between OS.
3) It can use Java libraries and plugins.
4) The interface can be far more attractive with less effort than C#
5) It can easily be ported to Android using Basic4PPC.
6) With small effort and libraries, it can handle all the things the original editor could and more.

If you would like me to do a mock up using B4J, I will.

This is where I think we should go with AGS personally.

This is sad to hear CW. You worked so hard on this and stepped up when only few others did. You will always be immortalized in AGS history. Do not feel bad for leaving. We totally get it. But know this... We all REALLY appreciate what you have done for this community. If this is a permanent leave, so be it. But hopefully you will make a return one day when you are ready. Thanks for everything.

Are you trolling us, Joseph?

Lol, no. I just happened to notice this and was wondering if anyone knew anything about this. One good thing with this is that it can at least allow backwards compatibility on its player, which in turn allows AGS development to focus less on that and more on improvements.

It was announced today that they have been working on AGS port for SCUMMVM through the Google summer of code agenda they have. Interesting news. Source: Scummvm.org

I believe I was using R9b. I just installed R9(Original) and it compiled 3.3.1 Development build with no issues. Thanks for the feedback JJS.