Turning Ninth Age into a computer game/simulation, with AI

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

The latest issue of the 9th Scroll is here! You can read all about it in the news.

Our beta phase is finally over. Download The Ninth Age: Fantasy Battles, 2nd Edition now!

And on December 24th, Father Chaos brought us... A brand new army book for Daemon Legions!

  • Turning Ninth Age into a computer game/simulation, with AI

    A lot of speculation has been done on the topic of game balance in Ninth Age (of various types).

    The problem with speculation is that it is a tough prediction problem where opinions have free reign and facts are hard to come by :wall: . Playtesting takes a long time, small sample sizes are an issue, and playtesting cannot be used to explore design space quickly and accurately.

    A possible solution would be to implement an open source digital version of the game (or a suitably close approximation to it, e.g. using a discrete grid for unit positions), along with a game AI with an easily extensible, hackable set of strategy heuristics. Humans could play against the AI to confirm that it has at least some minimal level of skill, and then millions of games could be run on servers to explore the strategy landscape, and output (for example):
    • a colored matrix of army matchup winrates, or a subset of that matrix (e.g. all elves)
    • a visualization of the internal balance landscape for a given army (how many strong list types are there?)
    • rankings of the most and least useful units
    • ...
    This would make design a lot easier. Balance questions could be asked and answered fairly precisely. People who thought their army was OP or UP could prove or disprove that assertion, and would either see the AI winning/losing with their army, or uncover a bug in the AI that could be permanently fixed and make future simulations more accurate.

    So what I am asking is whether anyone has done work on such a project, or is interested in doing it? Does anyone have any thoughts on what kind of existing software is out there that could be leveraged? Are there any real showstoppers to something like this, other than time and skill?

    Obviously this would be a very, very large undertaking, but it would be a learning experience and a fun side project (good for the CV!) even if it failed. I suspect we have quite a few software professionals among our number.

    It would be too much work for one person to complete, but a core team of two could probably come up with the overall design philosophy, and build the code in a way that made it easy for others to work on specific parts - AI design could be decoupled from the game engine via an API, automated analysis of game results could be decoupled from AI and the game engine via logging, design of automated tournaments/automated list selection would be decoupled by having a MetaNinth simulation program that was at least somewhat agnostic about how the game engine, AI and data analysis worked.

    Compare the amount of effort/person-hours that smart people have wasted arguing about balance without good data to the amount of time it would take to get good data. We may already have spent more time - even more programmer time! - (if you count everyone involved) arguing about balance than it would take to write this simulator.

    I work in data science and enjoy R/Octave/Jupyter+Python+Pandas, have some Python/Flask web dev experience, though lately I have been working with Java in a fairly large corporate codebase.

    Please post any thoughts below.

    The post was edited 2 times, last by Warboss_R'ok ().

  • Ozariig wrote:

    If the project is organized to facilitate easy contribution from community members (github repository, pull requests, some kind of collaboration tool like Slack) I could see myself contributing a few spare hours to this project. I think it's a good idea and could be well worth the effort.
    Cool.

    I already did some work in this direction in a big, ugly excel spreadsheet - no movement phase, just simulated combat. @flam Called it the "Hospital average temperature spreadsheet" because he thought that without a movement phase, it was as useful for thinking about balance as the average temperature in a hospital is for trying to diagnose a patient. I thought that was hilarious and I'll never forget it! :lol:

    Being serious, I think at this stage the problem is to work out what tools, languages and frameworks one should use. Bad choices early on can multiply the amount of work by large factors - like 3x - 10x.

    One way to proceed with such a daunting task would be to just replicate the functionality of the "Hospital average temperature spreadsheet" (Just combat, random pairings, no movement) in some kind of modular way, with all the infrastructure for running thousands or tens of thousands of army pairings. Perhaps work out how to consume data-files from the army builder programs, maybe try to make some tools for volunteers to convert simple special rules (e.g. parry) written in natural language into some kind of computer readable format, which could then be automatically interpreted by our game engine.
  • the core mechanics of this game aren't challenging to code. I've already months ago made matlab code to do your "hospital average temperature sheets" and have note recently applied it to the magic phase.

    So special rules/ basic mechanics are easy. It's the movement phase and AI and lists i think will pose the biggest challenge.
    “You can never know everything, and part of what you know is always wrong. Perhaps even the most important part. A portion of wisdom lies in knowing that. A portion of courage lies in going on anyways.” -Lan Mandragoran, EotW


    Dovie’andi se tovya sagain.
  • nicreap wrote:

    the core mechanics of this game aren't challenging to code.
    Yup, the core combat mechanics are very simple, implementable even in Excel.

    nicreap wrote:

    It's the movement phase and AI
    Yeah, the movement phase will get fiddly. The biggest issue I see is the combination of movement and AI. Planning algorithms over a continuous space of strategies (if you allow units to have arbitrary positions with floating point-level precision) will be hard, but making the inherently continuous space of the tabletop discrete will also be problematic. There will be problems with detecting collisions and constraints, especially constrained movement.

    We could consider implementing an approximate movement phase before trying to go the whole hog. Something like not worrying too much about closing the door for charges (so units could fight just by touching each other), not treating movement as occurring along a path, but rather treating every unit as if it is flying - if you have the movement range to get to your destination, and you can fit, you arrive. Maybe even start with units being point particles.
  • Pellegrim wrote:

    Isn't a reasonable symeyrical system like chess already a nightmare to program?
    No, you can easily write a basic chess simulator and basic AI for it using tree search, a scoring funtion and alpha-beta pruning on the game tree.

    What makes warhammer hard is the movement phase, especially all the constraints about how a unit is allowed to move, how it isn't allowed to touch stuff, and the extremely large space that an AI has to search through as a result of a continuous set of possible positions and paths being available.

    Moving a unit in warhammer is a much more complex affair than moving a chess piece.

    Pellegrim wrote:

    with multiple kits each
    The kits are not the hard thing - they are already somewhat digitized in army builder files. Special rules that affect movement and combat will present a challenge, because that means that the core game engine has to be written to be extensible in a very clean and parametric way - so that it can be updated about a small change to movement by editing an XML file rather than rewriting the core code.

    The post was edited 1 time, last by Warboss_R'ok ().

  • Pellegrim wrote:

    Yes ok. So has anything like this been done? That be a good starting point maybe?
    Well, there are a lot of turn-based games that have AI, and some of them are open source, e.g. freeciv. The problem is that I think our movement system, with units having an infinite set of possible positions but also some very strict rules about how they have to move might be unique. If anyone has any leads on whether someone has done this before, please post them.
  • Warboss_R'ok wrote:

    Well, there are a lot of turn-based games that have AI, and some of them are open source, e.g. freeciv. The problem is that I think our movement system, with units having an infinite set of possible positions but also some very strict rules about how they have to move might be unique. If anyone has any leads on whether someone has done this before, please post them.
    I'm not sure about this part. Total war let's the computer move armies, almost freely barring some restrictions, and it allows the units on the field to function independently, and smartly enough to seek things like flanks and rears if possible. So I think it is doable, it's just getting that framework laid out.
    “You can never know everything, and part of what you know is always wrong. Perhaps even the most important part. A portion of wisdom lies in knowing that. A portion of courage lies in going on anyways.” -Lan Mandragoran, EotW


    Dovie’andi se tovya sagain.
  • nicreap wrote:

    Total war let's the computer move armies, almost freely barring some restrictions, and it allows the units on the field to function independently, and smartly enough to seek things like flanks and rears if possible.
    True, though they are solving a slightly different problem. Total war movement/collisions are a bit different than the warhammer movement rules. It is entirely possible for a unit in warhammer to just not be able to get from A to B, for rather complex reasons. E.g in the following diagram, the unit is trapped because obstacles have railroaded it and prevented it from turning into a large open gap that it could fit through.



    You need a planning AI to deal with this (in full generality), whereas something like TW: Warhammer AI probably just sends the unit towards a point, and troops bump into obstacles and get pulled around them. TW: Warhammer units are slippery, flexible objects, real warhammer units are rigid geometric shapes.
  • Something which helps reduce complexity is that the game is played a fixed number of turns, not until a victory condition. One of the things that makes Chess hard is having to plan dozens of moves in advance. Each unit in T9A doesn't get dozens of moves.

    That said, each turn features a lot more moving parts that are going to interact with each other, which increases the difficulty substantially.

    If at all possible, the AI should be written to read from a text file key parameters that affect its behavior. The community can then try its hand at finding good AIs. This requires AI programming define the space of parameters for AI, not optimize its behavior on specifics.
    Just because I'm on the Legal Team doesn't mean I know anything about rules or background in development, and if/when I do, I won't be posting about it. All opinions and speculation are my own - treat them as such.

    Legal

    Playtester

    Chariot Command HQ

  • There are several parts to this project that could be worked on nearly independently.

    Going back to thinking about frameworks and technology, if one of our sub-goals is to make a "rectangles taking turns crashing into each other in a 2D space" simulator, I would lean towards Python, Matlab, or other such languages with strong statistics features for making a test harness, extracting results into a nice report, and running hundreds of thousands of simulated tests. I imagine that there are lots of good choices here; I'm partial towards Python because it's what I used in school, but I'm nowhere near to keeping up with the bleeding edge of such things. I'm happy to pick up something new.

    By the way, I don't see any large concerns with finding fast-ish algorithms for collision detection of arbitrarily rotated rectangles: gamedev.net/resources/_/techni…rectangle-collision-r2604

    I understand that getting an AI to use this algorithm when planning its moves might be tricky, though.

    If the goal is to someday allow humans to play against the AI, I would tend to want to implement the client for the game in something like MonoGame.NET or Unity. Again, I'm nowhere close to the bleeding edge, but I know from my limited experience that MonoGame.NET would give all the control we could ever want for hooking up the same AI that we use in the test harness, and that distributing such games is fairly painless.

    To me, the heart of the project would be in making an API that exposes the rules of the game. If I were doing this, I would probably start here, because if it's done right it could offer benefits to many other parts of the T9A project as well.

    What you don't want to do is have to spend a dozen hours after every rules update parsing the new rules and performing data entry in order to keep our test harness up to date.

    The ideal situation to me would be to let the rules API become a driver for all other parts of the project that rely on the rules (e.g. battlescribe, the rules lexicon on the website, even the PDF files), and find a way to make it easy to edit and version. That way, the rules would only need to be updated in a single place and a lot of volunteer time could be saved across all the various releases.
  • Nicklz wrote:

    I don't think the game looses to much by quantizing rotations to eighth of a circle. This should reduce the complexity of a movement phase.
    It's possible, but there will be all sorts of problems with movement and especially charges becoming impossible when they should be possible. And the "Can I get from A to B" problem is still hard.

    Ozariig wrote:

    I would lean towards Python
    Yeah, I would also lean towards python, because I like the language and it is very popular with a lot of libraries. I would expect that there is probably a library for most of the stuff we need, including primitive 2D graphics (Unity may actually harm us because it might be geared towards 3D games - which we certainly do not want). E.g.

  • I'd certainly love to involve here.
    I'm doing Phd in Computer Science having specialized in computer games (some projects done) up to master and right now I'm doing my research with neural networks and alike. Working with python, c++ and obviously any higher level language is rather easy to incorporate in such task. I could envision extension using Lua as probable.
    Surely such long-term project would be great to delve into. I thought about it by myself but have not really realized that there might be others with similarly useful skill set and willing to proceed :)
  • Maybe instead of simulating (very difficult for the movement phase) it may also worthwhile to consider improving collecting data of played (UB) games.

    As an PhD in computer science specialized in Maschine learning i can tell you that having good training data is key to get any sufficiently effective AI up the ground. So better collecting real data can be seen as precondition for any further more fancy approaches.