Related to "the future of AGS" -- but only for OCD and nerds

Started by Monsieur OUXX, Tue 17/01/2012 17:53:13

Previous topic - Next topic

Monsieur OUXX

This is a side discussion. (and when I say "side", I mean "as far as Pluto")
Most will have no idea what it's about, and others will wonder why one would even bother with such things.

But here it is : Since we mentionned it, how about we actually DO write down the specifications for all "exchanges" in point-n-click software? You could call this a "point n click standard" or a "point n click protocol" or whatever you like.

Some have seen that the idea was raised in another thread.
Such specifications would include :
- abstract, universal terms to designate anything that is involved in point-n-click (what's an "inventory", what's a "character", etc.)
- a way to organize all this

Long things short: Something like web standards, but instead for Point n click games.

I'll try to make it a little more concrete: Do you ever ask yourselves silly questions like the ones below?
- "in a point n click, should we expect the main character to have one inventory? Several? Possibly one inventory per character? etc." (think "Maniac Mansion")
- "should a character wearing a custom skin still be the same character (with custom, temporary graphical properties) or should we use the trick of switching characters?" (think "Nelly Cootalot wearing a mustache". Is it still Nelly?)
- "is an object in an inventory virtually the same thing as the object on the floor before it's picked up, but just drawn differently when displayed in the inventory?" (think "Kyrandia's droppable objects")
- In an inventory, should countable objects (such as coins) be managed natively?
- etc.


If these questions should ever be asked, it's now! Because we are at an important time of AGS' history. These specs could be the underlying work to the implementation of AGS 4.x or 5.x (see the proposed roadmap in thread "the future of AGS")These specs could answer questions like: what should be hard-coded? What should be dynamic? What would be the limits?
More importantly, they would then help maintaining migration tools through versions of AGS (even if a feature wasn't implemented in version X, version Y can still import the game files because the feature was already described in them -- yet let empty).
Another thing is that it would enable interoperability (things could be exported as XML).



There are no limits.
I hope I'm being clear in my explanations.


PS: Another concrete example that pops to mind would be the AGS awards: Imagine if there was a "standard" for point n click characters' graphical resources. Then it would make the programmer's life easier, he'd only have to focus on handling the characters, their moves, and what they're saying, without having to worry about loops, sprites, views, etc. If someone decided to code a feature to allow clients to upload their own skins onto the server, the organizer of the awards wouldn't have to do all the job of debugging all the skins one by one, validate them, etc. Then again that's just a random example.




 

Wyz

Wow, Monsieur OUXX, really you've described a few things that were on my head the past few days. Boring story (or not since this is an OCD and nerd only zone): a few years ago I created a specification language for myself with as goal to abstract all sort of games to find an universal models for games in general. This project has since been superseded by other projects, all not very interesting but Point and Clicks was one of the game genres I've looked at. It was actually not that hard to do it for point & clicks since it is really a well defined genre and AGS and I'm sure all other tools to create such games have structures that resemble any generalisation closely.

Still, it might be useful to make a specification for AGS, and I was already planning to do this. Maybe we can bundle our efforts. I don't mind writing it in other specification languages then my weird own one. I've worked with Z and UML in the past, but UML might be a bit too visual, and Z too formal, heck whatever works. :D

Migration tools will be really helpful to the community, also making resources that will remain useful for different editor versions and engines. Let me hear what your ideas are.

And about the awards, yes that would have made my life a lot easier, especially since things like views are pretty much static.
Life is like an adventure without the pixel hunts.

Ali

Quote from: Monsieur OUXX on Tue 17/01/2012 17:53:13
- "should a character wearing a custom skin still be the same character (with custom, temporary graphical properties) or should we use the trick of switching characters?" (think "Nelly Cootalot wearing a mustache". Is it still Nelly?)
- "is an object in an inventory virtually the same thing as the object on the floor before it's picked up, but just drawn differently when displayed in the inventory?" (think "Kyrandia's droppable objects")

I can't answer the philosophical question, or engage in the techie discussions, but I can confirm that Nelly with a moustache is still Nelly.

I think the second one is quite interesting. The idea of objects having continuity between the real world and the inventory makes a lot of sense (The Elder Scrolls games work like that I think..?)

It also makes me wonder about creating a game where players can sneak into the inventories of other characters (in the form of minds or memories?) and rearrange things. Getting more than a bit off topic, so I will stop.

Monsieur OUXX

#3
Wyz's post is a relief. I thought people would throw rocks at me for this.
Wyz, you pinpointed my concern here: The scope. The goal wouldn't be to describe a universal language for any type of games (that would be an unlimited scope) but instead only for point n click games (but letting enough doors open for people who'd like to extend their gameplays).

I'd like the opinion of someone involved in the technical development of the AGS editor. Would that help or would that be an obstacle? (then again, here we're only talking about future versions of AGS, not the current one!)

Does anyone have recommendations to make regarding which language should be used to formalize such specs? I'll always have a preference for UML, but there aren't so many free UML editors around (well there are plenty, but most of them omit most of actual UML!)


PS: Ali, how did you add the mustache on Nelly? By changing views, or by drawing it over manually at each frame?
 

Snarky

I don't really see the value of a general specification or protocol for adventure game data, because adventure games aren't identical; they work differently and have different needs. So to all of your concrete examples, I think the answer is "it depends".

(I could see a use for it if we were creating a new adventure game engine to run networked games, like the AGS Awards ceremony, or to run in a browser, where there'd be a lot of data passed back and forth and you'd want a nice format to represent all of it. But that's not really what AGS is for.)

What I do think is worth considering is whether the built-in datastructures and abstractions in AGS are optimal (allowing for easy creation of a variety of game mechanics), or whether they should be simplified, extended or reorganized somehow.

Someone (ProgZmax?) has talked about how it would be convenient to allow objects to move between rooms, allowing them to be used in situations where you need a character or a GUI currently. I would further propose to use the principle of inheritance, so that an object extends hotspot, and character extends object. And yes, I don't think we need a separate data type for inventory objects.

The built-in cursor system is confusing, and I think it would simplify things to drop hard-coded cursors completely and make them all user-defined (with the empty game/Sierra game templates creating the appropriate number of defaults).

I also think the creation process for characters and (particularly) animated objects is confusing, and involves a lot of duplication of work. In my opinion the concept of "views" should be reconsidered, possibly distinguishing between animation sequences and character views (and allowing more flexibility in which views to provide; including possibly composing views by combining separate sprites/animation sequences), and probably offering some way to auto-generate views/animation sequences from a series of sprites (e.g. in the character/object creation dialogs).

GUIs, overlays, dynamic sprites, rawdraw methods... Ideally these would just be layers that you could draw on and compose freely, above and below elements in your game scene. (But this might not be efficient implementation-wise, so some compromise between functionality and performance may be called for.)

It would also be nice if mixed resolutions (e.g. backgrounds, characters etc. running in 320x240, but fonts running in whatever resolution the game is scaled to, as faked in the Blackwell games) and sub-pixel positioning were built into the engine, but that's not really an issue of the game logic, more just the display logic.

Monsieur OUXX

#5
@Snarky: Your answer is confusing.

You start by stating that we don't need general specifications.

Yet, you then describe exactly what we're actually talking about. These are not technical specifications, this is not about data storage, etc.
This is indeed about optimal abstractions.

You've described a few concrete applications that fits perfectly:
- "Shoud objects belong to a room, or be cross-rooms entities?"
- "Shouldn't cursors' representations be detached from the actions associated with them? Shouldn't actions be user-defined?"
- "Shouldn't 'animation sequences' be a different concept from 'views'?"
This is abstract, but clearly has an impact on the final implementation.
That's the sort of things we'd like to define.

But then you switch again to technical implementations (inheritance, etc.). I have nothing against that, of course.


 

Monsieur OUXX

One of my concerns is that I don't like the word "Object".
It refers to so many things:
- It's a term used in Object-Oriented Programming, which would have a specific meaning when dealing with the programming of the Editor
- It could refer to that abstract "Object" underlying hotspots, inventory objects, etc. (described in Snarky's post)
- It refers both to something on the ground and something inside the inventory, etc.

That's one of the things that confused me when I started learning AGS. I was confusing objects and inventory items.
 

Snarky

Quote from: Monsieur OUXX on Wed 18/01/2012 11:01:17
@Snarky: Your answer is confusing.

You start by stating that we don't need general specifications.

Yet, you then describe exactly what we're actually talking about. These are not technical specifications, this is not about data storage, etc.
This is indeed about optimal abstractions.

...

But then you switch again to technical implementations (inheritance, etc.). I have nothing against that, of course.

Strange, I saw the bit about inheritance as being closest to what you were talking about, since it goes directly to the UML object model. I think it does have an effect on the abstraction, since it would imply that a character is an object, and an object/character is a hotspot.

I think where I differ is that I see these questions mainly as pragmatic decisions about what changes to AGS are worth making in order to make it easier to use, not some attempt to define what the "right" data model is, or to say "this is what a character is, always, in every game". So to take your list of examples, I would pose them differently:

- Is the current way inventories work in AGS fine (making things as easy as possible for the typical-case user while giving those who want something non-standard convenient configuration/work-around options)? Or can we think of a different way to do it that has a better balance of being easy to learn and use, flexible, and not excessively difficult to program/maintain?
- Is there a need for better support for character variations? If so, what kind of AGS feature can we think of that would offer an improvement?
- The distinction between inventory items and room objects is confusing to newbies, arguably leads to extra work in order to implement common scenarios, and makes Kyrandia-style inventory management hard/impossible to implement. Is there some compelling reason why they have to be different things?
- [I wouldn't ask the question about inventory item counts at all, since I don't see an issue that needs to be addressed there.]

Maybe if you could explain to me why, for example, we need to decide whether characters should have no/one/multiple inventories, instead of just leaving that choice up to each game creator, I'd see the point of trying to make a universal adventure game specification.

Quote from: Monsieur OUXX on Wed 18/01/2012 11:16:50
One of my concerns is that I don't like the word "Object".

I object to that!

Nah, you're right. It's really confusing. Blame the OO guys for taking a perfectly good term for physical things and using it for abstract units of computer code.

Assuming we combine inventory items and objects, what would you want to call that? An item? Entity? Thing? Prop? Article? Element? Thingy?

Wyz

Yes this is not about creating a specification language rather using one. You can actually convert any generalisation to any language given that the language has a few properties, and it can be proven to be consistent. But there I'm already wandering off topic. :D

Abstraction is a trip into the meta world where any entity stand for an (almost) infinite group of things all described by their trades. I also dislike the word object, I call them entities instead.

I'll make a glossary for other terms I might use in the future (my definition):
Atoms: the smallest units in the specification, they are indivisible.
Value: a certain atom or a composition of other values. (there is no way of doing this without recursion ;))
Set: a list of unique unordered values
Universe: all possible values within the specification
Domain: a selection of possible values
Type: a named domain. (it might in cases be useful not to bother describing what is in the set)
Variable: a named 'space' that can hold a value
Typed: variable same but this time it has a type as domain.
Structure: a recipe for an entity, built from variables. Note that a structure itself is also a type.
Entity: a value with as domain one of the structures.

Well I sort have to agree with the UML editors out there, I had a nice one once but it wasn't free. I guess I'll just use ad hoc specification in the meanwhile.

On to the interesting parts:
After having the types of entities defined I feel the need to give them roles. A thing is something that can be lodged in the background, be something that moves around in the room, or something that is carried around in the pocket of a character. Currently they are defined as: hotspots, objects and inventory items, but what strikes me is the fact that the interactions with this thing remains very similar. I think it is safe to assume they are the same entity but have a different role. The role of the thing entity does change parts of the interactivity: As a hotspot they are unable to move, as an object they have a different appearance then when they are contained in the inventory. It might be possible that in different rooms the appearance of a thing is different, or according to where in the room the thing is placed. Also when using the 'look' verb on things that are contained in the inventory might result in different dialogue, since when it is in your pocket you can inspect it closer. Yet it remains the same thing, a pencil will still be a pencil when you pick it up from the perspective of the user (maybe not for the computer developer but that is the wrong perspective).
There is something I like to add to that: A thing might  next to a role also have a state (which also can have a different appearance). This is something that always gives me major headaches when I build games. Let me begin with a simple example:
You have 'a piece of wire' and you bend it so it becomes a 'lock pick'. Stops 'a piece of wire' existing and starts 'lock pick' existing, or do we still see it as the same thing?
I like to think the latter, but here comes a more difficult one:

We have 'a Y shaped stick' and 'a piece of rubber' and we make 'a catapult'. So now we merge two objects into a new one. How the hell to we do that? I think most of the time we will make 'a piece of rubber' and 'a Y shaped stick' stop existing and let the catapult start existing. Ok that is a solution but completely inconsistent with how I handle the previous problem.

There arises a new thing I like to discuss. Let's say we want to make sure our game doesn't have deadlocks, there are beautiful algorithms to do that but we must have to notion that combining the two things give rise of a new thing. With what we have now no system could ever explain how a player could ever get a catapult. But if we do allow the notion to be made somewhere, we actually could. :D

Oh wow there is still lots of stuff I'd like to talk about but this post is already becoming very long, so I'll come back to it later.

edit: Oh shoot, sorry Snarky my timing was most unfortunate
Life is like an adventure without the pixel hunts.

Monsieur OUXX

#9
Wyz: I'm a bit repelled by the first half of your post -- now you're going too far into abstraction: It's a very cold, mathematical approach! And you're using new words to redefine concepts that already exist in most formalization languages (and in extenso in programming languages). We're talking point and click here.

On the other hand you're asking all the correct questions in the second part of your post, about a "thing".

Snarky: On your question about inventories:
- I took the example of Maniac Mansion, because you can switch between 3 characters, and each of them has an inventory.
- You could also imagine several inventories per character (for example, the inventory could be reset to a predefined inventory after a cutscene (when the storyline moves on), or in debug mode -- that would simplify debugging) -- but that's far-fetched.


 

Snarky

Yeah, you can certainly imagine situations where it's useful to have multiple inventories. For example, you could have one inventory for physical items, and another for spells, or clues, or conversation topics, or a diary, or a to-do list. Many games have done that. Resonance has three separate inventories (items, short-term memories and long-term memories - though I'm not sure whether the latter is actually implemented as an inventory) for each of four different playable characters!

Inventories are really just a special case of a particular kind of character state that is useful for many adventure games. I don't think we can (or should) define how it "should" be done, just think of what features AGS can offer that are as useful/usable as possible for as many users as possible.

What might be worth thinking about, OTOH, would be breaking the hard-coded link between inventories as a data structure and inventory windows as an interface element, so that you could lay out arbitrary data the way you can lay out inventories, and also so you could lay out inventories with more flexibility. This would require making the GUI API much more powerful, though (something approaching a simple windowing/widget toolkit).

So the actionable questions, IMO, are:

Is there a way to make the AGS inventory system simpler and quicker to use? (Including replacing it by more generic per-character state.)
Is there a need for better support for multiple inventories per character, or are the existing workarounds acceptable?
If there is a need for multiple inventory support, is there a way to add it that doesn't complicate things for regular single-inventory games?
Should the elements/methods for displaying the inventory be hardcoded, offered as a template/module, or left to the user?

Similarly, to Wyz's scenario, I'd say: let's not worry too much about it. Sometimes it might be most convenient to represent manipulating one item into another item by editing the existing data structure (i.e. updating the item name, graphic, and interaction responses); other times it will be easier to just remove it and replace it by a different inventory item. I'd argue that we should just give the game makers the necessary APIs, and let them do it whichever way comes more naturally to them (though it's probably cleaner and less error-prone to use separate items for each state, so that might be the recommended way).




Personally, I would ideally (in some dream-AGS) want to see all the special adventure game logic moved into discrete script modules, instead of being hardcoded into the engine. So the same way you can load up a LucasArts/Sierra/Verb-coin template now, you could switch out the default "single-inventory" module with one to handle multiple inventories per character. Or you could change how conversations work, or what a walkcycle is, or create new event types.

RickJ

Just s a couple of thoughts:

Game Specification Language
If this concept was expanded to included a directory structure containing all the resources, sprites, backgrounds, sounds, etc, their  import properties/instructions and the scripts that comprise the game, the AGS editor then be able to read/write this file.  The file could then be input to stand-alone compilers to port any given game to different game engine back-ends. 

I believe this is similar to what Clavaron did with XAGE.  It's also a way to work around the license incompatibilities between AGS and SummVM;  there could simply be an AGS-ScummVM compiler and shazamo AGS games are able to run on ScummVM.  Conceivably this could be done with older AGS games even without the source code?

With regard to format,  the obvious first choice to come to mind is XML.  Fell free to opine as to it's merits and/or alternatives.


Game Entity
I like the above discussions about "things' and "game entities" and agree with much of it.  I believe all Game Entities or Entities ought to have some common characteristics:

Resources
Entities ought to be able to "own" resources such as sprites, sounds, music, etc.  Two or more entities can own the same resources.  If an entity is exported it's resources are also exported (this would also apply to it's other constituents as well).  If an entity is imported all of it's constituents are also imported.  From a user perspective it may look like the game contains multiple copies of the same resource but this does not have to be the case.  The game files themselves would contain only one copy and multiple references as is the case now.

Views
Animation is perhaps  a better word? Entities could have 0 or more views or animations consisting of an arbitrary number of loops.  Different views could be set active by the script code. If a character entered the water the swimming view could be activated.  Perhaps multiple views could be simultaneously set active to change clothes or hair-do for example.  This suggests some sort of organizational hierarchy (i.e. folders, groups, or something).  The concept of view should be general enough to include the playing sounds, music, and other resources synchronized to animation or without animation at all.   In light of this perhaps a word like "Composition" may be a better choice? 

Collections
The way to handle inventory is perhaps to just let inventory items be Entities and then allow Entities to contain collections of other entities.  So if a character has a gun, then the gun can have bullets.  If a character has chewed bubble gum and a paper clip in the inventory and then makes a key with those items he will end up with a key in his inventory but no bubble gum and paper clip.  Why?  Because the key now has the gum and paper clip.  I suppose a generalized solution would allow entities to have multiple collections.   You could then of course, as suggested earlier, have GUI components for displaying collections.

Scripts
Entities ought to have the ability to contain scripts.  It could be something like modules are now in AGS and could work in exactly the same way.  The would have the ability to respond to and/or capture events.

Events
Otherwise know as player interactions.  Currently interactions are only defined in for rooms.  Why should not other entities also have the ability to respond to such events/interactions.  In addition it would be nice if there were the ability to handle user defined events where one script could post an event (possibly with data value) which would trigger interaction functions in other scripts.

Dialogs
Dialogs are held between one or more entities.  Participants can be explicitly identified within the dialog or identified when the dialog is initiated, sort of like passing parameters.   Dialogs are owned by entities.  If a room owns the dialog it can only be initiated when the participants are in that room.  If a character owns a dialog then the dialog can be initiated in any room where the participants are present.  The owning entity does not necessarily have to be a participant.

Dialogs usually result in the player learning something or the game changing state (or both).   Perhaps the latter consequence should be enshrined in a standard way.  What if entities were able to have a collection of "Facts"?  Each fact could be a string or unique id# and have a count and %confidence level.  There could be a dialog command called reveal (reveal "fact string" [%confidence]).  If confidence level not supplied then revealing entity's default confidence level is used.  The entity(s) to whom the fact is revealed adds the fact to it's knowledge base it it doesn't exist.  The count is then incremented and then used to calculated a weighted average of the confidence level.  The game programmer can then use these properties however he wishes.  "Conversation" is perhaps a better word than dialog?



Monsieur OUXX

#12
Quote from: RickJ on Wed 18/01/2012 23:33:51
Views
Animation is perhaps  a better word? Entities could have 0 or more views or animations consisting of an arbitrary number of loops.  The concept of view should be general enough to include the playing sounds, music, and other resources synchronized to animation or without animation at all.   In light of this perhaps a word like "Composition" may be a better choice?  

Quote from: RickJ on Wed 18/01/2012 23:33:51
I also think the creation process for characters and (particularly) animated objects is confusing, and involves a lot of duplication of work. In my opinion the concept of "views" should be reconsidered, possibly distinguishing between animation sequences and character views (and allowing more flexibility in which views to provide; including possibly composing views by combining separate sprites/animation sequences), and probably offering some way to auto-generate views/animation sequences from a series of sprites (e.g. in the character/object creation dialogs).

These comments are both essential.

the way I see it, is that animations in general should be very close to Flash's "Movie Clips" concepts :
- An animation should be:
  - a succession of frames
  - each frame can have a different "length" (possibly defined using key frames)
  - There should be a mechanism to customize the loops (repeat once, repeat always, backwards, intertweened, etc.). the way I see it, the "loop" is attached to the animation but not synonymous to it
  - Maybe we should incorporate the tweens natively here
  - An animation can be composed of any number of other "embedded" animations => This is the very delicate part IMO: Should this all be real-time, or pre-rendered? Should there be a flag to let AGS know?
  - I think we could decide to put the sounds and other resources in the animation!

- A view should just be a "label" put on any arbitrary animation, to give it the required status to be used to render a character, or an inventory item, or even any game entity, in a given state. That way, you could see all views in a separate folder, but they're just animations, really.

=======

On a different note: Shouldn't an AGS game be defined as an abstract entity, possibly defined inside another game? (in programming terms: Like an inner class, defined in another class). That would virtually allow to define and run a game inside another game.

That would natively allow mini-games in AGS games. One could import mini-games from other AGS developers into their own games (think "Bernard playing Maniac Mansion in Day of the Tentacle" or "playing arcade games in Toonstruck")

Technical solutions are off-topic, but just so that you see it's possible:
- AGS could run another instance of AGS, then render it onto a Surface that would then be stretched down and drawn into the current AGS game.
- Or you could force AGS scripters to write their game object as inherited from a global "Game" object, so that it's easily imported into another script just by copying the sources (a bit the way applets work)
- etc.



 

Ryan Timothy B

QuoteOr you could force AGS scripters to write their game object as inherited from a global "Game" object, so that it's easily imported into another script just by copying the sources (a bit the way applets work)
Do you mean someone could create a Game object in an AGS application, containing things like: Views, Loops, Frames, Sprites, Dialogs, GUI's, Rooms etc etc (whatever these existing objects get turned into).

So if I were to delete that Game object, all the inner items are deleted. So a game object could simply be a game within the game. Like a super advanced module that contains everything the module would need?

Also exporting or importing would also contain all these items. That would make things super easy for team projects. Especially for things like a mini-game like you mentioned.

Because if that's what you meant, I have a chill running down my neck. ;)

Monsieur OUXX

Quote from: Ryan Timothy on Thu 19/01/2012 16:49:36
Do you mean someone could create a Game object in an AGS application

I'm not saying someone *could*, and I'm not suggesting a way to implement it.
I'm just saying we should anticipate it, at least formally, because it's a possible use case.
 

Wyz

Quote from: Monsieur OUXX on Wed 18/01/2012 15:18:57
Wyz: I'm a bit repelled by the first half of your post
Yeah, don't sweat it, that was the OCD part of me. It is not really all that useful so just skip it. :P

Quote from: Snarky on Wed 18/01/2012 16:41:20
Similarly, to Wyz's scenario, I'd say: let's not worry too much about it.
It is not so much worrying as it is philosophizing. I love to do that, very much.
I kind of share you view to stuff things in modules rather then hardcode stuff. But yeah, it should still remain a tool for building point & clicks so I guess some of it will remain.

Quote from: RickJ on Wed 18/01/2012 23:33:51
Just s a couple of thoughts:
Very nice, that made me think. The generalization of game specification would be really awesome, not easy to specify but definitely worth the while. I like your break down of the entities. The resources are like the atoms the game is build from, if feels really natural to me.
I also like how you defined script as part of the resources, would really well with functional programming languages actually. Events? yes please! This is something I miss the most right now actually. I like for modules to be able to raise events when they have data ready. That would make it more natural for both the plugin developer and user.

Also you might have just come with a solution for the 'merging of things' issue I described. You simply add it as a collection of things to a container thing and have conditionals for what resource is should show. That is beautiful. :D

Quote from: Monsieur OUXX on Thu 19/01/2012 10:48:45
On a different note: Shouldn't an AGS game be defined as an abstract entity, possibly defined inside another game? (in programming terms: Like an inner class, defined in another class). That would virtually allow to define and run a game inside another game.
That would definitely be useful like mini games. If you'd combine that with the kind of game specification format RickJ described you could import games in your own like modules. Very nice!
Well in my original specification there would be only one game entity and it will remain until the game has been won, but this option would be more flexible.
Life is like an adventure without the pixel hunts.

RickJ

Wyz, thanks for the compliment.  Here are some more thoughts.

Game-in-game
The game itself could be an entity and so could have a collection of other games.

Entity (more)
First of all just to be clear.  Entity is pretty much the same as an OO Object/Class or Thing.  Entity is being used for the purpose of this discussion so as to eliminate confusion between language elements, AGS room objects, and Wyz's Things.  

There would be different types of entities of course.  There could be restrictions and requirements for each type.  On such restriction, for example, could be what types of entity collections a particular entity type could have.

As TimothyRyan was saying if an entity is exported then all of it's resources would go with it  Importing an entity then would include all of the needed resources.  There would also be a possibility of importing entities at runtime.  For example, if someone wanted to have an episodic game where episodes are created and released over a period of time.   One could easily imagine an in-game catalog and download system for such a game.  

Game Specification Language
Quote
If this concept was expanded to included a directory structure containing all the resources, sprites, backgrounds, sounds, etc, their  import properties/instructions and the scripts that comprise the game, the AGS editor then be able to read/write this file.  The file could then be input to stand-alone compilers to port any given game to different game engine back-ends.  
Please let me know what you think about having a genar;lized/defined editor output like this.  It think this may be a way to work/cooperate with ScummVM without all the licensing hoopla.  

[edit]
Related thread on ScummVM forum
http://forums.scummvm.org/viewtopic.php?p=71107#71107

Ryan Timothy B

#17
Quote from: Monsieur OUXX on Fri 20/01/2012 14:05:32
Quote from: Ryan Timothy on Thu 19/01/2012 16:49:36
Do you mean someone could create a Game object in an AGS application

I'm not saying someone *could*, and I'm not suggesting a way to implement it.
I'm just saying we should anticipate it, at least formally, because it's a possible use case.

Well of course. That's why I said could. ;)

Anyway, even the possibility of a character class/object? containing these sprites or animation views as well. It would be nice if characters had the option to have their own script as well. They should, shouldn't they? It only makes sense to me. Organization and such.

I even think removing the header script would be justifiable. Having the public keyword on classes is all we would really need. GlobalScript.DoFunction();

Would we really need a Global Script? GUI's shouldn't share the global script. Character's shouldn't. What other need other than repeatedly execute and always, plus on event and other functions. Basically all we would need is a Game script.

Alan v.Drake

Since you've linked that thread, I think it would be dutyful to quote what sev wrote today:

Quote
As of the AGS development, anyone is welcome to come with an engine ported to our framework and according to our standards. Current AGS source code is a mess and has to be refactored heavily. This will lead to two incompatible codebases and if AGS community will continue developing original AGS engine, it will turn into an endless race for the compatibility.

Thus it was told that a feasible approach would be to port 2.x branxh which will definitely not be developed anymore. So far the sources weren't published and such discussions are pointless.

And of course, once the engine is ported to ScummVM and if the community decide to develop the engine on top of our codebase, we're fine with that, however in this case development will be ruled by ScummVM's 6 months release cycle.

I personally hope that AGS 2.x sources will be published because there is number of developers interested in tackling it, and even there is an idea to turn it into a GSoC project if we be accepted this year.


Eugene




Monsieur OUXX

Quote from: Ryan Timothy on Fri 20/01/2012 21:17:22
It would be nice if characters had the option to have their own script as well.

Can you decribe a use case? I can't visualize it. Maybe if there were some events associated to characters, like, let's say "has started speaking".

Quote from: Ryan Timothy on Fri 20/01/2012 21:17:22
Would we really need a Global Script?(...) Basically all we would need is a Game script.

I won't say yes or no, it's just vocabulary, isn't it?

Quote from: Ryan Timothy on Fri 20/01/2012 21:17:22
I even think removing the header script would be justifiable

Why not. What is the opinion of scripters here? Doesn't it make a module more readable if you put all the comments, function description, parameters decription, etc. in the header?
 

SMF spam blocked by CleanTalk