Scripting with Dagon

I was thinking the “Scripting with Dagon” section of the wiki would help me, but I can’t seem to find what I need over there, so I was hoping somebody more knowledgeable than I, could help get me started.

I’ve been looking at the Asylum teaser scripts and the Serena scripts, and they seem to be slightly different. Is everything in the teaser still applicable in the latest version? I don’t really yet understand how all the various scripts fit together to make the game work.

If I can understand the basics of how everything fits together, I’m sure I’ll be able to find my way from there. At least, for a while anyway. :slight_smile:

For example, if I jjust wanted two rooms that had two nodes each and various closeups, what scripts would I need for that?

Thanks in advance. :slight_smile:

I’ve been working on assets, so it’s been a while since I’ve done any scripting. The last version I used was the Asylum demo with Dagon version The version of Dagon used for Serena was, so it’s slightly more advanced. Agustin stated that there were slight changes in the coding, but I don’t recall what they were.

Check out the wiki -->
There’s a basic explanation (though a bit outdated, most of it still holds true for the Asylum demo), which might help you to figure out how things fit together and the organization of the files. —>

One big change was planned. Dagon currently compiles the 6 cube sides of the node in TGA format into a single TEX file. We’re moving (or were?) to using 6 individual JPG or PNG images for each node. I’m not sure what we’ll be using for Dagonity, but for the old converter and an explanation of how to use it is here. -->
You can at least see your nodes that way. I’ve saved my cube sides as PNGs plus alphas and depth maps, as well as TGAs, just to be safe. Agustin maybe will clarify. :slight_smile:

Yeah, the wiki sucks. Sorry about that. As soon as I can, I’ll start documenting all the changes and new behavior of the engine. Dagonity has introduced compelling new features and even a solid new philosophy in scripting (the addition of “Things”).

But the overall changes aren’t that drastic. In short, it will be best if you stick to the version used for Serena. However, you might still want to investigate the code of the Asylum teaser for the creation of multiple rooms (Serena has only one). That didn’t change between both versions.

In particular, you may want to have a look at the Infirmary.lua (in the Asylum Teaser) which is a fairly complex room with slides and stuff, yet still less complex than Serena.

As for textures, for now I’d encourage everybody to use PNGs and avoid TEX. It’s preferable to include the alpha channel in the PNG itself, but we’re planning to support separate depth maps and alphas. We’re even supporting normal maps now for groovy lighting effects :slight_smile:

Thanks guys. :slight_smile:

I’m having trouble understanding what all the scripts are for, especially as things have changed from the teaser to Serena. The teaser has the Asylum.lua script, but there’s no Serena.lua script. Has this scrupt become the main.lua script now? Would all the different rooms I want to create go in the topology.lua script?

Being a newbie, and a non-programmer, I just really need some basic overview of what goes where, what is doing what, and how all these scripts are working together. Of course, I undersand if that would take up too much time. Maybe I should just wait for Dagonity? That seems to be the future. :slight_smile:

Ah yes, that’s correct: the newer version launches main.lua first. From then on you can do “require module(.lua)” to load other files or “room name(.lua)” to automatically create a room and load the associated file.

Dagonity will make things much simpler as it will include a graphical interface to create your game, but I’m afraid it will be a while until that is ready. Still, we can reply to any questions you have here :slight_smile:

Thanks. I appreciate it. I’m afraid I might have way too many questions though. :wink:

I think I’m making some general progress. Yay! :smiley:

Quick question: what is the difference between an Overlay and a Slide? Under what circumstances would I use each?

Thanks. :slight_smile:

Hi Dan, overlays are used for things like the intro and the readme in the asylum demo. They play on top of the node or slide. Scripts that used overlays used to be in the modules folder. Slides are stills/close-ups and have a fixed camera. Also, images that go within spots are called “patches.” Patches, slides, and overlay components that are image files all get lumped into the Images sub-folder within Resources.

I’ve not moved Adamantus to the Serena version of Dagon, but Agustin has assured me that what I’ve done already on the Asylum demo version of the engine (or most of it) will work in Dagonity.

I just took a look at the Serena files and the organization when compared to the Asylum demo is different. The placement of assets in the Resources folder is the same, but the Modules and Rooms folders are combined into one folder called Scripts. My guess is that this is mostly due to there being only one Room in Serena.

The old order was that the configuration file took you to the game.lua (Asylum.lua) and then that file served multiple functions. It required the modules, took care of the audio, cursors, resizing, effects, hotkeys, preloaded the first Room, started the intro playing, and switched you to the first Room. In this version config.lua and main.lua must be initiated by the Dagon.exe file itself. Most of the “stuff” that was in the modules files and in the Asylum.lua has been distributed among several smaller files. Topography.lua is the file that most closely resembles an old Room file. On line 52, main.lua switches you to the Node “Cabin” (specifically it goes to cabin_n7, which is the first node added in the topology.lua file) and then it starts the intro played on line 54. I expected the switch to go to a Room file — Cabin.lua. My guess is that the Spots sub-folder in Scripts was necessary to keep the single room file (topology.lua) from becoming monsterously long. I liked having the room files separated from the modules and I think that it must be possible to have a Rooms sub-folder within Scripts.

Until Dagonity is released, I think that I’ll continue to concentrate on creating assets. :stuck_out_tongue:

Thanks Imari. That helps. :smiley:

I wonder what is the reason for keeping Dagon as a standalone engine if there’s also going to be Dagonity? Won’t they effectivly be the same?

Oh, and Adamantus looks great. :slight_smile:

Imari, yes I agree it seems to make more logical sense to me to have separate room scripts that contain all the various definitions for that room. Is that possible using the Serena version? It’s quite hard to know what to do with Serena because there’s only one room. I think maybe I’m better off using the 0.6.5 binary and scripting like the Asylum teaser for now as that is easier to follow and understand. I think that way I can get something done relatively quickly. :slight_smile:

One of the reasons that I did not make the transition to the Serena version is because one would have to go through the code and take out all of the bits dealing with “MOOD” and find all of the bits where one of the moods listed in the constants.lua file is a parameter of a function. Both the English files (written text at the bottom of the screen) and the feedback (spoken audio clips) are dependant on mood, for instance. Also the touchable items’ hotspots are also mood dependant. The gamelogic.lua file (in spite of the mood stuff in it) looks like a neat way to deal with variable states.

The configuration file one could leave as is for now. Also the files for audio, controls, cursors, and enginesetup, hold information formerly held in the game.lua file. They’d just need tweaking to be usable for your specific game. Ditto for the intro.lua file. The letters.lua file defines the assets for a particular Overlay. I believe, the sound effects found in muffled.lua and the information found in the files in the Spots folder would go in the individual room files in a multi-roomed game.

I don’t know how to handle the lack of a Rooms folder. Perhaps Agustin could explain why topology.lua (which looks like a room file) is not called as a room “topology,” but as the node “Cabin.”

In other words, why not:

room 'topology' switch(topology)

I’m not sure. I’m finding it difficult to follow the Serena scripts. :slight_smile: I like the Asylum teaser. It seems much simpler. I feel I can do what I need with that version, so I think it’s best I stick to it. I want to get a little game out within a few weeks, so as long as it works, and does what I want, I don’t think it really matters. :slight_smile:

I still would like to understand the Serena version better though, if Agustin could kindly explain a little about the room situation. :wink:

As far as I can tell Serena doesn’t have anything different in terms of how scripts work, but has a different way of doing things than the teaser. Like separating spot locations and some variables to different lua files for better organization.

If you want a new room you can just create a testroom.lua file as you need with nodes and spots (you can use same style Serena spots were created or just create them in the file, it’s your choice), load it in the Serena room (in topology.lua file with -room ‘testroom’-) and switch to that room with -switch ‘testroom’-.

I haven’t tried doing this myself, though. So it’s possible there might be problems, but from the look of things I think that’s the way it works.

For example I’m already keeping all global variables in a different file called GlobalVariables.lua and calling them in all rooms as necessary, because I just think that’s an easier way to organize them in case I need to test a situation in game that involves doing some specific thing with variables.

There is no hard-set way to organize lua files, so you can do anything any way you like. Please correct me if I’m wrong Agustin, I don’t want to misguide anyone.

Yes, something that was improved for Serena was the organization of files. This is perhaps the most drastic change since the Asylum teaser. Because it’s merely a matter of copying files around, it’s fairly simple to to adapt the folder structure to either version. My advice would be to stick to Asylum Teaser and eventually move the files to Dagonity (it will be slightly more different than Serena).

We will document every aspect of the new version, as it’s far more focused and cleaner than what we had until Serena. That said, the scripting code itself remains mostly the same.

Be warned that the Serena code is NOT meant to be used as a tutorial. It’s very specific to the game, whereas the Asylum Teaser is more friendly towards general projects. The “preferred” version to organize rooms is precisely what we did in the teaser.

civanT is correct, of course: Dagon doesn’t try to impose a folder structure on you. In fact, the upcoming Dagonity version has a setting that allows you to come up with vastly different structures. For now, it’s OK to create a name.lua file, place it in the Rooms folder, and load it with the “room name” sentence :slight_smile:

Thanks guys. :smiley:

One little thing. I copied the Dagon.exe binary from Github, and replaced the one in the teaser. It seems to run a lot smoother now. But the right click is different. It no longer brings up the journal. Instead, it frees up the cursor and stops the view being moveable. How can I control the right click? The “right click” code in the Asylum.lua script still refers to the journal, eve though it’s not doing that anymore.

This code allows you to control what happens with the right mouse button:

register(MOUSE_RIGHT_BUTTON, function() journal:toggle() end)

Should work in the GitHub version!

That’s the code I was referring to, but it no longer toggles the journal. It frees the cursor from being in the middle of the screen, like it does in Serena, but it doesn’t allow you to look around.

Hhmmm… that’s something I’d have to test. Maybe it’s best if you stick to the engine from Asylum Teaser then. Maybe the GitHub version is breaking something :frowning:

Thanks Agustin. :slight_smile: