mlutze / flixball Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
returning List[(PlayerId, Position, Direction)]
based on discussion in #17.
In testRunBoard02
the spinning players are invulnerable and cannot spin more than once, it seems ๐ค
Based on discussions in #81.
{...}
in if-expressions, lambdas, defs, etc|>
useAiState
'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.
I think the main way to run things should just be some function that returns an Iterable
of GameState
s.
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.
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.
Somewhere to list and describe the innovations we've explored here:
Some assorted ideas about the code structure, etc:
Coordinates
type alias everywhere instead of separate rows and cols fields. Only very rarely do we actually need to unpack it.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.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?
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}'")
}
Related to #4.
algorithm
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]?
Based on the discussion in #40
AiInfo
that is given to the AI functiongetPlayerMap
and getTileMap
on this type; this allows us to change the internals without changing the AIsAiInfo
type will hold a Board
and a Map[PlayerId, Position]
but can be changedagree with this @mlutze? (Very open for a better name than AiInfo
)
As discussed in #30.
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:
Other requirements
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.
And just depend on https://github.com/JonathanStarup/Flix-ANSI-Terminal
See #56
Basic "kill everyone else" mode. 1 life per player
--version
--help
Now that we have some basic AIs, I think we should consider alternative game modes. We can probably take ideas from classic shooters:
These will require a few more game mechanics.
And possibly:
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.