When objects need to talk…

[fiz]

Hello,

For over a year since I’m here, I have understand one main thing (among a lot of wonders):

If you find yourself writing a lot of code to make something work, it means you are on the wrong way.

Either you are trying to implement something so special that your users will need a big documentation to use it, or you didn’t find the correct method of the correct class.

I develop applications for children, so I can’t ask them to read a thick user manual before accessing the keyboard. Some of them come from the PC world, so things have to be even more simpler on a new machine.

I’m not a professional programmer, so I don’t have the time to master 300 classes with their dozens of methods each. Days only have 24 hours.

That’s why this site is very, very precious to me and people like me.

Now for the problem (ahem).

I have some objets (they are objects in the OOP sense: abstractions for real objects like a door, a lantern, a dragon and so on) collected in an array (I like to keep an eye on my objects and I know NSArrays are more smart than “just arrays”. They can be enumerated, filtered with predicates, merged and so on).

I want to give my objects some artificial intelligence (a really basic one). I want them to be aware at what happens to others, and react accordingly. The base of this “intelligence” is given by a (property) status, which makes them capable to receive certain messages and execute certain actions.

“Ha ha, you are trying to implement a finite state automaton using objects!”

Well, some of. Let’s say we have a DOOR object: it status is «isClosed» or «isOpen». If it’s «isClosed», it can receive the message “open”, but this message must be sent by a KEY object. If a CAN OPENER sends the “open” message, the DOOR will respond “I can’t be opened with a can opener!”. When the KEY sends the “open” message to the DOOR, the status of the DOOR become «isOpen».

But the KEY must have the status «isCarried» to send the “open” message". If its status is «isBroken» it can’t send the message. Got the picture?

This is my Model part: a collection of objects whose status (ok, “state”) allows to send or receive specific messages.

The View part consist of a textual description of the object to be inserted into a NSTextView, like “There is a door in front of you. The door is closed.” and some buttons which appear when the DOOR is selected, like “Open”, “Break” or “Leave alone”. Clicking on “Open” will, of course, send the message to the DOOR, even if the KEY is not carried: in that case, a dialog will appear, saying “You can’t open the door. It is locked”. If the key is carried, the text becomes “There is a door in front of you. The door opens on a dark corridor.”

Note: this example is just to demonstrate the concept: you may replace the door and the key with a dragon and a magic sword.

So the main problem is the Controller part. That’s why I need your cocoa’s knowledge because I need a good start:

How make my objects “aware” of the other object status? Do they have to? For example, a PARCHMENT can be read if the user carries a LAMP, so it has to “know” the LAMP status is «isCarried» (or that the LAMP is into a “carried things” array).

Oh, “One more thing.”: the objects, their characteristics, their initial status, the condition chain to change the status, everything will be. defined by the user himself before the game begins!

My app is NOT a game. It is a Game Maker.

That’s it. Interested to help me? Consider this as a shared challenge. There could be a lot of things to discover about new classes, arrays, enumerators, messages, class/instance variables, maybe useful for other (more serious) applications.

Thanks for sharing!

[DJ_Bazzie_Wazzie]

@fiz

If you find yourself writing a lot of code to make something work, it means you are on the wrong way.

Since when? Cocoa gives you basic objects for basic programming. If that was true what you were saying then why should there be sub classing? That’s the whole idea of OOP and it’s advantage of procedural C. Cocoa is filled with classes that ‘fits in most cases’ but I still haven’t found a circular linked list in cocoa. Just because they seems complex and not needed in many cases. Just give a programmer a simple as possible (indexed) list and leave it like that.

@fiz

Either you are trying to implement something so special that your users will need a big documentation to use it, or you didn’t find the correct method of the correct class. I develop applications for children, so I can’t ask them to read a thick user manual before accessing the keyboard. Some of them come from the PC world, so things have to be even more simpler on a new machine.

:D… both wrong. Interface design is and programming are two different things. The programming can be very complex while the interface remains very simple. That’s the goal of every programmer.

@fiz

I’m not a professional programmer, so I don’t have the time to master 300 classes with their dozens of methods each. Days only have 24 hours.
That’s why this site is very, very precious to me and people like me.

Who says he does, class, property and method names should speak for itself. Luckily they do in most of the programming languages today. This site is precious for that because AppleScript is harder to learn every command property and class.

@fiz

I have some objets … maybe useful for other (more serious) applications.

you said that your app isn’t a game but before you can create a game maker you have to know how games work. well games aren’t made in one night, unless you make hangman or tic tac toe ;). The easiest way to start is looking into a text based rpg game (this is how almost every game developer (book) starts). Starting this way you can evolve your 70’s like text based game to a state of the art game that can compete with today’s game. Most of today’s games still work with the same principles as the ‘old’ games.

How you are gonna work completely depends on your demands. There are tons of examples and unfinished op source projects that shows how it should work. In Xcode 1 and 2 there was an example project about a platform game which also shows you how you could make a game.

I can’t answer all the questions you have asked. Because it will take me a day and nobody would be interested in reading a post that take up to hours of reading. If you start you can ask questions that pops up.

[SuperMacGuy]

I agree with DJ.

On the question of “how to know what objects affect others”, I would say (from my non-gaming perspective at least) that each item would have properties or keys it can respond to.
For example Door object would have properties it knows about:
Door


key turn, brute force, digital badge swipe

open, close

Your door object doesn’t need to know about every other item in the game. It only needs to respond to actions from any other item. If an item acts upon the door, it gives it’s properties to the door. If they match, then it works. If not, then door doesn’t respond.

Key


rust

key turn, cut cardboard box

Can opener


rust

can opening, bottle opening

So when someone “uses” object key on door, you send some “action” that tries to match the door’s “affected by”. You only have to worry about each object’s list of properties, and of course keep your syntax for matching consistent on all objects. I think you understand this.

But your DOOR object doesn’t need to know the key “isCarried”. It only needs to receive the action message. Your “game player” object should somehow handle if the key is carried or not. If game player “isHoldingKey”, then it tells key to send message. If not, then key doesn’t send message. Same thing with your Lamp example. If game player has lamp in its list of “objects I am holding” then it tells lamp to send a message to “illuminate area”. If your lamp isn’t held/owned by game player, then the message to lamp goes nowhere and nothing happens.

[fiz]

Thank you for taking the time for these long and detailed comments!

@DJ Bazzie Wazzie

If you start you can ask questions that pops up.

Sure I will! I’ll look for references for these “old” games (the only one I get is a FORTRAN source literally stuffed with GO TO statements In parallel, I’ll try to gain more knowledge about classes, messages dispatching and so on.

@SuperMacGuy

So when someone “uses” object key on door, you send some “action” that tries to match the door’s “affected by”. You only have to worry about each object’s list of properties, and of course keep your syntax for matching consistent on all objects.

Thank you very much for this point of view – When I wrote my post, I was asking myself if “everything should be aware of everything” was the correct way. Well, it is not. Your approach is, of course, more simple: the objects are better characterized, and the object-to-object interactions more specific, and your “non-gaming perspective” is, in fact, very “gaming” – if such a programming perspective exists!

Your answers made me reconsider the problem. I’ll try to be less general with my future questions, and meanwhile I’ll read, try, read and try again.

Thank you very much!

[DJ_Bazzie_Wazzie]

@fiz

Sure I will! I’ll look for references for these “old” games (the only one I get is a FORTRAN source literally stuffed with GO TO statements In parallel, I’ll try to gain more knowledge about classes, messages dispatching and so on.

You can take a look here at this site

EDIT: this one is pretty good very small and still have some features, you can download it here

[fiz]

Hi DJ,

Exactly! The “Colossal Cave” is the FORTRAN IV program, with it’s (slightly different) C version. I played with it during hours in the early '80. Strange to have a look inside this mysterious code so many years later.

[DJ_Bazzie_Wazzie]

@fiz

I played with it during hours in the early '80. Strange to have a look inside this mysterious code so many years later.

I like that too. I also looked into the code of ROTT ('95) which was a FPS and was in that time a very large game. When looking at the code (source code is free of this game as well) I wasn’t expecting that the game was that small and simple.