Ohh

It's hard for me to tell quite what's going on but it looks/sounds like it could be really cool. Gonna upload more anywhere?

I think the rules are that each colour has a reaction to each other colour:

Red likes green, dislikes red

Blue likes green, likes blue

Green likes green, dislikes red

I think that's all the rules, but I'm not totally sure. Anyway, enjoy!

I don't think I would personally play this game if it was much longer. Although I enjoyed them, levels 5-6 were pushing it a bit -- they didn't offer much different from level 4.

The game is very cute and solid! I liked how trees ended up being a very useful and necessary tool. My gut said they were just gonna be obstacles and I was glad to be wrong.

neat idea! are you planning to revisit/expand this at all? it's pretty hard to read what's going on right now and there are some little ui changes i'd love to see (for clarifying what's going on, but also -- it'd be really nice to have a tiny queue that at least shows what's coming up next so I don't have to think about my next move from scratch every time. i find it pretty mentally taxing!)

yikes, okay! mac build should function properly. working on a solution.

hello this is a comment on asphyx

hello

droqen // burial young apex agile

Oops, I messed a bunch of stuff up. I set up a system for keeping an in-development & unstable version of fiefs separate from the public-facing one but, silly me, i completely forgot to actually take advantage of it, ha ha ha

This version of fiefs is grossly incomplete, but I have implemented jump code peeking (unlike the passwords of olden times, jump codes are not reset when you look at them... yet. it might be worth making those separate actions.)

One of the largest design changes is that scouty is no longer a separate action & actions don't have their own range score. This may turn out not to be fun? But it makes interacting with the game a lot easier. Hex/node names can take a backseat now.

2016 June 9th -- fiefs has been reset for new hex-based system. currently wondering: should stored lore (information discovered -- in old fiefs lingo, stuff like passwords) be bound to a home node or to some kind of external player account?

2016 June 13th -- droqen # bliss space smoky expand

http://php.droqen.com/fiefs/
> fiefs ? do=login & un=ungouk nebra & pw=trim rotten differ gender

alright. i'll be implementing & experimenting with node relationships - each node keeps track of how much it "likes" or trusts each adjacent node.

when you jump into a node, it gives you a trust rating based on the node you came from.

naturally, there will be progs that affect these trust ratings! i'm thinking of calling the basic one CHARM, letting you improve your trust rating from afar?

hexagon report:

oh wait i understand what you're saying now!! That sounds neat. Maybe there is some kind of pass codes and knowing more unlocks more capabilities

Maybe little 2x2 groups of nodes? hmm but right now there's no real notion of who controls something or not. I guess it could be a power-channeling thing?

it probably wouldn't be! i just tried and it got on my nerves not being able to make the grid... perfect...

i'll give it a go.

I pretty much have three options here:

• Keep using taxicab geometry (every node has 4 neighbours, and a 'circle' is a sort of weird diamond shape. easy to program and neighbour overlap is easy to understand!)
• Switch to a hex grid (every node has 6 neighbours, and visually it's quite pretty -- if difficult to program in css)
• Stay on a square grid, but include diagonal neighbours (every node has 8 neighbours, and a 'circle' is basically a square. neighbours overlap a lot and this makes it very hard to make 'walls'.)

Nodes could potentially have "jump ranges" as well that allow you to jump a longer distance -- rather than only letting you jump to adjacent nodes. Most jump ranges would probably be 1-2, and almost always >0. A node with a jump range of 0 could be interesting, though...

Parameters

RANGE How far away can your target be?

"0" only hits own node; "1" hits adjacent nodes.

AREA What area does this prog cover? (Originally only used for Scouty)

"0" only hits target node; "1" hits target & adjacent nodes.

POWER Effect varies by prog

ACCURACY % chance of success! Calculated separately for each target. I'm thinking low accuracy is most common on progs with AREA > 0, but I could see it appearing on a very weird / powerful single-target prog

COST How much node energy (how many 'moons') it costs to run the prog

Progs (non-final name, stolen from 868-HACK)

SCOUTY Updates the node's internal map with the current state of whatever nodes it hits.

Not sure what information scouty should learn, but there should definitely be timestamps on the map so you know what's out of date!

BREAKR Reduces target's shield by POWER

MINWAL Increases target's shield to POWER if it's less

GETJMP Learn target's jump code // replaces the old prog whose name i forgot, the one that let you reset a password

New Progs

SETJMP Set target's jump code

I want nodes to feel like bigger places! To encourage that, I'd like for multiple players to claim ownership over a node and to be able to fight over its control. I'm not totally sure how to do that.

Having to log into every node using a password is extremely clunky and awful! Instead, I'm going to define certain nodes as entry nodes, and these ones have master passwords. You can log into an entry node from anywhere.

The only way to log into non-entry nodes is to jump to them from an adjacent node. So I'll call them jump nodes, even though you are allowed to jump into an entry node.

A master password will continue to be something like 'dog erroneous waterfall end'.

A jump code will be one word, or a short number. Something like 'din' or '419'.

Because I've generally been against tracking player accounts, I was having trouble -- I wanted shorter passwords, but I didn't know how to prevent brute force attacks!

Now, it's simple: a brute force attempt will be punished by temporarily blocking the jump path. If you're attempting to guess a node's jump code from an adjacent node, you only get a few guesses -- somewhere between 3 and 10 -- and if you hit that maximum, the destination jump node will block jump access from the source jump node for a period of time.

Alternatively, the punishment can involve your entry node (which are now rarer and more valuable! you really don't want someone getting into your entry node), or some sort of energy cost for attempting a jump (and failing?).

http://probability0.wikia.com/wiki/Probability_0_W...

I made a barebones P0 wiki years ago and it's been totally filled in with gifs and descriptions and all the good stuff by Mystery User Psr12. I'd love for it & all their hard work to get more views!!

See first post for details, but I calculated a Bare Minimum Estimate cost to me: $5/month, $60/year. (per player)

Or looking at it a different way: $2.50/letter, twice a month.

Would you pay that much to try a play-by-mail game? ;p

(... also I basically have not been thinking about $ stuff until now, but all the design stuff is kinda ephemeral and I don't know really how to put it all down!)

👍 Also this definitely works!

It could also be twisted more loosely, based on the more specific definition of "The game requires careful exploration of the dungeon levels and discovery of the usage of unidentified items. This has to be done anew every time the player starts a new game."

Unknowns are fine as long as they're not too similar to unidentified potions or random dungeons? Discovering reliable properties or emergent events are still on the table. "Not exploring" a landscape could mean you have a map, or something.

Then again, given that there's no grid and low complexity, there could be no map at all...

maybe even what makes games compelling.

I think the direction I'd take is to just steer clear of the kinds of exploration & discovery that roguelikes exemplify. No resource-limited exploration of nooks & crannies for items. No random items with testable properties. No... item identification in a mechanical sense. But surely no game can survive without discovery, just as no game can survive without complexity.

Wrote this while reading the blog post.

Having come to the end, it was a really good read! The No Berlin Roguelike will probably take form very slowly (well, mine anyway) b/c I'm working on other major stuff... but I have yet more to chew on now.

I guess when I say ARG, I don't mean... the traditional mechanics of ARGs, more like, pretending to exist somewhere in the real world.

I almost called this game "wax seal", but I wanted to leave things open.

The way that I expected to run the game was going to be, I think, primarily mechanical with *some* narrative, with players managing something from a distance.

One of the concepts I had been considering was:

--> Each player is an orphaned child of a king, a queen, or some other noble, sent to live in safety in a distant tower. They can't go back home because their country is in turmoil and they have too many enemies there, so they rule from afar, vying to make their country safe for them to live in again (but also, every other player has their own country, and if your country is overrun... well, you'll have little to return to).

I had only idly been thinking of ARG-ey-ness. It'd be cool, but limiting?

I'd be interested to hear (as usual) what people think - do you want something ARG-ey, or is it okay if it's more clearly fictional?

edit :: posted this before i read ploogle's post! that sounds cool! getting report cards :)

oh wtf james i thought you were already up there! my bad 0:

Physical tokens. I can't imagine any other way to encourage physical mail!

Even if the schedule is fairly regular, there will probably be some variance as a natural result of something as chaotic as the postal system, no? It's definitely fun to think about certain events triggering special reports though... surprise letters! A break from the schedule!

I could encourage people not to share any online handles/information, but there's also the problem of players knowing one anothers' addresses o_o; a little worried about troublemaking there...

other than that, though!

Maybe allowing for some crossed wires isn't a bad idea! Players can send letters whenever they like, but I only send reports at fixed intervals...