31–36 of 36 posts
I know this is kind of beside the point, but my response would ne pretty simple - I've never played Monopply, and have no idea of its structure at all.
http://news.ycombinator.com/item?id=2063092
;-)
What if your candidate isn't familiar with Monopoly because, say, they didn't grow up in the west?
Perhaps hand them the rule-sheet?
No one here or on the original page seemed to consider they should design a Monopoly game on the net to be "fun." Especially since Hacker News is about and for entrepreneurs, it would seem natural to turn an idea like that into money. Monopoly is a game. It should be fun. It had better be fun, or the design doesn't matter because it won't sell. What makes the game fun? Part of it is the interaction between players, l…
This was exactly my immediate reaction, but mostly because I never really found Monopoly to be all that fun in the first place. Instead, my friend and I pooled together our monopoly dollars and made a monopoly casino. There's not really a good digital equilvalent to this, but that's the tricky thing about monopoly: the things that set it apart from other games are the hardest to transfer to a digital analogue. This r…
When I'm only doing average or not so well as I want to let on I make sure I have my 1000s on the top of a large stack. When I'm clearly leading I spread all my money into individual stacks so that people can clearly see that I'm far in the lead. The same goes for properties. Especially when I have stuff built on them. Anything with the most value is up in people's faces unless I'm slightly behind the curve where I obfuscate what I have to not seem a threat. (Games of monopoly often turn into horse trading in the late stages.)
Translating that online would be hard. Fun but hard.
Monopoly is not just an external entity, it's a pretty big one with tight cultural ties. If the candidates you interview were not born in the same country as you, the best case scenario is that they played Monopoly in a different language and the worst case scenario is they never played it.
I prefer to focus my interviewing on questions that rotate around pure coding (if that's what the candidate is interviewing for) and even then, I hardly find the time to dig as deep as I'd like.
What I’m about to say will be blindingly obvious to the Enterprise crowd...The rules must be considered as carefully as the entities. Enterprise developers have known this for years: that’s why you see rules engines, table-driven designs, and visual workflow editors in many Enterprise applications. What a refreshing statement at a time when we're bombarded with so many annoying "SQL is Dead" posts. Try designing an e…
May be completely besides the point, but my first OO instinct upon approaching the question is to model rules etc. as objects themselves. Only the most naive OO modeler would think that OO objects must be nouns within some physical analogue of the system - to my mind, anyhow.
Earlier quoted context omitted.
May be completely besides the point, but my first OO instinct upon approaching the question is to model rules etc. as objects themselves. Only the most naive OO modeler would think that OO objects must be nouns within some physical analogue of the system - to my mind, anyhow.
Why would you want to do that? They have no state. You're almost never going to do anything with them except invoke them from specific places. This sounds like complexity for its own sake.
Secondly, rules do have state, in so far as one rule is distinct from another. Perhaps a rule has preconditions (which could be represented as a binary tree and evaluated through recursion) that must be true before the rule is "active". Perhaps rules have effects, a list of state changes that they impose on the rest of the game world. You could model these as functions, or alternatively again as trees, evaluated through recursion. If the rule system needs to be flexible enough, they could be serializable and deserializable from a text or binary format.
If the game is a simple one, with a fixed set of rules that never change, there's little need for this. But if you look at a game like Monopoly, there's a lot of complexity that comes up in real-life games that isn't so simple to encapsulate in rule lists, such as making complex deals, haggling, borrowing money from other players, even receiving charitable donations from other players to prevent the game ending prematurely.
Move further into business rule systems and the need for flexibility increases again. I've architected systems which needed a generic rule-based system for data validation and workflow transitions; and these rules had themselves rules for when they applied, as older rules needed to be grandfathered in to older data, but expired for new data.