jkomoros / boardgame Goto Github PK

Like precisely which card was actually drawn--the information necessary to actually have enough information to apply the move clientside.

Will need to keep this separate somehow from information necessary to PROPOSE a move. Maybe with struct tags (ick!) or with a Complete() method that returns true when all of the required fields to propose a move are complete. Or a sub-struct that has state after its been set?

This will test out hidden states, much more components, much more stack manipuatlion

The first step to being able to play around with the logic of a game and make sure it works OK.

Likely on delegate. This is a method that will check to see if based on the state, the game is over. And if so, who won.

For example, we should be able to have a tool that outputs the Prop/Props/JSON/GameName basically automatically given the name of the Move object.

Currently it requires you to remember all of the states to set, which when you add a field is brittle

PlayerMoves is the set of all moves that Players can ever propose. MetaMoves is all other moves--things like FixUps. This makes it easier for e.g. cli to enumerate only the moves that the user likely wants to apply, while still allowing them to propose the other moves if they really want to.

Question: is every MetaMove a FixUp move? Do FixUp moves make sense to apply IFF their Legal() returns true for a given state?

Originally captured in #45

Likely stored in State.Payload.Components (in addition to Games, Users)

Just removed it from move, might be last thing that used it

Just have it configure an ASCIIRender func that takes the state and returns a multi-line string?

If it's too long to fit, figure out how wide the longest string printed so far is, give a few spaces of padding, draw a | line, and then render the rest. Repeat.

We want a way for Game or CLI to be able to enumerate moves, ideally with a description, and create a new one.

One way is to have all Moves have a Copy(). So we keep a list of instainiated base moves of all of the types, and when seeing which ones are legal, we go through and Copy() them. Then they can all have a Description() and Name() field, and InitalizeWithState(payload) on them.

Another approach is to have game just have a list of functions that take a state payload and return an initialized move or nil if the game state doesn't permit one to exist. Moves could still have Description() and Name(), and then we'd only be able to list ones that were at least vaguely plausible at that state in the game.

The latter seems cleaner, although there are definitely some instances when I want to enumerate all of the moves in the game, even if I can't do anything with them right now.

So maybe it's Move.Copy()InitForState(state) error. Where if it returns error that means it's not even conceivable right now (let alone legal).

... Is there a distinct concept of "Conceivable at this game state" and "Legal at this game state"? The former is only useful to the extent the move is not yet filled in with all of its fields yet, but otherwise is basically the same. Conceivable seems like it could be an albatross, because it's basically a bespoke version of Legal(), which will be finicky logic.

OK, so it's a list of instantiated Moves(). We can enumerate them for Name() And Description(). If we find one we like, we call Copy().DefaultsForState(state), which always does the best it can to set the properties it can default reasonably. (like TargetPlayerIndex == CurrentPlayer)

Necessary to fix #26

https://godoc.org/golang.org/x/tools/cmd/stringer

There are lots of Constants that are basically enums, so Stringer is quite useful.

Write now we have some interfaces that do things and at various point library users need to cast back and forth and do some weird implementations. Which things are structs and which things are interfaces is seemingly random, which makes everything seem pretty messy.

Another approach would be to do a code-gen approach with marked-up structs, like in https://github.com/go-reform/reform . This is very hard to get working and test, and seems like it could be very finicky. But it's worth considering an option.

The first thing is actually more the StateWrapper, and the inner thing is actually the State.

That just has no-ops for all methods. That way you can easily embed it in your struct and just override the methods you want.

It does editing and everything and layout. Might do more of what I'm looking for

https://github.com/jroimartin/gocui

That would allow JSON() method on many structs to just return themselves.

Not that that prevents dupes from being put in OTHER stacks, but at least it helps...

That takes the struct and uses reflection to pop the values out

If it's an interface, that allows a single cast in Legal, Apply methods to get all of the things typed in your generic type.

So we can inspect it. Viewing mode is JSON multi-page, or a way to inspect specific keys

Requires a way to map the right underlying Component.Values to the right struct

It's a stub that basically just tests the type hierarchy

Likely a method in Game Delegate

Will need to redo the jSONCompare function to just do something like https://gist.github.com/turtlemonvh/e4f7404e28387fadb8ad275a99596f67

But then lots of places shoudl be able to just return self and we're good

With arrow keys and with mouse wheel

A top-level expected type. That would allow us to understand the intent, and verify that it's never out of bounds (except for maybe -1 if it's no one's turn)

Plus a way in the CLI to view the state as particular users.

When iterating through names, only add to chest if their prefix matches a filtered phrase.

Deck.AddMultipleComponents.

Values would likely need to be a PropertyReaderCopier, and then the method would need to call Copy() on the value delegates

This will exercise a lot of the things that we're missing

It should be possible to call Finish() yourself, but when you put a Chest in a Game it should have finish called automatically.

I tripped over this for awhile writing 1bc56cc

Currently called FixedLengthStack in the explainer.

A normal stack, except that the length is always the same, and -1s are included in spots that aren't filled.

It's not actually used anywhere. And if it were, we'd likely just use reflection (which would require the fields to be public... or would it? Looks like you might be able to read).

It's theoretically useful in the Logic Engine to be able to read property values, but maybe we just do a State.ReadProperty(...name string) interface{}, which can just use reflection.

It's a lot of (weird) overhead to have until we actually need it...

At the worst we can probably remove it and then add it back in if really necessary.

So that we don't have to worry about people messing with the default copy. Right now if someone grabs a Move and doesn't copy, everything will get in a weird state.

That's basically just a two dimensional array of termbox.SetCell calls.

Would have to be in a separate package so that everyone could include it

Would have NewTermboxBuffer(width, height), a Size(), and SetCell.

Then a Render(x, y) which would render into TermBox.

This would allow more dynamic rendering in CLI render mode.

That install the various key bindings when the mode is entered. This will help rationalize the keybinding logic, which currently is very ad hoc...

Necessary to fix #26 (without going crazy, at least)

Sets the defaults for a move based on the current state. For example, it might set TargetPlayerIndex = state.game.currenPlayerIndex

Currently they just output {}, likely because their fields are private.

The first will need to rely on delegate.CurrentPlayer

For example, if you want to do a Renderer func, you can't print if the game is won or not, because the state object doesn't know. And legal methods on a move can't know if the game is already over.

It's probably OK to have it be special--renderer funcs can't show it, and legal can't know it, but the cli can render winning state itself, and ApplyMove will always do a check for the game being won anyway.