BASS Stub - A Lightweight BASS template

[Ghost]

Lightweight BASS Template v2.0


Download LW_BASS v2.0

The LW BASS is a small, clutter-free template that implements the "Beneath A Steel Sky" two-button interface: Left-click is walk/interact, right-click is examine.

Based on the many helpful suggestions I've rewritten the thing from scratch, with readability and simplicity in mind. The template requires no setup at all and keeps
things as simple as possible.

Feature List:
* Two buttons, two interactions. LMB is "interact", RMB is "examine"
* BASS-style inventory (GUI pops up when top of screen is touched)
* Nicer fonts with full umlaut/foreign character support
* Custom inventory property "propInstantUse" allows inventory items to be used "on their own" (blow whiste, eat sandwich) instead of requiring a "use inv on" action

v2 changes:
* full code rewrite, incorporating most suggestions to improve readability
* removed tween module
* full comments, and license
* as suggested, only "interact" is used, instead of additional "talk" for characters
* moved all mouse handling to on_mouse_click
* support for "instant use" of inventory items
* inv popup position is now a makro
* added nicer unhandled_event template
* fleshed-out test room
* removed Revenant

[CaptainD]

Nice!

[Phemar]

Awesome. I was just thinking of releasing something like this, after all the recent topics in the technical forums. I can see a lot of newbies benefiting from an updated ALARCOST template

Edit: Would it not be easier to just release this as a standalone module? It would make integration easier for people with existing projects.

[Ghost]

Edit: Would it not be easier to just release this as a standalone module? It would make integration easier for people with existing projects.

Probably, yes, my reason to make this an actual template was to offer some additional extras- fonts and tween, in this case. But a module can easily be done if there's enough interest

[Crimson Wizard]

I would remove the things it does not really rely on if I was adding this to AGS distributive, just to keep things clean.
In my opinion, since the concept of the template is to emulate certain game style, it should do only that (+ have a example room(s) maybe, like 9-verb/Verb Coin templates do if it really needs to demonstrate its features).

[awakening]

Thanks a bunch for this Ghost - no really.
It's really helpful.  I've edited a few things to suit my needs but it's all really easy to understand and it's laid out nicely, so cheers for that.
I'll credit you in my game for the time you'll have saved me with coding, if that's alright?

[Ghost]

Credit is always nice but not really required. I took much of the code from an existing template myself, and as far as I am concerned templates like this really are more of a "working base".
Will polish it a bit though, and eventually it may become a full-fledged "stub". Then I want a penny each time someone says its name 

[Phemar]

I still don't understand why everyone keeps scripting different actions for Talking and Interacting when using 2 click interfaces if the actions never overlap.

I really think Talk To should be abandoned in favor of Interact for simplicity's sake.

[Crimson Wizard]

I still don't understand why everyone keeps scripting different actions for Talking and Interacting when using 2 click interfaces if the actions never overlap.

I really think Talk To should be abandoned in favor of Interact for simplicity's sake.

I agree completely. If the UI style assumes that there's only one type of activity with any kind of object possible, then there should be only one interaction type.

[Ghost]

It's just a habit for me. When I look at a function and see a nice friendly XYZ_Talk, then I know I wanted to script some talk there.
It is, of course, a subjective decision and settling for one interaction type would remove the need to distinguish between objects/hotspots and characters.

Way easy enough to change, though.

[Billbis]

Well, IMO it easily allow to it dynamically change cursor aspect between "Talk To" mouse graphics and "Use" mouse graphics. There is other way to do that, but setting eModeTalkTo when mouse is on character is an easy way to do it.
Not saying that we should do it that way, but that how I understand people "keeps scripting different actions for Talking and Interacting when using 2 click interfaces if the actions never overlap".

[Phemar]

Well, IMO it easily allow to it dynamically change cursor aspect between "Talk To" mouse graphics and "Use" mouse graphics. There is other way to do that, but setting eModeTalkTo when mouse is on character is an easy way to do it.
Not saying that we should do it that way, but that how I understand people "keeps scripting different actions for Talking and Interacting when using 2 click interfaces if the actions never overlap".

This is why we have Mouse.UseModeGraphic!

[Ghost]

Thanks for the feedback/discussion, guys. It helps to refine this in v1.2 

- Using "Interact" for everything is a sensible request, so yes, I'll do that.
- I like the idea of changing the mouse cursor to display an interaction. AFAIK this is not in the original BASS but it would give nice visual feedback. Thoughts?
- The original BASS changed to an "exit" signs when over places where the character would leave the room. Useful, in my opinion, will do that.
- I got PMs asking for a better "showcase room". Indeed.

Has anyone tried this out and really HATED the alternative fonts? That's something I'm curious about.

I really want to make this worthwile, so keep it coming!

[Crimson Wizard]

What caught my eye.

1. The UI assumes there's only 1 cursor mode all the time and never changes. Instead of setting cursor images for all built-in cursors, you could set it only for one (I'd vote for mode 6: Pointer).
Also, disable all modes except chosen one in game_start:

Code: ags

mouse.DisableMode(eModeInteract);
mouse.DisableMode(eModeLook);
... etc ...
mouse.Mode = eModePointer;

In GlobalScript:
1. You do this in repeatedly_execute:

Code: ags

if (gInventory.Visible)
{
    player.StopMoving();

Is it what BASS did? I don't like it, because that will be very annoying during action sequences. Though, I guess, user can remove this line.

2. Maybe make constant/macros instead of hardcoding "12" pixel edge which triggers inventory right in the function body?

In custom module:
4. The huge "if (!IsGamePaused())" condition block that covers all function body. This is a matter of personal code style, though I would suggest to make it instead

Code: ags

if (IsGamePaused())
    return;

This will reduce nesting level making code more clear to user.

5. "if (mouse.Mode == eModeUseinv) " condition will never be true, because you never set mouse.Mode. Instead, you can just test "player.ActiveInventory == null", or "!= null". This refers to both "if (button == eMouseLeft)" and "else if (button == eMouseRight)" blocks.
6. This, and merging al location types will produce the code:

Code: ags

if (GetLocationType(mouse.x, mouse.y) != eLocationNone) 
{
    if (player.ActiveInventory == null)
        ProcessClick(mouse.x, mouse.y, eModeInteract);
    else
        ProcessClick(mouse.x, mouse.y, eModeUseInv);
}

7. You are using "inventory[game.inv_activated]". IMHO that's bad. Although that may work, "game.inv_activated" is an obsolete variable, and also old-style code (also it is not very obvious how engine sets it).
I'd suggest to just use InventoryItem.GetAtScreenXY, it might be little slower, but it is a click handler, therefore does not matter really. Also you call GetLocationName anyway, and with GetAtScreenXY you'll get InventoryItem pointer with Name and everything. You won't need to compare names too (comparing strings is slowest operation of all, except only getting object under mouse), you will simply compare pointers:

Code: ags

InventoryItem *item = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
if (player.ActiveInventory != item)
    item.RunInteraction(eModeUseinv);

8. I don't think it is good to add "data == theGUI.ID" condition when you check that player clicks on gui. There may be other guis too, and the item should probably be deselected anyway.

9. I think it is simplier to test "if (button == eMouseRightInv)" in "on_mouse_click" to make player LookAt inventory item, rather than in "on_event". This way you won't need to test which mouse button is down, nor which Control is clicked.


//--------------------------------
EDIT:
I suggest to nullify info label at the start of mouse_click. Otherwise, the label text will stay on screen while player talks / does blocking actions.

[Ghost]

Crimson, thanks for the extensive feedback. I think it is obvious that you're "deeper" into the actual coding stuff than I am I learned a good bit from your list, and will see to add these tricks to my toolbox. I see how it'll make the code more readable, too, many thanks for that.

But:

5. "if (mouse.Mode == eModeUseinv) " condition will never be true, because you never set mouse.Mode

I don't get that. The manual states that an interact click on an inventory item will be translated into an useinv action- basically, as soon as your cursor becomes the selected item you *are* in eModeUseInv. So I don't see why this test will fail? (And if it would fail, the template wouldn't work the way I want, but it... seems to do just that  )

[Crimson Wizard]

I don't get that. The manual states that an interact click on an inventory item will be translated into an useinv action- basically, as soon as your cursor becomes the selected item you *are* in eModeUseInv. So I don't see why this test will fail? (And if it would fail, the template wouldn't work the way I want, but it... seems to do just that  )

Yes, I was wrong... something I forgot about, that engine automatically sets mode to eModeUseInv when you set ActiveInventory.

Other than that, I think I am mistaken about "game.inv_activated", it is not obsolete, and probably can be used, just needs little different code to remove excessive commands.

Code: ags

if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv) == 1 && mouse.Mode == eModeUseinv) 
{
   if (player.ActiveInventory.Name != Game.GetLocationName(mouse.x, mouse.y))
      inventory[game.inv_activated].RunInteraction(eModeUseinv);
}
else if (inventory[game.inv_activated].IsInteractionAvailable(eModeInteract) == 1) 
   inventory[game.inv_activated].RunInteraction(eModeInteract);
else 
   player.ActiveInventory = inventory[game.inv_activated];

There is no need to call Game.GetLocationName here, because you already know that it is "game.inv_activated" item id, therefore you can use inventory[game.inv_activated].Name; but further, you don't really need to compare Names, you can just compare pointers:

Code: ags

if (player.ActiveInventory != inventory[game.inv_activated])
      inventory[game.inv_activated].RunInteraction(eModeUseinv);

Another thing that worries me is whether this combination of conditions is proper.
1st condition will succeed if both mode is "use inv" and clicked item has "use inv" handler.
2nd condition will succeed if either mode is not "use inv" or clicked item has no "use inv" handler and item has "interact" handler.
This means that 2nd condition will succeed too if player used an item on another item that does not have "use inv" handler.
This also means that 3rd condition (else) will succeed if player used an item on another item that does not have any event handlers - in which case he will select the latter.

This is, of course, a choice of design. I don't remember how BASS handled this (if you follow BASS UI style). But I may suggest do it this way instead:

Code: ags

// if player has active item in hand, use it no matter what (we may get "unhandled event" here)
if (mouse.Mode == eModeUseinv)
{
   if (player.ActiveInventory.Name != Game.GetLocationName(mouse.x, mouse.y))
      inventory[game.inv_activated].RunInteraction(eModeUseinv);
}

[Kitai]

Well, IMO it easily allow to it dynamically change cursor aspect between "Talk To" mouse graphics and "Use" mouse graphics. There is other way to do that, but setting eModeTalkTo when mouse is on character is an easy way to do it.
Not saying that we should do it that way, but that how I understand people "keeps scripting different actions for Talking and Interacting when using 2 click interfaces if the actions never overlap".

This is why we have Mouse.UseModeGraphic!

I think Billbis meant to refer to the IsInteractionAvailable function: it's an easy way to check which cursor mode/aspect you should set depending on what the mouse is currently on. You might have character instances that are only associated with interact events and objects instances that are only associated with talk-to events: GetLocationType will do it wrong in that case.

- I like the idea of changing the mouse cursor to display an interaction. AFAIK this is not in the original BASS but it would give nice visual feedback. Thoughts?

Well, if you use only one mode, you can no longer use IsInteractionAvailable to determine which cursor to use. So you're left with GetLocationType.

To deal with "talkative" objects and "non-talkative" characters, you can use custom properties, but it might go against simplicity for a template.

We already had a discussion with Billbis on how to dynamically change cursor's aspect on this thread of the French forums.

[Billbis]

Well, what I think is that there is many different ways of coding a 2 click interface in AGS, and that I am far to new into AGSscript to determine the best one (if any).
But I also think that there is a ENORMOUS need for 2 clicks templates, and that the defalut template packaged with AGS should be one of them.
So thanks a lot Ghost for this template.

[Ghost]

This also means that 3rd condition (else) will succeed if player used an item on another item that does not have any event handlers - in which case he will select the latter.

That would trigger unhandled_event, though. If the user makes use of it, so there *is* potential for the code failing...
Your suggestion is lean and nicer to read anyway, so I see no reason not to use it.

I'll rewrite that thing. It's nice to throw away some old coding habits, and if the end result is useful, it's a win/win situation and they are nice because everyone wins 

[frenzykitty]

Thank you very much.

Nice and clean and functional <3

[Ryan Timothy B]

I'm a little confused.

There is no need to call Game.GetLocationName here, because you already know that it is "game.inv_activated" item id, therefore you can use inventory[game.inv_activated].Name; but further, you don't really need to compare Names, you can just compare pointers:

And then you have this:

Code: ags

// if player has active item in hand, use it no matter what (we may get "unhandled event" here)
if (mouse.Mode == eModeUseinv)
{
   if (player.ActiveInventory.Name != Game.GetLocationName(mouse.x, mouse.y))
      inventory[game.inv_activated].RunInteraction(eModeUseinv);
}

You're assuming that the object, hotspot, character or inventory item you're hovering over won't ever have identical names. I don't understand your logic here.

This would be better:

Code: ags

if (mouse.Mode == eModeUseinv)
{
  InventoryItem *item = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
  if (item != null && player.ActiveInventory != item) inventory[game.inv_activated].RunInteraction(eModeUseinv);
  else if (GetLocationType(mouse.x,mouse.y) != eLocationNothing) ProcessClick(mouse.x, mouse.y, eModeUseinv);
}

Also, I very much dislike you doing this!:

Code: ags

if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv) == 1)

It's a boolean and you're checking if it's 1. I know AGS's booleans are actually integers and this code will always work. But you shouldn't make this a practice. It should either be the two with no exceptions:

Code: ags

if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv))
// OR
if (inventory[game.inv_activated].IsInteractionAvailable(eModeUseinv) == true)

If AGS ever gets a variable overhaul turning booleans into actual booleans, then this code could throw an error (if it's strict). Plus it's a VERY misleading condition statement that will only confuse people trying to understand the code.

[Crimson Wizard]

I'm a little confused.
<...>
You're assuming that the object, hotspot, character or inventory item you're hovering over won't ever have identical names. I don't understand your logic here.

I am sorry for confusion, Ryan, for the last code example I just mindlessly copied existing code, because the purpose of that example was to show different condition (mouse.Mode == eModeUseinv). I did not even paid attention to what is in the block.
Also, I was speaking about section of code under "button = eMouseLeftInv". There can't be any characters there.
If you read my posts further, you will see that I made two suggestions on how to optimize item comparisons.

Although your variant combines two of them . First you take item from screen coordinates and then still use inventory[game.inv_activated]. If you use "game.inv_activated" there's no need to check item under mouse.

[Ryan Timothy B]

My apologies. It's been ages since I've last used the game.inv_activated that I honestly couldn't remember what it was. I had also forgotten that AGS had a onClick handler for eMouseLeftInv. So it should've just been this:

Code: ags

if (mouse.Mode == eModeUseinv)
{
  // I don't know how this module was scripted, so as a fail-safe, I put: player.ActiveInventory != null
  if (player.ActiveInventory != null && game.inv_activated != player.ActiveInventory.ID) inventory[game.inv_activated].RunInteraction(mouse.Mode);
}

Edit: Also, I've never played BASS, if you're not going completely strict, the other option is this:

Code: ags

if (mouse.Mode == eModeUseinv)
{
  if (player.ActiveInventory != null && game.inv_activated == player.ActiveInventory.ID) 
  {
    player.ActiveInventory == null;  // deselect inventory item if you click the same item on itself
    mouse.Mode = eModePointer;
  }
  else inventory[game.inv_activated].RunInteraction(mouse.Mode);
}

[Crimson Wizard]

My apologies. It's been ages since I've last used the game.inv_activated that I honestly couldn't remember what it was.

I never knew about it until Monsieur OUXX asked something related on forums.

There are a lot of "game" members, some of which have quite non-obvious meaning, and allow to change different aspects of the engine, that cannot be affected otherwise.

[cat]

- The original BASS changed to an "exit" signs when over places where the character would leave the room. Useful, in my opinion, will do that.

I did something like that for SheepQuest, using custom properties to define the direction. I could clean up the code and donate it for your template if you want (that is - after OROW of course, this week I have different priorities )

[Ghost]

Cat, that's a great offer, please do. I *have* done pretty much the same already, using regions and custom props to allow for different "direction" cursors... I'd sure like to see how our code compares!

[Ghost]

*Bump* Version 2.0 is up; see first post.

[dactylopus]

This is very useful!  Thanks for developing this template!

[frenzykitty]

I don't know if I'm being a total idiot - but if I try and change the resolution of my game, things start acting very strangely?

For example if I make a new room after changing the resolution, it still makes it in the original resolution of the template? Am I being really stupid

[Ghost]

Changing resolution works fine for me, but the test room, having a 320x240 image, may look odd because the image won't fill the screen (backgrounds aren't resized).
Does the new room actually tell you it's still 320x240? Have you imported an image that works with your resolution?

[salak]

I'm not sure if this is the right place to ask this but, does this template support saving and loading? If not, can I add that function manually or is there a plugin or something to do that? I hope the question is not sheer ignorance but this template works really perfect for me.

[Crimson Wizard]

I'm not sure if this is the right place to ask this but, does this template support saving and loading? If not, can I add that function manually or is there a plugin or something to do that? I hope the question is not sheer ignorance but this template works really perfect for me.

Although this is not a direct answer to your question, I think it is worth to clarify - that the AGS template does not make any restrictions to your game, all it does is providing a starting script/resources. You may remove/rewrite any parts of it, even most of it if you like. Similarly you can add anything.

[Ghost]

The template has no custom-made save/load fucntions, but you can easily use AGS script to add that- read up the commands
RestoreGameDialog(), RestoreGameSlot() and SaveGameDialog(), SaveGameSlot()
in the AGS manual to learn how loading/saving works.

Then, you can just create a GUI with buttons that call your load/save functions. (The template, for example, has a "quit" button in the slide-in inventory GUI- you could also place load/save buttons there!)

For future reference, a template is a collection of scripts (and assets). You can ALWAYS alter/expand a template because once you create a new game from it, you can see all the code (and assets). Plugins are different since they are compiled by the author and can't be (easily) modified.

Hope this gets you started!

__
[edit]

Crimson was faster! But I was more elaborate! Mwuhaha!

[Denzil Quixode]

This is great, thank you!

Here is my contribution - a special BASS version of Character.Say()!

Code: AGS

function Say_BASS_Style(this Character*, String message)
{
  String bass_style = "";
  int space_idx = message.IndexOf(" ");
  bool prev = false;
  while (space_idx != -1)
  {
    String part = message.Substring(0, space_idx + 1);
    message = message.Substring(space_idx + 1, message.Length - (space_idx + 1));
    if (prev)
    {
      prev = false;
    }
    else if (Random(1) == 0)
    {
      part = part.UpperCase();
      prev = true;
    }
    bass_style = bass_style.Append(part);
    space_idx = message.IndexOf(" ");
  }
  if (!prev && Random(3) == 1) message = message.UpperCase();
  bass_style = bass_style.Append(message);
  return this.Say(bass_style);
}

(     )

[Ghost]

Here is my contribution - a special BASS version of Character.Say()!

wItcHCrAfT !1!11

[Anian]

Very nice.

[Monsieur OUXX]

Reporting a small issue with AGS 3.3.0 RC1:
When you click the "quit button" then the standard "Quit/Play" built-in dialog window appears but the text is shifted down 5 pixels lower or so. Its upper part is on the button, but its lower part pours out.
I haven't seen that with any other 3.3.0 RC1 game, so I guess it's caused by the template.

===========

@Ghost : I have migrated your template to 32-bits. PLEASE DOWNLOAD THAT VERSION AND DO ALL YOUR FURTHER CHANGES BASED ON IT.

[Ghost]

When you click the "quit button" then the standard "Quit/Play" built-in dialog window appears but the text is shifted down 5 pixels lower or so. Its upper part is on the button, but its lower part pours out.
I haven't seen that with any other 3.3.0 RC1 game, so I guess it's caused by the template.

Yes, the text shift is caused by the template replacing the default fonts with ttfs that support the full range of characters. I am aware of this, but so far nobody really complained about it, and these days you see very few of the build-in windows being used anyway. I'll document it in an updated version- the solution is to simply reset the fonts.

@Ghost : I have migrated your template to 32-bits. PLEASE DOWNLOAD THAT VERSION AND DO ALL YOUR FURTHER CHANGES BASED ON IT.

I appreciate your work, but out of interest: I understand that 16bit is the hard default and 32bit isn't used that often and several people avoid it to keep their game smaller. Isn't it simpler to upgrade the (very few) sprites yourself when you want 32bit? I am genuinely curious.

[Monsieur OUXX]

There was another thread where it was discussed that 32-bits should now be the standard so I did that, but there seems to have been some misunderstanding, maybe on my side. So hold on.

[Ghost]

No problem at all; as I said I really appreciate the effort you went through.

[cat]

The version included in the latest alpha needs to be updated, i.e. processClick.

[Ghost]

The version included in the latest alpha needs to be updated, i.e. processClick.

What exactly has changed that requires an update? I haven't used the alpha at all, yet (and don't intend to, since an alpha is a work in progress with things bound to change more). IS the alpha so popular and so widely in use?

[cat]

Global functions moved to Room class
GetRoomProperty ---> Room.GetProperty
ProcessClick -> Room.ProcessClick

I like to use the alpha because the developers need feedback and bug reports now, not when the official version is released. I don't know if it is popular, though.
Since the template is shipped with AGS, at least for the final release it has to be working with the engine/editor.

For now, it is not a big issue as I can quickly edit the few occurrences myself. I just wanted to give you a heads-up that this will be required in the future and is not overlooked.

[Ghost]

I like to use the alpha because the developers need feedback and bug reports now, not when the official version is released. I don't know if it is popular, though.
Since the template is shipped with AGS, at least for the final release it has to be working with the engine/editor.

Yes, those are both valid points, and the changes are important and easy to alter. Thanks- I'll update ASAP!

[cat]

But be aware, that older AGS versions will not work with those changes. I'm afraid that there will have to be two different versions of the module

[Crimson Wizard]

But be aware, that older AGS versions will not work with those changes. I'm afraid that there will have to be two different versions of the module

There is a solution, AGS supports "#ifver" command.
I suggest looking into Abstauber's 9-verb template to see how it can be done.

Examples:

Code: ags

// If your version of AGS is >=3.2, the new, object oriented audio system will be used.
#ifver 3.2
    #define USE_OBJECT_ORIENTED_AUDIO
#endif

Code: ags

#ifnver 3.4
    ProcessClick(x, y, Mouse.Mode);
#endif
#ifver 3.4
    Room.ProcessClick(x, y, Mouse.Mode);
#endif

[Ghost]

There is a solution, AGS supports "#ifver" command.

Yes, that's what I had in mind. Should be fun revisiting that ole babe of a template

[Crimson Wizard]

We have this template included with AGS distribution, but it does not compiled with 3.4.0.
Ghost, do you have plans on upgrading this template to 3.4.0?
If not, am I allowed to do so?

We have a repository for included template sources: https://github.com/adventuregamestudio/ags-template-source
I could upload your template source there as well.

[Ghost]

Crimson, if you can easily update BASS, by all means do so, I would be much oblieged. I'm in some pretty hard times at the moment and have dropped out of the AGS loop almost completely. No idea if, when, and how I could continue.

[AnalogGuy]

Crimson, if you can easily update BASS, by all means do so, I would be much oblieged. I'm in some pretty hard times at the moment and have dropped out of the AGS loop almost completely. No idea if, when, and how I could continue.

Sorry for this stupid offtopic. I want to contact Ghost but somehow he can't get the private messages or what?

[Kumpel]

I implemented BASS successfully in 3.4.0.7 and 3.4.0.10. Afaik the only compatibility problem I encountered has been some lines with processclick which had to be changed to room.processclick. Or am I wrong there?

[Crimson Wizard]

I implemented BASS successfully in 3.4.0.7 and 3.4.0.10. Afaik the only compatibility problem I encountered has been some lines with processclick which had to be changed to room.processclick. Or am I wrong there?

With most recent 3.4.0 version you do not even need to do that, because there is "Script compatibility level" switch in general settings that enables all the old functions you may need.

[Weilard]

First of all, thank you for this template Ghost. Would be rude from my side asking to add some actions and events in demo-scene?

My offer is add some events in this template. To best understanding what exactly people can create with AGS and this template in one time. It's for a newbies, of course. Experinced coder and developer no need this. Would be nice to fill room (or rooms) by objects, opportunity to combine these objects, where characters can speak & etc. Not a game, of course, but the demo of two rooms, for example.

I can describe why I'm asking for this. Some people, unfortunately, have a different skills, but sometimes (very often) in list of this skills is not including skill of coding. I spent lot of years to learning how I can drawing normally, writing & etc, but this 17 years in game development industry isn't bring me understanding of code. In case where I see working examples of code I can repeat it, analizing and create something like. But in case I have only list of functions of engine/template, I cant understand how this work. I can offer the barter, for example. Somebody deed for this template additional code. Code of events, situations and etc, I'm cooking well smelling graphics.

AGS site have after this nice example of "game" (more nice than we have now), I have code, which I can understand and can repeat in myself game. Sorry in case if I write wrong words in wrong place.