flesk

Amnesia Adventure Programming and Asset Creation

Recommended Posts

@Jenni: I'm having some issues with the skeleton engine, that I hope you can take a look at when you get a chance. I posted an issue on the issue tracker.

I've also been playing around a bit more with Escoria and I'm able to make some stuff with it now, so I figured I'd write some observations that are probably obvious, but are less immediately actionable than the things Jenni posted in the issue tracker.

Unlike some other adventure game engines, the Escoria framework doesn't support actions on anything but what is referred to as items (unless I'm reading things wrong), so it's not possible to define actions on something that isn't a separate node. For artists, this means that items that can be interacted with should be separate images with a transparent background that can be placed in the game. Don't put any extra effort into this if you don't want to, since they can just be cropped out of your background image.

Escoria has a very flexible verb interface, and we can easily choose between a verb menu (Monkey Island style) and an action menu (Full Throttle style), or probably single-click (though I haven't figured that out yet). Artists should make images for the verb/action buttons if we decide to go with that, preferably with separate normal and clicked states.

The inventory is similarly flexible, and is just defined as a number of points on a background with with buttons for scrolling through the inventory if needed. This means we can have a traditional inventory with separate slots or something like the cardboard box in Sam & Max: Hit the Road (I don't know if it's possible/easy to make the inventory appear/disappear within the Escoria framework though). Items that can be picked up should have separate images with sizes that fit the inventory, so we need to determine a size.

Playable characters should at least have three separate images for idling and walking: left/right (only need one, since it can be reversed), front and back, but preferably more for walking at least.

Edited by flesk
I was wrong.

Share this post


Link to post
Share on other sites

IIRC, the Forum Downtime Funtime Adventure had interactable objects that were part of the background (the robot was actually part of the background).  I'll dive into it and update the skeleton engine to have interactable photos from the background image, to make it clearer how to do that.

The Forum Downtime Funtime Adventure used a simple one click interface - although I like the idea of going with left/right mouse click (left click for action and right click for look) for this project just to keep the scope smaller so we don't have to worry about conditions for different verbs.

Yeah, I agree three would be the absolute minimum for animation of sprites, so you could do 1 (idle), 2 (left foot), 1 (idle), 4 (right foot).  That should probably be our goal for now - we could add more as a longer term goal to make things look more fluid.

Right now, scaling in the skeleton engine is wonky, as I'm not quite sure where they put the vertices for the depth (that's the only real drawback of the Godot engine, as things can show in a scene that are actually set up as a node in another scene).

Share this post


Link to post
Share on other sites

Yes, you're right about clickable areas not having to be separate control nodes. There's a bit more to defining interactive elements in the background and they should preferably have a two-color click mask but it's definitely doable. 

Share this post


Link to post
Share on other sites

Does Escoria have built in stuff for nicely handling perspective scaling?

Share this post


Link to post
Share on other sites

 

14 hours ago, Cheeseness said:

Does Escoria have built in stuff for nicely handling perspective scaling?

Yep.  It does.  I pulled that out of room 1, as it didn't need it, but it's in the Escoria test scene in the repo.  Basically, you set Navigation2D to use a terrain map with color indicators for the different depth. You can also change the color of the character (such as if they're under a red lamp for example), using this method as well.

Share this post


Link to post
Share on other sites

I checked out the previous commit yesterday (the last one is just a logo, I think—no code changes), and the menu and scaling seem to work nicely now. :) Good job, Jenni.

What doesn't appear to work now though, are the tooltips that are supposed to appear on hovering over items. Did something in said commit break that feature, or was that not working before either?

I noticed that the verb menu was disabled too, but the action menu is not working for when added to a scene, as per the instructions in the tutorial. I can tell that something is happening by inserting some breakpoints into the code, but it's possible that something is broken upstream on that one, unless either of you are able to get that to work? 

One-click actions work nicely though, but there's no support for a right-click action out of the box in Escoria, as far as I can tell, after spending some time digging through the relevant code. I figure I can add that in without too much work, if we want that. Plus, it might also be a nice feature to add to upstream Escoria, in case someone else wants that feature in the future. 

Share this post


Link to post
Share on other sites

I've been thinking a bit about project structure, and I think there's room for improvement in the way the project is laid out. Currently, the file structure for the test scene looks like this:

scenes/test/
├── background.png
├── box.esc
├── box.png
├── box.tscn
├── can.esc
├── can_open.png
├── can.png
├── can.tscn
├── chainsaw.esc
├── chainsaw.png
├── chain_saw.tscn
├── ice_cream.esc
├── ice_cream.png
├── ice_cream.tscn
├── newspaper.png
├── player
│   ├── idle_down.png
│   ├── idle_right.png
│   ├── idle_up.png
│   ├── walk_down.png
│   ├── walk_right.png
│   └── walk_up.png
├── player_anims.gd
├── player.scn
├── test.scn
└── water_bottle.png

I think it would be much better if it was laid out like this:

rooms/test/
├── box.esc
├── box.tscn
├── can.esc
├── can.tscn
├── chainsaw.esc
├── chain_saw.tscn
├── ice_cream.esc
├── ice_cream.tscn
├── player
│   ├── idle_down.png
│   ├── idle_right.png
│   ├── idle_up.png
│   ├── player_anims.gd
│   ├── walk_down.png
│   ├── walk_right.png
│   └── walk_up.png
├── player.scn
├── sprites
│   ├── background.png
│   ├── box.png
│   ├── can_open.png
│   ├── can.png
│   ├── chainsaw.png
│   ├── ice_cream.png
│   ├── newspaper.png
│   └── water_bottle.png
└── test.scn

First, I think we should rename the "scenes" directory to "rooms" to avoid confusing game scenes with Godot's concept of scenes (unless there's too much hard-coded logic that depends on game scenes being in a directory named "scenes").

I also think it would be a good idea to only place scene files (.scn and .tscn) and Escoria script files (.esc) in the base directory of the room. That way, it's easy to tell which interactive elements (usually a playable character and some items) that are present in the room and it's easy for non-coders to find the script files if they want to edit dialogue and add actions themselves. 

Only items that it should be possible to remove or hide from the scene needs sprites, but other interactive items will usually have a click mask, unless they have simple geometric shapes. These files would probably also go in the "sprites" directory, so maybe "sprites" isn't the best name for it. I don't know.

Thoughts?

Share this post


Link to post
Share on other sites

It sounds like a good idea - especially moving the assets out of the rooms (I actually started moving them out to /art in the latest repo code - but it would definitely be better if they were sorted by how they are used in the engine).

I simply set the verb menu to not appear for now.  And, I agree that it would be a good idea to make a pull request for the changes we make to Escoria (the menu is actually pretty broken in upstream Escoria, so any fixes we make to it will definitely be helpful to anyone wanting to use Escoria.

Share this post


Link to post
Share on other sites

Yeah, there seems to be a bunch of stuff that's pretty broken in upstream Escoria, so hopefully we're able to fix some of it. I'm guessing that it hasn't been used much for creating games, besides Dog Mendonça.

I started converting some of the .scn files to the newer, text based .tscn format, since that will make it easier to track changes. For things that are unlikely to change, it's probably not worth it, but I think it might be a good idea for the files we make at least, plus stuff like hud.scn and inventory.scn, which are likely to see some changes. On updating one of the placeholder rooms I managed to break it a little, and it gave me a chuckle, so I figured I'd share:

http://i.imgur.com/TO4BXqd.gifv

I had forgotten to reposition the playable character within the walkable area. Surprised it worked at all.

Share this post


Link to post
Share on other sites

@Jenni: I see that you have created a separate directory for playable character sprites. I think that's a great idea, since that will make a lot more sense if we want to use the same character in more than one room. With that done, I don't think there's any reason to have player animations and player scene files under room directories anymore though, so I think we might as well move those in with their respective assets, so that we don't have to either duplicate player scenes or instance players from different rooms.

I.e. instead of:

├── characters
│   └── doug
│       ├── idle_down.png
│       ├── idle_right.png
│       ├── idle_up.png
│       ├── walk_down.png
│       ├── walk_right.png
│       └── walk_up.png
└── scenes
    ├── doug_1
    │   ├── doug_1.tscn
    │   ├── player
    │   │   └── player_anims.gd
    │   ├── player.tscn
    │   └── sprites
    │       └── doug-bg-jennibee.png
    └── doug_2
        ├── doug_2.tscn
        ├── player
        │   └── player_anims.gd
        ├── player.tscn
        └── sprites
            └── doug-bg-jennibee.png

we'd have:

├── characters
│   └── doug
│       ├── idle_down.png
│       ├── idle_right.png
│       ├── idle_up.png
│       ├── player_anims.gd
│       ├── player.tscn
│       ├── walk_down.png
│       ├── walk_right.png
│       └── walk_up.png
└── scenes
    ├── doug_1
    │   ├── doug_1.tscn
    │   └── sprites
    │       └── doug-bg-jennibee.png
    └── doug_2
        ├── doug_2.tscn
        └── sprites
            └── doug-bg-jennibee.png

 

Share this post


Link to post
Share on other sites

I managed to add in support for a two-button interface, and have made a pull request to Escoria, but I haven't added it into our code yet, since it's pretty minor in terms of lines of code and I have a couple of bigger PRs pending on Amnesia Adventure that I want a second pair of eyes on. I'm not used to working on more than a couple of branches at a time, so I'm worried I'll goof something up if I add yet another one.

I forgot to say that the PRs I have pending on Amnesia Adventure code is mostly some cleaning up of duplicate files and making a file name lowercase and without spaces to avoid any future gotchas. Plus I changed the name of the scenes/ directory to rooms/ to make talking about things less confusing to those of us working on the code. This last one might blow up a bit though, if it's not merged or discarded before we continue working on things.

I also made some very quick notes on folder structure on the wiki. We're not quite there yet though.

Share this post


Link to post
Share on other sites

I wanted to be able to help out with the programming for this project but unfortunately my uni work has been taking up most of my time so I've not been able to take a good look at what has been happening yet and I don't know if I'll have much chance before the end of the fortnight, as it'll depend how soon I'll be prepared for the assessed pitch I have to do next Thursday (not to mention work on an essay which is due a week after that). I'll try to help as best I can within the AF time frame.

Share this post


Link to post
Share on other sites

Don't worry about it, @CorruptBiggins. Studies must come first, and I'm hoping that this project will live on after AF is done, so you'll get a chance to contribute.

Share this post


Link to post
Share on other sites

No worries, @CorruptBiggins - @flesk is completely correct.  Real life responsibilities should always come first.

We're aiming to have this game open to development after Amnesia Fortnight is over, so you'll have time to contribute then. :)

Share this post


Link to post
Share on other sites

I noticed that Escoria upstream is just a stripped down version of the "Escoria in Daïza" demo.  That's why there's a lot of missing dependencies (such as popup_confirm, the music loop in bg_music.tscn, etc). I'm working on using that as a base, stripping out all of the demo assets, replacing our assets and changes.  It will probably be at least a few days, but I'll create a big pull request after everything's in.  Hopefully that solves a lot of the stuff on the issue tracker in one go. *fingers crossed*

Share this post


Link to post
Share on other sites
2 minutes ago, Jenni said:

I noticed that Escoria upstream is just a stripped down version of the "Escoria in Daïza" demo.  That's why there's a lot of missing dependencies (such as popup_confirm, the music loop in bg_music.tscn, etc). I'm working on using that as a base, stripping out all of the demo assets, replacing our assets and changes.  It will probably be at least a few days, but I'll create a big pull request after everything's in.  Hopefully that solves a lot of the stuff on the issue tracker in one go. *fingers crossed*

Make sure that the licences are compatible and credits are updated appropriately (eg: MIT requires that upstream copyright notices are included in derivatives).

Share this post


Link to post
Share on other sites
2 minutes ago, Cheeseness said:

Make sure that the licences are compatible and credits are updated appropriately (eg: MIT requires that upstream copyright notices are included in derivatives).

Escoria in Daïza is released under the MIT license too, so that shouldn't be a problem.  I'll make sure that I add it to the MIT license for Amnesia Adventure though. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now