The Discover Albia Forum is Now Closed

Thank you for a short but wonderful experience! Due to time constraints and other factors, the forum is now archived and is no longer open to new registrations nor posts. All existing content can be seen for the time being. Thanks again, and I wish everyone all the best!

Please note that the forum may be permanently removed in the future, so please save any content sooner rather than later. No advance notice of this action will occur.

The Progress of Project AMP

Discover what other players are working on.
User avatar
Amaikokonut
Busy Bee
Posts: 89
Joined: Wed Jun 08, 2016 10:25 am
Country: USA
Currently Playing: C3/DS
Favorite Game: C2
Favorite Species: Norn

The Progress of Project AMP

Postby Amaikokonut » Fri Dec 23, 2016 5:58 pm

Continued from the discussion in this thread to avoiding derailing it more than I already have.

Summary: AMP or Adaptive Metaroom Placement is a method of writing metaroom CAOS that eliminates the need to collision-check a metaroom against every other metaroom ever created. Instead of having to stay totally up to date on the placement of all those other rooms, developers can use this method to instead have their metaroom simply search a world for an empty spot to inject itself into.

Obviously though, this method comes with some challenges. Quoting a few from the previous thread:
...even though they play nicely with themselves and other adaptively placed metarooms, they risk clashing with the coordinates of most current/older statically placed metarooms if the static metaroom is injected later.
It's not just a matter of changing the coordinates of where the room is injected. You would also have to update the coordinates for every single plant/animal/foreground agent/possibly CA links/pretty much anything that is in the room.
Adaptively placed metarooms haven't really been stress-tested afaik. It's possible that there are some complications involved that just haven't surfaced yet. When I was working on the ant tunnels I was able to generate over 50 small-ish (about workshop size) empty rooms without any issue, but I didn't try injecting more, injecting lots of different shapes/sizes, or packing them all full of various agents, so it's possible there's limitations to them (I feel fairly confident the concept is at least stable enough for most normal playstyles, but again, testing will really tell).
Regardless, I can't seem to stop myself continuing to explore this concept anyway.

While I personally am the most interested in using the AMP method for future metarooms (and making it as easy as possible for others to use the method as well), Gio has shown interest in converting the existing C3/DS metarooms to AMP-standards:
Gio wrote:The painstaking, tedious process of converting the official C3/DS metarooms should be our first step, as it covers a lot of the bases and questions you've posed so far. The converted rooms can serve as a stability test (can it handle the default game?) which then serves as our baseline for further testing (agent injecting, new worlds with static rooms, turtles).
So here goes:

Here is the pastebin for an example AMP-enabled room - this one injects a simple clone of the DS Hub (map/rooms only, no agents). It's not thoroughly bugtested and needs a remove script but it is (or should be) functional. (Also I promise it's way more readable once copy-pasted into the CAOS tool)

Here is the python script I used to assisted in the tedious process of converting the selected hub room-placement code (from !map.cos in the DS bootstrap). It's probably really bad because I don't know python and basically just googled "how to do x" for every other line; it's very limited because I wrote it to parse only that particular format and it would need to be adapted for any other use, but it might get someone more knowledgeable than I started at least.

Ultimately I think I want to have a script that will merge an output cosfile from the Map Editor with the AMP script, so after mapping out the room, developers would only have to export the !Addon.cos-file, run the conversion script on that file, and immediately have an injectable cosfile of their AMP-enabled room with as little effort as possible. But I'm going to take a break and work on some other things for a while to avoid burning out.

In the meantime, let me know what happens if you try this out, and let me know if you think of any other problems this project might face that need overcoming. And of course, feel free to ask any questions. :proud:

User avatar
Amaikokonut
Busy Bee
Posts: 89
Joined: Wed Jun 08, 2016 10:25 am
Country: USA
Currently Playing: C3/DS
Favorite Game: C2
Favorite Species: Norn

Re: The Progress of Project AMP

Postby Amaikokonut » Fri Dec 23, 2016 6:23 pm

Here are some (large) map images so you can see the effects of this test file:
[+] When injected in an undocked DS, the room is placed in the top left next to the splash-screen room.
Image

[+] When injected in a docked DS world, the room is placed more in the middle, under the ettin desert and to the right of the aquarium map.
Image

[+] And just for fun, if you comment out the check-if-exists-before-injection code and inject the room several times until the world is full, the map looks like this
Image
I wouldn't recommend doing this for anything released for general use without first modifying the code to at least ensure each instance of the metaroom has a unique name (even if it's just "hub_1" "hub_2" etc) so they can still be tracked for proper agent-placement and the like. But hey, the technology is there if you want to make your metaroom injectable multiple times! Thankfully it's not hard to expand the world map.

User avatar
Gio
Everyday Egg
Posts: 15
Joined: Wed Nov 16, 2016 5:13 pm
Currently Playing: DS
Favorite Game: C2
Favorite Species: Ettin

Re: The Progress of Project AMP

Postby Gio » Sun Jan 01, 2017 4:19 pm

And 'ere we go!

*A wild Gio appears, tools in hand!*

Thanks a bunch, Amai. I've begun analyzing your example alongside the CAOS reference materials. Fortunately (for me), CAOS actually *is* similar to assembly, so I'm having an easier time reading/comprehending it than I thought I would initially.. as long as the command reference is handy!

I'm trying to split the program up into functional parts, which, due to my limited knowledge, is more difficult than I anticipated. Logically speaking, the metaroom injection process should be split off from the room data. Just by perusing the CAOS reference I can see a couple of possible methods of passing the necessary data to a worldbuilder/metaroom injector agent (of course, whether any of them actually *work* or not..).

Then again, I may be getting ahead of myself here. >.>

User avatar
Amaikokonut
Busy Bee
Posts: 89
Joined: Wed Jun 08, 2016 10:25 am
Country: USA
Currently Playing: C3/DS
Favorite Game: C2
Favorite Species: Norn

Re: The Progress of Project AMP

Postby Amaikokonut » Tue Jan 03, 2017 3:49 pm

Neat! I like your line of thinking with this. Let me know if you hit any walls in CAOS. I've got some other stuff on my plate right now but I'll try to keep checking in. I've got some other thoughts on this too but I'll type them up a bit later when I have the time. Good luck!

User avatar
Gio
Everyday Egg
Posts: 15
Joined: Wed Nov 16, 2016 5:13 pm
Currently Playing: DS
Favorite Game: C2
Favorite Species: Ettin

Re: The Progress of Project AMP

Postby Gio » Mon Jan 09, 2017 6:04 pm

*grumbles* "Good luck!" she says! Hmph!

.. but then, I did volunteer for this, didn't I? Silly me.

Truth be told, it's not as grim as I paint it above.. but you did mention this was a complex project, and I believe that I am beginning to appreciate the true scope.

In my previous post, I said I was looking at breaking the injection process and room data apart. I got stuck trying to do this; CAOS doesn't make it easy to shuffle data around in that manner. Today, however, I had a brilliant and (hopefully) more workable idea: transforming the default metarooms into individual agents. This accomplishes the exact goal I was trying to achieve earlier, namely making the process easier for us down the road. With the rooms pre-packaged as agents, all AMP will need is a world switcher and world builder..

My thought process:
  • Normal rooms are agents, but they don't have the safety checks that AMP has (and requires)
  • agents can pass variables to their owner (MVxx & OVxx respectively)
  • the builder runs each metaroom agent, and can access what we need to pass to it, and can use the info down the line

Downside, of course, is that we lose that info once the builder ends.. but it seems like a workable solution for now.

...

Unless I'm way wrong about something, or maybe you prefer another method?

User avatar
Amaikokonut
Busy Bee
Posts: 89
Joined: Wed Jun 08, 2016 10:25 am
Country: USA
Currently Playing: C3/DS
Favorite Game: C2
Favorite Species: Norn

Re: The Progress of Project AMP

Postby Amaikokonut » Tue Jan 10, 2017 1:12 pm

Heh, sorry, I really didn't mean to leave you hanging like that. I was actually writing up a much longer and more in depth post about it when I got called into work, so I just posted that short message, hoping it was better than nothing at all. This is the first time since then that I've actually had time to think about it.

To preface though, I don't have a lot of programming experience outside of CAOS so my knowledge of common programming concepts and terms is rather limited; I might misunderstand or require some explanation for your terms, and the way I use mine are probably non-standard and possibly confusing. I'll try to explain/understand best I can though.

There seems to be two major ways of going about this that I can think of. The test script I wrote was a method of stand-alone direct injection that did not require other scripts to function (well, except the favorite-place-icon scripts, but DS comes preinjected with those.) This is the method by which all C3/DS rooms are currently injected. When you mentioned separating room data from injection though, I started to consider the option of having an AMP-core that would handle the process of injection, and then have metaroom scripts going forward simply hold a bunch of variables containing the room data that the AMP-core would read from and do its thing with. This is similar to the way that Magic Words and Garden Box agents work, and I believe this is the method you are referring to in your most recent post, if I am understanding you correctly.

I think there are pros and cons to either way. However, the thing I've liked most about "core" agents in the past is that it puts less work on the developer and makes it easier/faster to put out a working agent. But in this specific case, it doesn't really matter because the room data is going to be painstaking to convert no matter what without an external script (python or otherwise) to automate it, and my intent is to write that script anyway (and probably give it a web interface and generally make it as easy to use as possible). So the amount of work for the average developer is probably going to be the same regardless of if it gets converted into an agent that injects itself or an agent that the core is going to read and inject.

With that benefit thrown out the window, I'm a little less interested in an AMP-core simply because making a scripts dependent on another script that the user has to download/install separately tends to lead to confusion among users. Not a ton of confusion generally, but it is an extra degree of complexity that I feel like has to justify itself somehow.

There are of course benefits to the core though. Having a core do all the heavy-lifting means less chance of error in modified third party scripts. The core could also do stuff like store the map of the world so it doesn't have to run the search script on the entire world every time a new room is injected, speeding up injection. On the other hand though it might slow down injection because it has to read and parse all the variables stored in the room-data-agent, so I'm not sure what would be faster in the end. We might down the road be able to beef up the core to make it capable of some other stuff too, like maybe automating world-wraps and CA links? And it would just generally be nice to be able to update the core to a new standard and it would affect all rooms injected using that new version of the core agent/scripts.

But at the same time, I don't foresee an AMP-core needing that many updates once it does what it does, and while that other stuff is a nice ideal I don't know that I'd actually practically get around to doing it. There's also the thought that some devs who want to use the AMP-standard would just generally prefer to have full control over the injection process and not depend on other scripts.

I dunno, am I making any sense? I think I haven't really been able to articulate what I'm getting at very well but I think I'd rather post this now than wait another several weeks to perfect all the wording (or just leaving you with another 'good luck' message). Just let me know if I'm being utterly confusing or if you need clarification, heh :oops:


Return to “Projects”

Who is online

Users browsing this forum: No registered users and 2 guests