Right now, when you accidentally reload you lose undo/redo state. Ideally undo/redo state is stored in an encoded form (MapData.toJSON) in localStorage and is therefore persisted after a reload, ensuring that players do not accidentally lose a map in progress. See the MapEditor component. It's also worth checking out the updateUndoStack function.

I suggest storing the undo state by mapObject?.id (or a fallback id if no mapObject is provided) so the undo stack can be per-map which will be on a different route in the game.

Additionally, when loading the map editor it has the ability to "restore" previous state, like from the last playtest. It should no longer be necessary to keep that feature separate, and instead the code should be cleaned up so that restorePreviousState just restores from the undo stack. This might need a fallback behavior so that it doesn't keep restoring the same previous map – or alternatively the "Restore Map" button in the MapEditorControlPanel should just be an "Undo" button after the first click (or after undo/redo is executed once). Open to ideas to ensure a good user experience.

Links

• Map Editor Playground

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

The Athena Crisis AI works by executing all actions for a turn and returning them to the user. It's critical for the AI to be fast. The goal of this task is to speed up the AI by 5-10x while maintaining its difficulty level. Ideally it has the same or stronger behavior, while being faster. All tests in this repo need to pass with the improved AI, however if a snapshot test changes while retaining behavior, that is acceptable.

AI Info

The current AI is called DionysusAlpha and its code can be found there. There are also many AI specific helpers in dionysus/lib. Check out the AI Playground.

Notes

• Choice of Tooling: The AI has to be written in JavaScript and be maintainable. This is not a code-golf competition or challenge about porting code to another programming language.
• Radius Performance: Improvements made as part of #9 will count towards that issue. If we find that there is a new performance lower-bound based on improvements to that issue, we may adjust the target of this issue down to make sure the goal is achievable.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

I'm interested in exploring the possibility of using reinforcement learning (RL) to develop the AI for this game. I want to know whether RL is a suitable approach for it.

questions:

Has anyone tried using reinforcement learning for developing AI for this game?
What are the potential challenges and limitations of using RL for this purpose?

Any insights, experiences, or resources related to using RL for this game AI development would be highly appreciated.

Many Map Editors feature symmetrical drawing modes. This task is about adding a symmetrical/mirror drawing mode for tiles, buildings and units. Here is how I imagine it could work:

Basic Modes

• Regular: Existing mode where only one tile is drawn.
• Horizontal: Each tile drawn on one side of the map is also drawn at the same location on the other side.
• Vertical: Each tile drawn at the top/bottom of the map is also drawn at the same location at the bottom/top.
• Both: Each tile drawn at one point is mirrored on both axes to the other side.

For example, with regular horizontal mode, on a map that has dimensions of 14x10 (width x height), drawing on field 4,4 it would draw on 10,4 on the other side (14-4). The "Both" mode would instead draw at 10,6 on the other side (14-4, 10-4). I imagine we may need a fifth mode that mirrors each field 3 times, so that drawing in one field will draw in each quarter of the map. For example, drawing at 4,4 would also draw at 10,4, 10,6 and 4,6.

The basic implementation as above should work for tiles. When a building or unit is selected, I think it makes most sense to rotate player/colors as more fields are drawn. Let's say I'm designing a map with pink (1) vs purple (5), with horizontal mode. The first unit would be player 1, and the second would be player 5. map.active can be used to determine the players. If the mode that draws on 4 fields is selected, and there aren't enough players on the map, I suggest doing something like new Set([...map.active, ...PlayerIDs]) and wrapping around that set while drawing.

Next to building this feature, the challenge is how to make the UX good and not confusing.

I'm not sure if there are any modes beyond this that could be useful, and I'm open to ideas.

Steps

• This task likely requires refactoring parts of DesignBehavior so that multiple positions can be updated at the same time, while still running all the tile, unit and building related validations.
• The buttons to select the drawing mode should be in DesignPanel. The state should be stored in EditorState.
• Multiple cursors likely need to be rendered to highlight every place where something will be drawn. Let's make all the mirrored ones red, and I can swap in another color later. This might be possible through MapEditor, but more likely needs to be done in DesignBehavior's component. If neither are a good option, it can go into the render function of GameMap by using editor (EditorState) and placing cursors next to the existing <Cursor />. This might actually be the cleanest option, but I'm not entirely sure without trying.

I can provide icons for the buttons. Feel free to just use any placeholders from ui/icons in the initial PR.

Note: The code of DesignBehavior is maybe less ideal than it needs to be in some places. I appreciate any refactors that bring clarity, any possibly even some extractions into athena/lib (or athena/editor/lib?) with added tests for mutations/validations, but it is not necessary for the completion of this task. I care about it not breaking, and this is one way of doing that.

Links

• Map Editor Playground

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

Once support for optional win conditions (see #17) is merged via #34, we can start building on top of the feature by adding a win condition to reach multiple optional conditions. This is fun because we can set up optional conditions like:

• Defeat unit by label
• Capture 5 buildings
• Escort 1 unit

And then define a win condition that requires reaching three optional conditions to win the game. Together with secret conditions, this opens up exciting possibilities for map scenarios where you might have to discover hidden optional conditions to win the game.

Code & Steps

This task is about implementing a new win criteria and condition called "OptionalConditionAmount" which should have a players and amount field (next to the default fields like reward and hidden). I believe that based on #34, this condition should also be possible to be optional, even though that might be slightly confusing when used.

• WinConditions.tsx for data structures and where to add a new win condition. Check out other win conditions that have an "amount" field. Ideally the validation for this win condition should verify that the number of optional conditions defined for the map is higher or equal to the "amount" specified on the win condition. For that validateWinCondition should be changed to take the number of win conditions of the map.
• checkWinCondition.tsx for checking whether a condition was meet. checkWinCondition should look for an ActionResponse of type OptionalCondition and then go through all win conditions to check if the player or any player within the team completed enough win conditions.
• PlayerCard to show how many optional conditions were reached by the team compared to the amount, similar to the other conditions that are shown there. Feel free to pick an icon from https://icones.js.org/collection/pixelarticons or otherwise use a placeholder and I'll make a fitting one.
• Please add a test to verify the win condition works as expected.

TypeScript via pnpm tsc should guide you through adding various pieces of code once you add the win condition.

Note: This win condition should be triggered if enough optional conditions are fulfilled by the player or anyone on the same team. Therefore the check in checkWinCondition should look for each condition's completed set and check if the player id match the same team as the player who unlocked the optional condition via map.matchesTeam(actionResponse.toPlayer, completedPlayerID)

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

PS E:\Documents\source\athena-crisis> pnpm dev

@deities/[email protected] dev E:\Documents\source\athena-crisis
cd docs && pnpm dev

@deities/[email protected] dev E:\Documents\source\athena-crisis\docs
vocs dev --port 3003

21:44:32 [vite] building search index...

[running] [email protected]

➜ Local: http://localhost:3003/open-source
➜ Network: use --host to expose
21:44:34 [vite] Pre-transform error: Failed to load url /@FSE:\Documents\source\athena-crisis\node_modules.pnpm\vocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq\node_modules\vocs_lib\app/index.client.js (resolved id: /@FSE:\Documents\source\athena-crisis\node_modules.pnpm\vocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq\node_modules\vocs_lib\app/index.client.js). Does the file exist?
21:44:35 [vite] Pre-transform error: Failed to load url E:Documentssourceathena-crisis
ode_modules.pnpm
ocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css (resolved id: E:Documentssourceathena-crisis
ode_modules.pnpm
ocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css) in virtual:styles. Does the file exist?
21:44:35 [vite] Pre-transform error: Failed to load url E:Documentssourceathena-crisisdocscontentstyles.css (resolved id: E:Documentssourceathena-crisisdocscontentstyles.css) in virtual:styles. Does the file exist?
21:44:38 [vite] Error when evaluating SSR module virtual:styles: failed to import "E:Documentssourceathena-crisis
ode_modules.pnpm
ocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css"
|- Error: Cannot find module 'E:Documentssourceathena-crisis
ode_modules.pnpm
ocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css' imported from 'virtual:styles'
at nodeImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56268:25)
at ssrImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56177:30)
at eval (virtual:styles:3:50)
at instantiateModule (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56237:15)

21:44:38 [vite] Error when evaluating SSR module /@fs/E:/Documents/source/athena-crisis/node_modules/.pnpm/vocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq/node_modules/vocs/lib/app/root.js: failed to import "virtual:styles"
|- Error: Cannot find module 'E:Documentssourceathena-crisis
ode_modules.pnpm
[email protected]@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css' imported from 'virtual:styles'
at nodeImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56268:25)
at ssrImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56177:30)
at eval (virtual:styles:3:50)
at instantiateModule (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56237:15)

21:44:38 [vite] Error when evaluating SSR module /@fs/E:/Documents/source/athena-crisis/node_modules/.pnpm/vocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq/node_modules/vocs/lib/app/routes.js: failed to import "/@fs/E:/Documents/source/athena-crisis/node_modules/.pnpm/[email protected]@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq/node_modules/vocs/lib/app/root.js"
|- Error: Cannot find module 'E:Documentssourceathena-crisis
ode_modules.pnpm
[email protected]@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css' imported from 'virtual:styles'
at nodeImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56268:25)
at ssrImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56177:30)
at eval (virtual:styles:3:50)
at instantiateModule (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56237:15)

21:44:38 [vite] Error when evaluating SSR module E:\Documents\source\athena-crisis\node_modules.pnpm\vocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq\node_modules\vocs_lib\app\index.server.js: failed to import "/@fs/E:/Documents/source/athena-crisis/node_modules/.pnpm/vocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq/node_modules/vocs/lib/app/routes.js"
|- Error: Cannot find module 'E:Documentssourceathena-crisis
ode_modules.pnpm
[email protected]@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css' imported from 'virtual:styles'
at nodeImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56268:25)
at ssrImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56177:30)
at eval (virtual:styles:3:50)
at instantiateModule (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56237:15)

node:internal/process/promises:289
triggerUncaughtException(err, true /* fromPromise */);
^

Error: Cannot find module 'E:Documentssourceathena-crisis
ode_modules.pnpm
ocs@1.0.0-alpha.52_@types+node@20.14.2_@types+react-dom@18.3.0_@types[email protected]_babel-plu_4v4obqvrv26uvzezrtpkgcatzq
ode_modules
ocs_lib
ite.vocs heme.css' imported from 'virtual:styles'
at nodeImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56268:25)
at ssrImport (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56177:30)
at eval (virtual:styles:3:50)
at instantiateModule (file:///E:/Documents/source/athena-crisis/node_modules/.pnpm/vite@5.2.13_@types[email protected][email protected]/node_modules/vite/dist/node/chunks/dep-DEPSZ3SS.js:56237:15) {
code: 'ERR_MODULE_NOT_FOUND'
}

Node.js v20.14.0
 ELIFECYCLE  Command failed with exit code 1.
 ELIFECYCLE  Command failed with exit code 1.

The map editor has an "Evaluation" panel that can be accessed by pressing v or via the "more" dropdown of the editor link panel. When pressing "Start evaluation", it simulates 10 games of the AI playing against the AI and displays the results. This runs directly on the client, and is a sync operation, which locks up the browser until it is done.

This task is about making this operation non-blocking, either by yielding more often or by running in a web worker. Both approaches will likely be changing useClientGameAction. The first approach likely modifies and extends executeGameAction to yield after an AI concludes a turn, so that the a game can be played by calculating a turn, yielding and then going back and executing another turn until the end.

A good way to test this is by making a very large map with many players.

Links

• EvaluationPanel
• Map Editor Playground
• Web Workers in Vite

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

The way many sprites are rendered in Athena Crisis will render most of the image, and then cut off everything around it using CSS. This is naive, but works great for most use cases with small images that change often. However, character portraits are about 320 kb in size, and there are 11 variants of them. Rendering many characters on memory-limited devices is not good. This issue is about exploring alternative ways to render character portraits, possibly by slicing them up and rendering them with canvas and drawImage. There are some examples in the Athena Crisis codebase as well, see renderTile.

Steps

• Find the Portrait component.
• Implement a new rendering strategy that avoids rendering the same large image each time a portrait is used.
• Ensure that you retain all functionality such as animating the portraits. Note that not all portraits are animated at this time, so depending on which one you are trying, it may "animate" but just swap to the same image. Try it with the Pioneer, Infantry or Sniper units.

Check out the UI Components section for examples of portrait rendering.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

The AI currently does not know how to heal units. The Medic and Support Ship can heal various unit types, specified via healTypes. You can see how it is used in the getHealableVectors library function.

Implementation

For this task, the AI should receive a top level function healUnit that filters units that can heal units and finds nearby units to heal. It should make a good choice about whether to heal other units by considering health, cost of healing, and how many funds the AI is generating and/or whether it needs to build units or buildings instead. You may want to consider defining a weight for whether a unit should be healed or not, similar to whether an opposing unit should be sabotaged instead of attacked. getHealCost is used to determine to cost of healing a specific unit.

Additionally, the AI should consider building a Medic or Support Ship from time to time via its createUnit function.

AI Info

The current AI is called DionysusAlpha and its code can be found there. There are also many AI specific helpers in dionysus/lib. Check out the AI Playground.

Test for new AI behaviors should be added to AIBehavior.test.tsx. These tests must fail without the change from this issue, ie. they must ensure that the AI deterministically implements the new behavior.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

Hi, I've noticed the units no longer reflect the current player when placed in the map editor:

I did some digging and found the commit that causes the problem: e893189#diff-f7f9046324da075be3c9cebbfb7185d39a6d4daec6d6aa1ff219449106e1f1b4L524-R574

If you roll back to what it was in the above diff, it would work properly again.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

Currently Athena Crisis is using the DOM to render the core game. I would like there to be a full renderer for the game using React-Three-Fiber so we can make comparisons on performance and battery usage. It also opens the door for a possible 3d version of the game in the future, give more options for fancy fog implementations, and it should help fix the rendering of decorations which is currently a bit messed up.

Expectation & Steps

• Create a new package at the root (you get to pick a Greek god you like!) and mirror the package.json setup from hera. Add it to pnpm-workspace.yaml. All new code should go into this new package.
• Check out Map and its child components. These are the primary components of the renderer that need to be ported, along with animation components. Ideally, as part of this experiment, a new component Map.tsx component is created in the new package that retains the same interface/props but renders to React-Three-Fiber instead. You may have to look at GameMap for how this component is used, and you'll need to explore its child components like Tiles, Decorators, Fog, Building and Unit. The Unit component is the most dynamic one and most likely needs the most work, especially to support animations like unit moves and animations.
• There are a number of fancy usages of CSS like fading buildings when a unit is above it:
  
• Or the subtle outline that fades in when a unit is selected:
  
• Decorations are currently drawn behind buildings and units which can look odd. Ideally a proper renderer will put them (as well as forests etc.) on the right z-layer so that units and buildings can be "behind" a decoration or "inside" a forest.
  
• Menus can remain being rendered using the DOM on top of the map for now.

Ideally, at the end we have a full renderer for the game and can simply swap the Map component to use a different renderer.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

Right now the AI does not consider win conditions besides escort by label/amount. When there is a capture win condition for another player, the AI should actively try to deny those captures. If there is a capture win condition applying to the AI, it should produce more units with the capture ability and focus on the capture targets (either all buildings or filtered by label). If there are defeat (one) by amount or label conditions that apply to the AI, it should seek out the corresponding units in particular.

You can find more info about how to set up win conditions in code in WinConditions.test.tsx.

Steps

I believe a good start is to tell the AI about capture-able targets (or specific opponents to attack) by adding them to the "interesting vectors" list in getInterestingVectors or getWinConditionVectors. For building more units with the capture ability, determineUnitsToCreate and its callsites are most relevant.

AI Info

The current AI is called DionysusAlpha and its code can be found there. There are also many AI specific helpers in dionysus/lib. Check out the AI Playground.

Test for new AI behaviors should be added to AIBehavior.test.tsx. These tests must fail without the change from this issue, ie. they must ensure that the AI deterministically implements the new behavior.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

Can't play on Firefox, add Firefox support please.

It would be awesome to add a toggle for win conditions that makes them "optional". Together with win conditions being secret, they could add for hidden rewards within a game that do not end the game.

Code & Steps

• WinConditions.tsx for data structures.
• checkWinCondition for checking whether a condition was meet. Check its call-sites for handling optional win conditions.
• WinConditionCard for rendering.

This change likely requires adding an optional field to each win condition. The structure of encoded conditions cannot be changed, so we can only add fields to them that are optional. Sorry, there is no codegen for encoded win condition, but it's all local to WinConditions.tsx. We'll also want to add a completed field that is a Set of PlayerIDs that have completed that win condition. Similar to hidden/secret win conditions, the UI should show a checkbox to mark them as optional. I would suggest that the default win condition (defeat all units or capture HQ) cannot be made optional. Win condition validation needs to be updated to check for that, and validateMap (or maybe validateWinCondition or similar) needs to reset the completed state.

You can find the win condition panel in the map editor when pressing c, or by tapping "Conditions" in the bottom drawer.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

Mouse input controls stop working, do not see the cursor on hover either. Looked in console and saw this:

On initial page load, error message is not present while the game is working. Have not figured out steps to reproduce. Happened once while scrolling to the bottom of the page, another time when coming back to a tab after a long period of time after a few moves.

If I was to hazard a guess, mime type for an asset on an S3 bucket that does not exist is text/html 404 not found generic error page. Would be curious if assets are lazy loaded and when a new version is deployed if the old built files are being deleted. Thought is if that occurred while someone was playing a long game and a new version was deployed, old files deleted, then the game would end up at the state of requesting a JS asset that is no longer available and receive a 404 not found generic S3 error page of mime type text/html. Potential solution is never delete the old files. Just a wild hair of a guess.. 😅

Amazing project by the way, inspired. Cheers.

Right now there are no statistics to help players make better decisions. If a player wants to know how much funds each player is generating, or how many units each player has, they have to manually count them on the map. This task is a UI focused task to nicely present data available via the MapData data structure. Most relevant information can be collected using helper functions such as calculateFunds.

Currently, player information is shown via CurrentGameCard. It expands when clicked:

Ideally, this flyout receives the following information per player:

• Number of buildings
• Number of units
• Funds per turn
• ...?

Notes

• If fog is enabled on a map, it should only show visible information and/or show question marks given that the info may not be complete.
• This must work on small screens (iPhone) and large screens.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

For the Open Source website, it would be great if the Map Editor Playground supported "saving" and loading maps. Let's store a map in the URL. When loading the playground, the URL can be decoded to load a map.

Steps

• A callback for creating/updating a map can be passed to the component. When called, it should store the received data in the URL. In this case, the relevant use of the map editor is in map-editor.tsx.
• If the data is present in the URL when loading the page, it should decode and pass it as mapObject to the MapEditor component.
  • Check out the definition of the MapObject.
• The create/update callbacks are called through the settings panel's "Save Map" button in the editor.

*Note: The Map Editor might not re-render with new state if the mapObject that gets passed in changes. It may be necessary to set the key prop to wipe away map editor state.

Links

• Map Editor Playground

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

I want Athena Crisis to have a much stronger AI, and I want the best AI of the genre to be built in the open to inspire every future turn-based strategy game. This is a competition to build a better AI for Athena Crisis that beats the current AI.

All submitted AIs will be ranked based on a set of benchmarks. The prizes are as follows:

• 1st: $2500
• 2nd: $1600
• 3rd: $900

We expect the benchmark to evolve while the competition is ongoing and people are welcome to make contributions to the set of benchmarks we are considering to make sure the AIs can deal with as many situations as possible. The competition is scheduled to run until October 14th, but we may extend the timeline depending on progress and feedback.

Since this task requires extensive knowledge of Athena Crisis, a limited number of Steam Keys for the full game is available for participants. Please reach out to @cpojer (twitter.com/cpojer or [email protected]) for more information.

Check out the AI Playground.

AI Info

The current AI is called DionysusAlpha and its code can be found there. There are also many AI specific helpers in dionysus/lib.

Rules

• Completeness: Any custom AI must be able to pass all objectives and have as many capabilities as the original AI.
• Performance (Speed): The AI must not be slower at performing actions on a set of benchmarks compared to the current DionysusAlpha AI as of July 29th 2024. Any performance improvements made to existing AI code or libraries that also speed up DionysusAlpha during the competition will only be attributed to your code, but not to DionysusAlpha. This means that speeding up library code is beneficial to you and the codebase, and will not count against you.
  • Note: Any improvements made as part of #9 are considered an exception, and they will speed up DionysusAlpha as well as your AI. On the other hand, any improvements made as part of #15 will only count towards your AI, even though it makes the existing AI faster. We care about the baseline of AI performance as of now.
• Stability: The AI must not crash or produce illegal actions.
• Evaluation: In case the AI performs at the same speed with the same outcomes as another AI, it will score based on the fewest turns it takes to win, or otherwise the fewest amount of actions it takes.
• No Hardcoded Map-Specific Logic: AIs should be able to deal with any map setup and must not have map-specific logic hardcoded.
• Choice of Tooling: The AI has to be written in JavaScript and be maintainable. This is not a code-golf competition or challenge about porting code to another programming language.
• Fog: In fog, AIs are receiving more information than regular players. This allows them to make better decisions for gameplay reasons, but could also be considered cheating. DionysusAlpha handles this carefully by hiding information from various algorithms via this.applyVision(map). We suggest using your best judgment about the degree of cheating that your AI is allowed to do. Benchmarks will run fog games with full information and with only visible information so they can be compared.
• Clarifications: We may clarify rules as necessary.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

Calculating a movement, attack or vision radius is among the most computationally intensive code paths in Athena Crisis. While its performance does not affect normal gameplay, it matters massively when the AI figures out what to optimize for. This is further exacerbated by the fact that results of radius calculations cannot be cached for long, as any action executed against map state may change the radius that is returned. For example, defeating a unit that is blocking a path may make more movement and attack options available for other units in the same turn.

This task is focused on speeding up Radius.tsx by 2x or more. Given how critical the code path is, it is acceptable to make the code in this file slightly less readable (but still reasonably maintainable), and possibly also optimize some of the downstream algorithms – as long as it doesn't change the layout of MapData. It is preferred not to modify the return types given how widely they are used across the codebase, but I am open to it based on a proof-of-concept and some discussion of the trade-offs.

Guidelines

• The current algorithm went through extensive testing and its behavior must not diverge. All changes must pass the full test suite.
• More test cases may be added to ensure nothing breaks with the optimizations. It is allowed to update some snapshots if the order of the returned radius items is different, as long as it is the same.
• The code must remain maintainable, but some trade-offs around readability close to Radius.tsx are acceptable if the performance improvements warrant it.
• Performance improvements must be shown through the benchmark suite for calculating a radius. You can run the benchmark via pnpm vitest bench.
• The primary focus should be on calculateRadius and movement radius. Speeding up attack or vision calculation by 2x while not speeding up movement radius calculation at all does not meet the objective of this task. However, speeding up movement radius calculation by 1.5x (for example) and speeding up attack and vision calculation by more beyond that might be worth it.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

The repo currently does not work on Windows. This task is about making it work on Windows without usage of Windows Subsystem for Linux (WSL).

Requirements:

• pnpm dev:setup works on Windows.
• pnpm test works on Windows, including screenshot tests.
• A CI job to run tests on Windows to prevent regressions.
• Updates to the README, if necessary.

Ideally this does not introduce a performance overhead for macOS and Linux users. I care a ton about scripts running as fast as possible, so I prefer not to invoke node unless necessary, for example.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

This is a placeholder issue to store the funding amount for the second place of the AI building competition.

See #10 for the full competition information.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.

This is a placeholder issue to store the funding amount for the second place of the AI building competition.

See #10 for the full competition information.

Funding

• We're using Polar.sh to distribute funds.
• You receive the reward once the issue is completed & confirmed by Nakazawa Tech.