Adore - A New Adventure Game Engine - Feature suggestions.

Started by Calin Leafshade, Mon 08/07/2013 09:55:41

Previous topic - Next topic

Calin Leafshade

Hello :)

As some of you may have seen, my last MAGS game was released using a different engine to AGS. I hope to continue its development further on and off over the next few months.

The engine aims to be a modern alternative to AGS which provides better support for high resolution games and which is hardware accelerated at all stages. The engine will use Lua scripting and use Love2D for its rendering and sound support. Because Adore will be coded in Lua at a very fundamental level all stages of the game will be overridable by the user either globally or for individual objects. Don't like the pathfinding? Feel free to write your own. Dislike the way Say commands are rendered? Just override it and the engine will continue as normal, calling Say commands just like the built in version.

Wait, it's coded in Lua? Won't that be really slow?

It's true that Lua is slower than raw c++ but AGS itself doesnt really do that much calculation under the hood. The most complex calculation is probably the pathfinder which usually has 2 or 3 nodes to consider and is over in a flash. The bottlenecks in AGS's speed are the CPU based rendering (dynamicsprites and so forth) which Adore does not have and it's unoptimized scripting language. My tests indicate that Lua is about an order of magnitude faster than AGS script in most cases. I've yet to find a situation in which AGS beats Lua for speed. (Cue monkey_05_06, stage left)

Why are you posting? Get on with it!

Adore will probably adhere to alot of AGS's conventions such as Characters, Rooms, Objects and so on but it does not have to. We have an opportunity here to reconsider the adventure game paradigm and create a tool that can facilitate that without being tied to an old code base. So I want to ask what *fundamental* things about AGS that you would change. How should objects and rooms work? How should the hierarchy be arranged? What annoys you about AGS? What things do you think AGS should be able to do that it does not?

Here are a few that I've already thought about and taken on board.

- The option for polygonal regions and walkable areas. High resolution games don't play well with bitmap masks and they are slower and use more memory.
- (optional) Sub pixel accuracy for all objects for smoother animations.
- A rethink of the "blocking" paradigm that AGS has. Multiple threads? Coroutines?
- Bone based animation built in.
- Pixel shaders.

Why are you posting on the AGS Forums about a competing engine? Are you mental?

I doubt Adore could replace AGS in a lot of ways. Firstly the barrier to entry is likely to be higher since AGS is very user friendly and Adore would be more modern and so require more programming expertise. Secondly I don't think Adore could cope with traditional, pixel art games as well as AGS can. AGS has that sierra/lucas arts feel down to a tee. With Adore I'm hoping to allow the creation of newer, more modern adventure games which is where AGS has traditionally struggled.

CaptainD

Calin - not really feature requests, but a couple of fundamental questions about this engine:
- would it have cross-platform support?
- would buying a licence be required to release commercial games built using Adore?
 

Sslaxx

Quote from: CaptainD on Mon 08/07/2013 10:06:44
- would it have cross-platform support?
When Calin says Lua, he means LOVE 2D. So it should (nominally) be cross-platform as LOVE 2D is.
Stuart "Sslaxx" Moore.

Calin Leafshade

It would be open sourced under the LGPL or something similar. A license that allows you to basically do what you like providing you give attribution where necessary and inform users of any changes. Having said that I would allow donations to be given and I think it would be fair to expect successful commercial projects to give me a kick back but no commercial license would exist.

In terms of cross platform support, it would be supported anywhere that Love2D and Lua are. Currently that is Windows, Linux, Mac and Android (preliminarily). There is also experimental HTML5 support for Love but I don't know how far along that is.

CaptainD

Thanks for the answers.  All the best with this project!
 

miguel

Calin, I understand that Adore will have a set of functions specific to game-making, right?

If so, what I find time consuming with AGS script is looking (example here) for a function like
Code: AGS
SetSkipSpeech
. Although it's obvious, I keep forgetting all this specific functions and it's not easy to find it in the manual.
I always get by using the forum "search" and that's okay, I end up reading and learning more than I was looking for. But I think that all code related to Speech (in this case, of course) should be extended from typing...Speech.

Can you give us a hint about your way of organizing functions? Please.

I'm very excited about your project, good luck with this.
Working on a RON game!!!!!

Crimson Wizard

Quote from: miguel on Mon 08/07/2013 10:57:59
If so, what I find time consuming with AGS script is looking (example here) for a function like
Code: AGS
SetSkipSpeech
. Although it's obvious, I keep forgetting all this specific functions and it's not easy to find it in the manual.
I always get by using the forum "search" and that's okay, I end up reading and learning more than I was looking for. But I think that all code related to Speech (in this case, of course) should be extended from typing...Speech.

Ahem...
http://www.adventuregamestudio.co.uk/forums/index.php?topic=47966.msg636459390#msg636459390
(roll)

Calin Leafshade

Quote from: miguel on Mon 08/07/2013 10:57:59
Can you give us a hint about your way of organizing functions? Please.

All Adore's stuff would be under a single namespace (adore). So it would look like this:

Code: lua

adore.wait(1.5) -- wait for 1.5 seconds. (Adore will not be frame based but time based)

adore.currentRoom.hotspots[1]:interact() 
adore.rooms[1].hotspots[1]:interact() -- all hotspots and stuff will be global and all rooms will be editable at runtime.
adore.rooms[1].hotspots.hDoor -- hotspots can be accessed by name as well as index

--This seems longwinded but remember than in lua we can do this:

function myFunc()
    local hs = adore.rooms["myRoom"].hotspots.hDoor -- shorten the name for this function so its quicker to type and quicker to access.
    hs:interact()
    hs.name = "unlocked door"
end
    


My current plan is to make Adore something between a tool like AGS and a framework like love2d or xna or something.

The "tool", let's call it the Editor, would allow you to enter your data much like the AGS editor does. But when you "compile" your game, all it does it spit out Lua code which is then run by Love. This means no compiling necessary and it should be very fast. Adore will maintain no "sprite cache" like AGS does but just use pngs from a folder which can be updated at will and the changes will be reflected next time you run the game.

so for instance, you might use the Editor to create a character called Grundislav. The Editor would then spit out something like this:

Code: lua

local c = adore.character.new()
c.name = "Grundislav"
c.animations =
    {
        walking = 
            {
                left = adore.animation.new("gfx/grundislavLeft.png", 25,50) -- loads a sprite sheet where each sprite in the sheet is 25x50 pixels. Adore will do the rest. No views to worry about.
                right = adore.animation.new("gfx/grundislavRight.png", 25,50) 
            }
    }
c.walkingSpeed = 5
-- and so on
return c


Then the engine can just pick up this code and run with it. No compilation, no headaches.

miguel

I didn't mean to be rude Crimson, you're work with AGS is something fantastic.
I hope to see AGS being more organized and I do read and keep up with what you come up, although because it's very technical I refrain myself from commenting.

This next paragraphs are my own opinion:
But since this is a different thread I want to express my opinion that I think that it's easier to get excited with a new engine (created from someone that also loves AGS) than with a "new" version of AGS. If you would be re-creating AGS from scratch, now that would be exciting. But I have the impression that the task you're handling is way to troublesome to accomplish and without major benefits regarding other modern engines.
When will AGS have support for different platforms and better graphic capabilities? How many versions before that? For what I've been reading you are trying to make CJ's code more readable and of course to improve it. That's fantastic, but I think that the latest AGS built is more than enough to make commercial retro-like adventure games. It is stable and has a huge community behind.
A AGS 4 would be what I'd dream of, without all that compatibility issues. A Software adapted to the modern days with the flexibility of AGS and its incredible supporters.
Calin is offering something like that right now and that's refreshing!

--------------------------------------------------------------------------------------------------------------------------------------------
Calin, this looks amazing! I'm giggling like a school girl although I'm a fat guy with a beard!
I don't really want to insult anybody's feeling but Adore sounds way too cool to miss it.
I'll be keeping my eyes on this one, Calin. Great stuff.

Working on a RON game!!!!!

Crimson Wizard

Quote from: miguel on Mon 08/07/2013 11:32:14
I didn't mean to be rude Crimson, you're work with AGS is something fantastic.
Err, I never thought you are rude, just noting we are fixing the language a little.

bicilotti

A licence compatible with AGS would be awesome!
Good luck with it!

Radiant

One thing that annoys me about AGS is unclear error messages. If the engine throws an exception and exits, you don't necessarily get a correct line number, and often critical data is missing (for example, instead of "a parameter is out of range" I would like to know which parameter).

And I don't like the way AGS handles certain commands at the end of the current script run (e.g. NewRoom / RunDialog / CallRoomScript calls). There is a very annoying error message that says that two of these are run in the same script cycle, which is apparently not allowed, but it won't tell you which ones or where they were called.

Calin Leafshade

re: errors and exceptions

The unclear error messages is just a matter of proper error trapping which will come with time. Lua does have exception handling OOTB but there are ways we can augment it.

Code: lua

try(function()
    local x = nil
    x.pie = "yum" -- Oops! attempt to index nil!
end,
function (err) -- catch function
    adore.display(err)
end)


I'll probably override the error system in Lua because, usually, the errors passed are just strings which are awkward to interpret. So i'll pass objects instead with more info.

re: concurrency of commands.

This is something I've already considered a little. I think AGS runs certain things after the function has finished because there are certain game state changes (room changes especially) which would cause problems.
Adore will not have this problem because the game state is far more static. The only things that will get loaded and unloaded are assets like room backgrounds. So yea, Adore will allow things like room changes and dialogs to happen in the middle of a function. Indeed, Adore has a coroutine systems that allows you to run your own, non-blocking function and then return to it later where you left of.

Babar

I think someone (Crimson?) did an interesting topic about the "Data Structure" of an adventure game as a sort of prelude to the discussion of adjusting AGS after it became open. Can't find it now :(.
But as far as comparing to AGS, perhaps having inventory items tieable to rooms as well (so you could have people dumping all their inventory in one room or something), and maybe having objects be tieable to multiple rooms? Or maybe just combine the two. :D
And addable and changeable (at runtime) properties for all such entities (characters, objects, hotspots, rooms, etc.), but I suppose that'll come about anyhow considering how you're saying everything will be overrideable or changeable LUA objects.
The ultimate Professional Amateur

Now, with his very own game: Alien Time Zone

Crimson Wizard

Quote from: Babar on Mon 08/07/2013 18:15:31
I think someone (Crimson?) did an interesting topic about the "Data Structure" of an adventure game as a sort of prelude to the discussion of adjusting AGS after it became open. Can't find it now :(.
But as far as comparing to AGS, perhaps having inventory items tieable to rooms as well (so you could have people dumping all their inventory in one room or something), and maybe having objects be tieable to multiple rooms? Or maybe just combine the two. :D

That was RickJ:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=45165.msg607273#msg607273
http://img28.imageshack.us/img28/9957/entityconcept.pdf

Grundislav

Quote from: Calin Leafshade on Mon 08/07/2013 11:17:40
so for instance, you might use the Editor to create a character called Grundislav.

I am not a character...I AM A HUUUUMAAAN!

Galen

Quote from: Grundislav on Mon 08/07/2013 18:26:29
I am not a character...I AM A HUUUUMAAAN!

Well... there's only one way to be sure, what does this say?:

Scavenger

Quote from: Calin Leafshade on Mon 08/07/2013 11:17:40
The "tool", let's call it the Editor, would allow you to enter your data much like the AGS editor does. But when you "compile" your game, all it does it spit out Lua code which is then run by Love. This means no compiling necessary and it should be very fast. Adore will maintain no "sprite cache" like AGS does but just use pngs from a folder which can be updated at will and the changes will be reflected next time you run the game.

Will there be some way to pack those folders into a resource file or something? While loading PNGs from folders is all well and good and easy, it does make a huge mess of the directory, looks horribly amateurish, and allows people to just pick up the resources and walk off with them, or easily edit them. And, well, I just don't like huge directories of resource files.

Will there be support for actual vector graphics? I expect now that we're talking about high resolution graphics, they may as well be /resolution independent/.  I would love to see vector graphics being given the same ease of use as any raster format. And vectors are much easier to generate, nowadays!

I am quite intrigued at this project. I am interested to see more.

Calin Leafshade

Quote from: Scavenger on Mon 08/07/2013 21:39:51
Will there be some way to pack those folders into a resource file or something? While loading PNGs from folders is all well and good and easy, it does make a huge mess of the directory, looks horribly amateurish, and allows people to just pick up the resources and walk off with them, or easily edit them. And, well, I just don't like huge directories of resource files.

The data files will be attached to the EXE file much like AGS when you do a "release" compile but most of the time it'll just load the files from the directory tree. Of course the assets can still be extracted with relative ease. I'm not going to bother with encryption or anything.

Quote from: Scavenger on Mon 08/07/2013 21:39:51
Will there be support for actual vector graphics? I expect now that we're talking about high resolution graphics, they may as well be /resolution independent/.  I would love to see vector graphics being given the same ease of use as any raster format. And vectors are much easier to generate, nowadays!

There is support to draw arbitrary polygons and, with pixel shaders, you could implement some kind of vector rendering but i've no plans to implement vector graphics, no. The closest thing to vectors I plan to implement is tweened, bone based animation.

Sslaxx

Quote from: Calin Leafshade on Mon 08/07/2013 21:47:41
Quote from: Scavenger on Mon 08/07/2013 21:39:51
Will there be some way to pack those folders into a resource file or something? While loading PNGs from folders is all well and good and easy, it does make a huge mess of the directory, looks horribly amateurish, and allows people to just pick up the resources and walk off with them, or easily edit them. And, well, I just don't like huge directories of resource files.

The data files will be attached to the EXE file much like AGS when you do a "release" compile but most of the time it'll just load the files from the directory tree. Of course the assets can still be extracted with relative ease. I'm not going to bother with encryption or anything.
Planning on using .love files attached to the EXE then?
Stuart "Sslaxx" Moore.

SMF spam blocked by CleanTalk