Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

What's the best/most efficient way to examine something?

A topic by Garry Francis created Nov 02, 2019 Views: 197 Replies: 7
Viewing posts 1 to 5
Submitted

When you examine an object, there are several ways to handle it in your code. If it's scenery, you can use a match statement in the locations{} block or the on_command{} block. If it's an object, you can use a match statement in the on_command{} block. If it's scenery or an object that doesn't require any conditional logic, you can use examine_message in the objects{} block.

This is probably just a question of style, but is there any "best practice" for locating code for things like examine? I'm also curious about which is more efficient. I'm guessing that placing it in the examine_message is more efficient as it requires less code. The thing that I'm uncomfortable about is that command handling is scattered about in different places. This makes it harder to maintain your code. Any thoughts on this?

Submitted (1 edit)

I too find the code a bit unwieldy when examine commands are in different places, as when a game project gets big I can never remember where I've put things (I end up keeping a notepad file with the entire code open so that I can Ctrl+F).  As such, what I've been trying to do is keep everything under on_command and in alphabetical order, despite the fact that it would be a lot easier just to use examine_message (this also helps if I later decide that a particular object IS going to require conditional logic).

Host

It is a matter of style but I'd personally favour one of three approaches

  1. Put EVERYTHING in on_command {} block. All examine logic for objects AND general location logic goes in here, nowhere else.
  2. Add a : gosub "examine_messages" ; to the on_command{} block and put everything in a new subroutine called "examine_messages". All examine logic for objects AND general location logic goes in here, nowhere else.
  3. Put all examine per-object examine logic in the objects definitions themselves, and put all per-location examine logic in the locations themselves.
   lamp : object "a lamp" {
      start_at = my_location
      on_examine {
         : print "Hello" ;
         : done ;
      }
   }
Submitted (1 edit)

Location-based examines sounds like not a good thing to do, though there are exceptions of course. I can speak only for myself but I'm usually working with a different system to develop my games, which gets then imported in Adventuron. There I'm adding an examine message that is based on the fact whether the object is present at the location where you're invoking the code or not. So my examine commands are mostly object based. Sometimes they are location based because there is no object but maybe something in the room description that wants to be examined. But even in that particular case I have the code all at one place. That didn't change in Adventuron btw. but as far as I understand my code is mapped and created different to standard Adventuron code. 


Submitted

Thanks folks. All good advice. I'll give this some more thought and come up with my own little set of rules to cover different types of objects.

I've currently got a LOT of code in the locations{} block. This works well for static objects and you don't have to remember to have an is_at "room" test. I had been using a lot of non-objects to account for nouns in descriptions, but if you try to get one of these non-objects, Adventuron tells you it's not there, even though it's staring you in the face. Therefore, I've been steering towards scenery with conspicuous = "false". This means you have a lot more objects, but at least Adventuron says "You can't get that." rather then "It's not here." The downside is that you can end up with lots of duplicate objects or multiple is_at tests or you have to implement floating objects and use is_present. There are pros and cons for all these techniques.

Submitted (2 edits)

For Adventuron, this sounds like something you can do as you don't have to consider the constraints of an 8-bit / 16-bit platform. If you ever think about  porting your game to 8-bit or 16-bit, you will likely regret this decision and / or need to revise large chunks of code. As far as I understood, Chris is working on a way to export from Adventuron to DAAD (the Adventure System I'm maintaining with Tim Gilberts and a few others). So with that in mind, a purely object-centric approach would likely support you if you ever want to see your games on an oldschool platform. Cheers :) 

PS: Rabenstein was developed in DAAD and then exported with the DAAD2Adventuron tool that Chris created (currently in Beta). So it already worked the other way around.

Submitted

I decided to move all the command handlers to the on_command{} block. It's easier to maintain that way because it's all in one place. Would that make it easier to export to DAAD?

I'd prefer a system whereby each object has its own on_command{} block. This makes it more object-oriented, such that data and methods (command handlers) for each object are all in the one place.

Submitted

Yes, that would make it considerably easier as that pretty much is how DAAD handles the approach as well.