Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

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.

(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.

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.

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