mlutze/flixball

flixball's Issues

doc: create `style.md`

based on discussion in #17.

• when to use opaque enums
• perhaps how long defs should be broken

More precise error messages for config

Make tests for config parsing

Make most things in core `opaque` to force helper functions and keep API clean

• GameState #89
• Board

docs: create `innovation.md`

Somewhere to list and describe the innovations we've explored here:

• ANSI terminal stuff (moved to a community library)
• regional random
• hash-based sets and maps

Add config file

As discussed in #30.

Set up command line options

• --version
• --help

Discussion: Problem with repeated shooting

I think it will be an issue for the optimal strategy that you can shoot every tick. This means that you can hold a corridor completely. This can be solved by:

1. Not having boards with dead-end corridors
2. Not allowing players to shoot every tick
3. ?

Add license

Add tests for driver

Clean up driver

refactor: separate GameState and the AIs

Based on the discussion in #40

• Have a new opaque type AiInfo that is given to the AI function
• Define getPlayerMap and getTileMap on this type; this allows us to change the internals without changing the AIs
• This AiInfo type will hold a Board and a Map[PlayerId, Position] but can be changed
  This means that we are flexible in representation, stable in AI implementations, and GameState is exclusively there for game simulation

agree with this @mlutze? (Very open for a better name than AiInfo)

AI / map specification

I think it would be nice to have some data structure or class that makes it easy to convert from JSON to maps/strategies while also implicitly documenting the map/strategy. That way we can use the same data structure for parsing the object as for displaying documentation, and maybe avoid a lot of repetitive code for building a strategy from parameters.

Add some basic AIs

• random action
• search and destroy #54
• run away

Nice way to create a board

• Random generation
• Read from String

Command line options

Currently we have a minimal command line which usually doesn't do anything. What options should go in command line options, and what should go in a config file?

Fully connected:

• silent
• config
• log
• dimensions
• period
• seed
• replay

Other requirements

• mutually exclusive options
• dependent options

Add README.md

testRunBoard02 does not work

In testRunBoard02 the spinning players are invulnerable and cannot spin more than once, it seems 🤔

Decide on edge-of-board rules

from #97

Options:

• implicit wall
• wrap around
• death

JSON management

JSON is probably the easiest way to store log files and config files. I have a very basic implementation here: https://github.com/mlutze/flix-json

It would be sufficient for parsing the configuration files, since we don't expect them to be too long. But the log files could end up very large.

I think the easiest option for now is for the log files not to be "standard" json, but rather have one JSON entry per line, representing one game state.

Use "reasonable excuse" idea for unsafe functions.

Flix will be removing the @Unsafe annotation. I propose we change our functions that use@Unsafe to instead use what I call the "reasonable excuse" model:

We add a new string parameter in which the user has to explain why what they are doing is safe. E.g.,

def unsafeGet(excuse: String, o: Option[a]): a = match o {
    case Some(x) => x
    case None => bug!("This should never happen because: '${excuse}'")
}

Set up nightly tracking CI

Finish basics

• moving
• turning

Factor out ANSI stuff

And just depend on https://github.com/JonathanStarup/Flix-ANSI-Terminal

Design thoughts

Some assorted ideas about the code structure, etc:

1. We should just use the Coordinates type alias everywhere instead of separate rows and cols fields. Only very rarely do we actually need to unpack it.
2. Display should not know anything about the AI. I think instead of passing it a game state or a board, we should construct a DisplayBoard that contains the minimum information to display the board. This way the APIs stay separate.
3. It would be cool if AIs were combinable/composable. For example, I have an composite AI that tries AI1 35% of the time or else it tries AI2. Or if AI1 doesn't know what to do, we fallback to AI2. Maybe that's already possible.
4. The ugliness juggling states in Engine might be cleaned up with either a monad or internal mutability. Probably not internal mutability though because then we'd need a mutable GameState, I think?

@JonathanStarup comments?

Game modes

Now that we have some basic AIs, I think we should consider alternative game modes. We can probably take ideas from classic shooters:

• Capture the Flag
• Area control
• Kill everyone
• Zombie mode

These will require a few more game mechanics.

• Score tracking
• Teams
• Respawning
• Ending the game
• Time tracking

And possibly:

• Health
• Fog of war
• Team communication

Add rotation dimension to pathfinding

Related to #4 and discussion in #54

The shape of AiState

AiState's definition is this:

pub type alias AiState = (Int32, Map[String, String])

where the Int32 part is for easy counting, etc. and the Map part is for arbitrary storage.

It's kind of weird to have a "int part" and "everything else part".

I propose instead the following:

pub enum AiState {
    case Value(String)
    case Collection(List[AiState])
}

This makes it a simple enum and conversions to most types come quite naturally. I was originally considering a JSON style but all the types add unnecessary complexity. We lose some guarantees in the conversion for integers, due to malformed encoding, but that was always going to be a potential issue with anything nontrivial anyway, so I don't have a problem with just falling back to some default value in this case.

Serialization of this is also very easy, as we can just do, e.g. a Lisp Syntax.

`Board.players` and `Board.playerMap` should be merged

returning List[(PlayerId, Position, Direction)]

Submit for community build

Draft an initial release

refactor: add a Core folder

Add a folder for everything in the Core namespace and give the nested AiInfo/Board/GameState namespaces their own files inside that.

@mlutze [Y/N/postpone]?

Basic game mode

See #56

Basic "kill everyone else" mode. 1 life per player

• track and display step/time limit
• detect when one player remains

Set up release CI

Expand CONVENTIONS.md

Based on discussions in #81.

Style

• Line breaking in long def signatures
• Use of {...} in if-expressions, lambdas, defs, etc
• |> use
• Record syntax (#83)

Design

• Use of opaque enums

Documentation

• Public members (functions, types, etc) must have documentation comments
• Nontrivial private members must have documentation comments

implement smart search and destroy

Related to #4.

algorithm

• go to the nearest tile where another player can be seen (with the new predicate on goTo)
• shoot

Add CI

pull `runBoard` out of `Display`

I think the main way to run things should just be some function that returns an Iterable of GameStates.
Then we can pipe that into whatever we want. Usually it would be a display, but it could also be run headlessly or logging each state to a file etc.

CI use scripts from flix-action-templates