Up to Main Index Up to Journal for February, 2017
JOURNAL FOR TUESDAY 28TH FEBRUARY, 2017
______________________________________________________________________________
SUBJECT: Completing the ‘other side’
DATE: Tue 28 Feb 23:11:06 GMT 2017
Last week was a pretty good one for WolfMUD. I spent Wednesday and Thursday
evenings hammering out the last details for implementing doors and event
handling followed by clean up and documenting. Then Friday and Saturday I was
coding till gone 4am adding a Thing/Attribute copying mechanism and
implementing the ‘other side’ of doors.
Coding till 4am for fun, on WolfMUD, is something I have not done for a very,
very long time. It wasn’t planned, everything was just falling into place and
working so well I didn’t realise what the time was :)
The postal package and postal.Service function are now finalised as the event
package and event.Queue function. Events are now very simple. You queue an
event using the Queue method which returns a channel:
func Queue(thing has.Thing, input string, delay time.Duration) Cancel
To cancel an event you just close the returned channel.
I’m also planning ahead for an event.Schedule method for reoccurring events.
The attr.TitleName function that I mentioned last time is now in the text
package and named TitleFirst. It still just uppercases the first rune in a
string but is a useful addition.
What else was there? Copying a Thing and/or Attribute. I did think of using
Go’s reflect package for doing the copying. However there are some struct
values that should not be copied. An example would be unique IDs and locks.
I decided that each Attribute should best know how to make a copy of itself.
All types in the attr package now have a Copy method that return, a possibly
inexact, copy of itself. The Thing type also has a Copy method that allows for
copying a complete Thing with all of its attributes — and possibly other
Things, such as when copying a container which has its own inventory.
Copy will be more important later on when we need to make copies of objects as
they are spawned — either due to a reset or buying new items etc.
I implemented copying now so that I could easily create the ‘other side’ of a
door.
Doors in WolfMUD consist of two sides. Assume you have an exit from location A
to location B. To put a door between the two locations you add one to location
A and the ‘other side’ is automatically created at location B. The reason for
two sides is that depending on which location you are in — A or B — you need
to be able to examine, open and close the door. If you only had one door it
would have to be in two places at once[1] or somehow between two locations.
So that both sides of a door open, close and reset together they do share the
same state.
If everything goes to plan this Wednesday — 1st March — I’ll be spending time
finishing everything off. Everything is working now, just need some addition
documenting. Wednesday I hope to push everything out to the public dev branch
as well. Then Thursday I’ll release everything as v0.0.4 for people to play
with.
Next I need to sort out the zones package. At the moment it does a lot of work
that should be implemented by attributes themselves using a PostUnmarshal
method — I’m hesitant to call it an init or setup method. For example linking
exits and creating the ‘other side’ of doors should be handled by the Exits
and Door types. It will make it so that the code is with the corresponding
type rather than tucked away in the zone package. It also means the zone
package does not get hacked about when new attributes are added. Adding a new
attribute should be as simple as adding the type into the attr package and an
interface into the has package.
--
Diddymus
[1] If the same door was in two places at once it would block the same
direction in both locations. That is in location A it would block south,
but also block south in location B instead of the return direction of
north, back to location A!
Up to Main Index Up to Journal for February, 2017