[somehow]

eigenbom, your answer to some of the serious concerns I and others have raised is to.... try to push suspicion my way instead?

I've been telling myself to try to keep an open mind about things, in case, despite the obvious and glaring signs at this point, that there may somehow be a reasonable explanation. If there actually was one, you're really not making it easy to figure out.

[not]

Okay, I'd say that it may be a reasonable assumption that eyeliner was a demon under the circumstances! Whilst in theory it could be an elaborate ruse of some sort, I really doubt it. This is definitely good news: Not only have we taken out a demon, but we now have some indication as to whether the Hand managed to correctly identify a demon. This would suggest that the two previous targets of the Hand were not demons. They may have been innocent.

Noah, one thing that I was hoping to ask (before night fell suddenly fell and I found myself asleep, part way through composing my thoughts) was why you had decided to go with eyeliner. As it turns out, it was an incredibly good choice. What led to your decision?

I hope you all didn't miss the mention of the "no ash" reference on eyeliner's death. I am now reasonably convinced that ash is significant in some way- why all of these ash references, plus an explicit mention that there was none in this case? I still don't know what they mean, but at this point would most agree that they are probably significant? I'm wondering if the "no light" reference is significant too.

Now, as for the other two deaths. Randomasta is quite likely to have been a demon too- note the scorch marks, the "obviously writhing with pain and suffering", lack of body, and probably a narrative slip in saying "its death", rather than "his death". This would mean that we've taken out two demons in one night! Finally some good news.

The question is- who killed him? Was it the deliberate act of an ally to the town, or are we watching two rival factions fight over us?

One thing is terribly interesting: One faction killed Jared, and another killed Randomasta, who I'll assume was likely a demon. I'll also assume the demons are not killing their own. This means we have two factions:

- Faction A, who kill by ripping people apart, and as far as we can tell, have never killed a demon. They have also killed every single day thus far, with (more or less) exactly the same results.
- Faction B (or C, D, etc) who have killed a demon. One died by ash, one night was skipped, and one died demon-style with no ash. It's possible that these are all indpendent parties.

I'd say Faction A are very likely to be demons- Faction B certainly aren't, and they seem to be hitting innocents. Faction B (or, possibly, multiple independent parties) are probably the enemy of the demons (since they killed one, probably), and may be our friends? Or maybe not? In any case, they aren't just hitting demons exclusively- is this deliberate, or an accident?

Shortly after SirNiko was picked by PBS to die, he sent me a message, asking if I had any abilities that I could use. It struck me as unusual, as he would not be able to usefully use any information I gave him, as he was due to die that evening by PBS's hand. I guessed that it probably meant he had allies he was relaying the information to before being killed. I messaged him back, and told him that. I never got a reply- he was killed before I got one. Perhaps this is Faction B? Or something else?

My theories regarding whether ashing is an indicator or the killer or the killed might be interesting to revisit. It seems that the means of death indicates both the killer and the killed. Demons die in an explosion of flame (apparently)- but demons also kill in a certain way (if I am correct). I'd say that the method of death indicates both the killer and victim.

As for Jared- I'd say it's likely that we have lost one of our number. All indications are that Faction A hit him, and with a body and nothing more specific than normal, I'd say he was innocent.

Another thought: Perhaps there is no Faction B at all, just a bunch of us lashing out, hoping to hit demon targets if we can.

I'll ask a question of the Hand: Did you have anything to do with taking down Randomasta? You've said you didn't ash Ashkin, but how about Randomasta? This is really important as if you did it, then my theory about burning indicating demons could be wrong.

(Although, on a quick review of page one of the town records, Randomasta and Eyeliner are crossed off in red. I'd say that the theory that they were demons is pretty strong now)

I now have some incredible doubts about eigenbom's position now. He had stated that Ashkin was evil because he was ashed- we now have some convincing information that suggests that demons die in an explosion of fire, not ash, and that the demons are not likely to have killed Ashkin- they hit Shelby that night, not Ashkin. I hope you have an amazingly good explanation for your earlier statements, and for the period in which you vanished, conveniently avoiding the questions that myself and others asked. I think we are all incredibly curious as to what you have to say on the matter. Short of an amazing explanation at this point, I suspect we may be looking at demon number three right here.

Noah, thankyou for your reply. To be honest, I had absolutely no idea how you would address my queries- or if you would address them at all. What I did not expect at all was a fairly detailed reply answering most of what I had asked- which is exactly what you gave.

Much of what you say is quite reassuring. Time will tell, of course, but I hope at this point that it is okay to be... cautiously optimistic.

On page eleven of the town records I suggested a number of theories. Based on what you knew before, and what you now know, in the role of the Hand, is there anything you can add to any of these? Are any clearly wrong? Does anybody have any information that they can (safely) share that might give us some further clues as to the nature of the enemy that we face?

[Put it in Putin]

Put it in Putin was shown on the acclaimed Swedish public service prime-time TV-show Kobra. Kobra has also brought us classics like Hitler singing Born to be Alive.

Dear God. That this video exists is basically proof that someone, somewhere decided that it would be cool to put together a video about vibrators and Putin, and actually took the time to painstakingly put it together.

No doubt wielding the blade is a heavy burden, and those chosen by the blade may find themselves in a position where they cannot carry its full weight and the obligations it entails. It is no doubt a difficult weight to bear. To hold it aloft even without wielding it at its full glory is still an accomplishment. I would wish PBS the best in his continuing journey. (OOC: Best of luck with whatever is presently troubling you- I hope you get through things okay)

I am very curious as to what this new development is going to mean for us all. I have spoken at length about the Hand of God and peanutbuttershoes as one, but now we find ourselves in a situation where the role has shifted, possibly changed, and the title is also now held by another. No doubt much of what I've speculated regarding the Hand may be rendered moot by these changes, whilst some things will remain pertinent. This change is going to force us all to rethink any assumptions we may have made about the role of the Hand thus far. In a way, we are starting again, and I hope that this will only be a temporary setback.

To Noah, the New Hand, I ask: What role do you see yourself playing in this town? What path will you be walking- will it be your own, with us, or similar to the path walked before? Will you work with us to determine who the demons amongst us must be- or do you feel you are driven by a divine mandate that puts you beyond our input? Can you- or will you- shed some light on the mysteries surrounding the unusual role and activities of the Hand in this town thus far?

(OOC: People going inactive or low-response is an unfortunate reality in these sorts of games. In the TIGSTWG I ran some years back I had one player with a key ability go inactive, and it was necessary to change some things both behind the scenes and in front of the rest of the players to keep the game both balanced and running. A in-game event can be used to change and justify just about anything, particularly in a setting in which divine intervention would be a natural part of the story. If there are enough active players remaining with the right roles and a sudden dramatic change via game event would help, I'd suggest considering this as an option.)

Yes it is actually implemented as the former. The entities inherit from a base entity class and much of the code refers to them in a generalized way as instances of the base class.

Ah, cool.

However I also handle some entity-type specific things outside of the entity object's personal code. So I'm storing a type string in each entity which will let me know what type it is, so I can make specific choices about how to handle certain behaviors. I'm fearful that this is a terrible way of doing this, but as I said before: It works well enough, and it isn't getting worse. Although I can't say the same for the overall editor structure.

A quick way to move this more toward an object-oriented approach is to consider what you're actually testing. Are you genuinely after a specific class, or certain properties of that class?

For example, suppose only certain entities interact with the player. At the moment you have a switch that picks out all of the relevant cases, like this:

Code:

switch (foo->type())
{
  case TypeBullet:
  case TypeEnemy:
    handleInteraction(foo);
    break;
}

You could change this instead so that the class itself indicates whether it can interact:

Code:

if (foo->interactsWithPlayer())
  handleInteraction(foo);

You'd make the default implementation one that returns say false, and each class that should interact with the player overrides it with its own version that returns true.

If you did this, and later on you wanted to add a new entity that is a child class of an existing one, you'll just need to derive the new class from an existing one, and it would work. Without this, you'd have to go to each and every place with one of these switches, and update it. It also means that if you add a completely new entity, your initial implementation would just involve you going through the functions in the base class, and considering what values should be returned. It's like filling out a questionnaire about your new class. It works well.

As mentioned with the hammer analogy, it's just a tool though. If the change is going to make things worse, don't do it. I mention the example above as it's quick, easy, and frequently gives a good return on the time you spend doing it.

One of my main top-down design goals is to keep the game Model completely unaware of the game Visualization (so no draw methods, images, animations etc. in the game model objects). Rationale: I want to be able to use different visualisations on different platforms and to run the model code either locally or on a server.

I haven't found or figured out a good design pattern for this yet. So if anyone has any ideas, I'd be interested to hear them.

Here's an idea: For my current project I have the concept of something called an Actor. The main project code can give it positions, tell it where to move, start animations on it, and so forth. It is a big wrapper around the concept of a moveable, animated graphical entity, with certain properties that make sense for my project. The main code doesn't have a clue what the underlying engine itself is doing, and doesn't need to know, as it creates and sends instructions to these Actor objects. The Actor code doesn't have a clue how the project works, and it doesn't matter. Then, there's a Scene object, which includes terrain. And so forth. If you can break your game up into several of these coarse concepts, then you could take a similar approach. I have similar design goals to yourself, and this is what I have done.

Another idea, which I don't recommend, is to make a light wrapper over the graphical API. I don't recommend it as it can take an awful lot of work and only really comes out right if you have a very good understanding of every API you might possibly use, and can factor this into your design decisions. It's a great concept, but the reality is that the implementation is painful once you get beyond one underlying graphical API. For larger team projects though, it'd probably work great.

The main issue that I'm having related to this, is that all entity types are implemented as new sub-classes of a base entity class And each entity has a separate header and source file. Besides just adding two files to the project, I also need to tell some other bits about the new entity types. Any time I want to add a new entity type, it is actually a bit of a pain because I have to make changes in four or five places instead of just one.

Wouldn't you need to make changes in multiple places to accommodate the new entity types anyway, whether they are implemented as separate types, or somehow bundled together?

For what it's worth though, if you've got code that acts differently based on the type (say, in C++ switches), is it something that you could store in say virtual functions (I'm assuming C++ here), and provide a default implementation for each hook in the base class? That way, when you add a new object, all you have to do is to go through that object (one file), and add code to handle each hook. If you need new hooks, you can add them in, provide a basic default implementation in the base class, and override it in the new class.

As a partial example:

Code:

class Entity
{
  ...

  public:
    virtual void move() {sitIdle();}
    virtual void ponder() {muse();}
};

class Fish
  : public Entity
{
 
  public:
    virtual void move() {doSwim();}
    virtual void ponder() {blowBubbles();}
};

class Human
  : public Entity
{
 
  public:
    virtual void move() {takeStep();}
    virtual void ponder() {chewGum();}
};

...

void foo(Entity *e)
{
  e->move();
}

void bar(Entity *e)
{
  e->ponder();
}

rather than:

Code:

void foo(Entity *e)
{
  switch (e->type())
  {
    case EntityTypeFish:
      doSwim();
      break;
    case EntityTypeHuman:
      takeStep();
      break;
    default:
      sitIdle();
      break;
  }
}

void bar(Entity *e)
{
  switch (e->type())
  {
    case EntityTypeFish:
      blowBubbles();
      break;
    case EntityTypeHuman:
      chewGum();
      break;
    default:
      muse();
      break;
  }
}

I've generally found the former far easier to maintain- all of the relevant code is bundled together. In the example above, the code to handle fishes is all in one place, as opposed to scattered throughout the whole codebase.

One of the things that annoyed the hell out of me at my last job was their insistence on unit tests for everything, even when it made no sense at all. ... I saw so many instances of coders having to create the most convoluted nonsense to accommodate unit tests.

Heh, that makes as much sense as using a hammer for everything, regardless of the problem. A hammer is a great tool, but you just don't use it for everything, and certainly not when it compromises the solution. You use it when it makes sense. The same with unit testing.

Code:

Player.setx(int x)
{
     Player.x = x;
}

That just seems like a pointless thing, but I have seen similar things in the name of the glory of encapsulated object oriented program design.

It's pointless until you've got this code in a few dozen places around your code, you can't remember exactly where, or someone else is working on that code, or worse, random customers are using your code, and changing the API will hammer your support people. You decide to add an information cache based on the player's current position that you want dirtied immediately any time the player's position is changed. Uh oh, game over.

I think a lot of it comes down to the likelihood of you being able to gain benefit from the extra getter/setter code. If you know you're never, ever going to hook something off of it, perhaps getter/setter pairs are overkill. If you're prototyping, it can slow you down unnecessarily. Otherwise, they can be very helpful. Sure, they don't do anything fancy *now*, but they may later.

But really, a lot of it comes down to language limitations. One language that handles this *really* well is Ruby. Consider:

Code:

class Player
  ...

  attr_accessor :x
end

player = Player.new
player.x = 333

The "attr_accessor" creates magic getters and setters for you.

And to top it off, say you wanted to implement a cache? Then, without changing the code that uses the class, but just the class, you can do this:

Code:

class Player
  ..

  def x= v
    @x = v
    dirtyCache
  end

  attr_reader :x
end

player = Player.new
player.x = 333

It's very neat, but guaranteed to send people who don't think much of operator overloading into a violent fit. I consider this a pleasant side effect.

By that point I kind of disliked this girl. Why am I chasing her?

I felt this way too. By the time I'd reached screen three I was looking for the "she's obviously not interested, check out her best friend instead" option.

As a suggestion, would it be possible to give the option at least of moving a bit more quickly through the village?

We tried this, but it wrecks the feeling of spacial relation. We also tried to fully take away player movement and just make ut possible for the player to cycle through characters, but this was just awful as for the whole 'adventure' experience.
But maybe we could crank up player speed a bit.

Ah, I thought it might be a realism versus playability thing. Never a good dilemma to have to resolve. :}

Here are a few random suggestions:

- Leave speed exactly as it is, but give an option somewhere to speed up time. This would increase both your speed and the speeds of any other moving entities, so that it is very obvious that you're not moving actually faster, but time is moving more quickly. The standard single triangle and double-triangle pairs are pretty well understood, if these icons were in one of the corners, people would get curious and click them when they're at the point where the walking speed is starting to frustrate.

- Implement mouse clicking to make the character automatically move to the chosen point. Double-click and it just jumps you there, skipping time. You still need to go up to the person/location and hit space to talk, but you've got this movement option available too. Maybe even double-clicking starts the dialogue. The downside of this is that this isn't really a mouse-driven game, and you might not want to add it.

- Implement an option to cycle through characters as you've mentioned, but make it entirely optional. The default is normal movement, but you can hit a key or click a button to call the option up. One possible advantage is that you might have written most of the code for this already.

I hope that one of these proves useful.

When the day ends automatically it makes you wonder if you've lost health for not getting inside in time. If the player shouldn't go to bed early, I imagine it would be better if still could visit their house, but get a message saying why they can't, or that they've still got time.

That's actually a pretty good solution. We're going to think about implementing this one.

Happy to have been able to help.

Okay, that was a lot of fun. It took a few shots to figure out the mechanics, but I found myself replaying over and over, whether I'd won or lost.

Just to check: There's no way to skip a move short of using your special, is there? I assume that is part of the challenge?

EDIT: So... addictive... can't.... stop.... playing...!

Okay, I finally got a chance to try it out on a Windows system. I was using roughly the same version of Firefox and Flash, but on a Windows box. I could properly control my character this time.

What an interesting game.

One suggestion I'd like to make is with respect to how quickly the main character moves. Whilst it's probably realistic that it takes a few minutes to fully walk through the village, it's very tedious to actually do this. The most interesting and fun part of the game- the dialogue- is only accessible by slowly walking around the village. The process of walking to your destination (or worse, trying to find a specific person) is actually incredibly dull. I often found myself thinking "too far" when playing, and just picking the next closest person to talk to.

Whilst I really want to play it again and experiment with talking to different people to see the results, the prospect of having to spend so much time walking around is sufficiently offputting to make me not want to do so.

As a suggestion, would it be possible to give the option at least of moving a bit more quickly through the village?

On another note, am I right in saying that you can't go home early on the first two days? It's a bit confusing when you first play, and are told not to stay out too long, but you have no way to return home early. When the day ends automatically it makes you wonder if you've lost health for not getting inside in time. If the player shouldn't go to bed early, I imagine it would be better if still could visit their house, but get a message saying why they can't, or that they've still got time.

I hope my feedback is useful.

I'm sorry to say that it's completely unplayable on my system.

That sucks. We haven't encountered any problems regarding controls so far (except an IE issue with scrolling of a window when pressing up/down).
We don't use linux, so I'm afraid we can't test on it. I'm afraid that's the problem.   

Hey, thanks for letting me know. I always end up feeling like the bad guy when all I can offer as feedback is basically "doesn't work for me". The game does look very interesting though.

Cute game, but a couple of issues that together detract from the game somewhat:

- Doublejumps seem to occasionally not work. I haven't figured out the precise reason. This means I can be skipping around, and suddenly just drop into spikes when I definitely hit the key to jump again, but nothing happens.
- When you die, you lose everything, and have to start again.

Put the two together and there is a serious problem- random, uncontrollable deaths that force you to start again, forcing you to replay the same section, over and over.

I stopped playing after getting a several of these unfair deaths in a row. It ceased to be fun repeating the same sections over and over, only to be cut down for reasons I didn't understand.

Perhaps consider allowing respawn without a complete loss of abilities and items?

PS. I was also unable to click to start the game, but "X" worked for me.

It looks like the sort of thing I might enjoy, but I was unable to play it due to the controls responding strangely. The option to hit space to continue tended to take a long time to appear, and it tended not to notice some presses of the space bar. Moving around was almost impossible. Sometimes pressing one of the arrow keys moved you a little, sometimes you moved on the spot, and sometimes suddenly jumped across to the next person in line. Sometimes not. I've got no idea how the controls are supposed to behave, but they aren't behaving on my system at all. I'm sorry to say that it's completely unplayable on my system.

I tried these two configurations:

Firefox 7.0.1, Flash 11.1 r102, Debian Linux 6.0.
AND
Firefox 12.0, Flash 11.2 r202, Debian Linux 6.0.

The second set is the latest available as of today.

[might]

Fifth, I'm not sure that the theories are necessarily controversial, nor do they deserve to be labeled as such so broadly. If you think this is justified, I'd like to hear what exactly makes the theory that Nix and Shelby were probably taken down by the same party controversial in any way.

In any case, they are just theories, based on the extremely limited information we have at hand. I'd rather get my ideas out there early, to get people thinking and talking, rather than remain silent and risk losing information that could be useful if I meet an untimely demise. Given two more nights, we would probably have better information, and better theories could be put together. However, we could potentially be down six people (one at the end of the day, two at night, per day) in this time! So I'd rather not wait. Even if every single theory I have come up with turns out to be completely wrong, somebody with more information or better ideas than myself might be able to apply it to what they know, or build on them in some way. And if one of the theories is right, well, we've made some decent progress at a very early stage, and might have a crack at prevailing.

And as much as I don't like it to say it, your theory that I might actually have been deliberately left alone last night because of what I've been saying is sound and should definitely be considered as well, now and in the following days, and particularly if I end up getting killed. I'm not sure how likely it is that this actually happened, but it is definitely possible. However, if instead there is a guardian angel, as past literature tends to suggest may occur, and I was protected, then there is now one amongst us who can be reasonably confident that what I say presents some kind of threat to the forces of darkness in this town. On top of that, we've managed to deny them a kill, which buys us more time, and pushes the advantage back toward us. I'm sure you can understand why I'm hoping for this particular theory to be true.

As for the mention of ash- I don't know exactly what can be concluded from what we've seen, but I do get the feeling that it may end up being significant in some way, which is why I talk about it a fair bit. Yes, I can offer nothing concrete, but only God above could state anything about our circumstances with absolute certainty. All we can do is come up with ideas as to what might be happening, and act on any potential clues that we can find. I do get the feeling that ash may be one of these clues and should be watched closely.

As for eigenbom, I'd like to know if his exile is self-imposed or has forced upon him. This could be pretty significant.

the weirdest grossest stuff comes from germany or japan

Two countries with an international reputation for manufacturing excellence. Coincidence? I think not.

Life has a nasty habit of getting in the way of interesting things at the most inconvenient times. I hope that you're able to get through things and can get back into a position where you can work with interesting projects like this one again. Good luck.