battlecode / battlecode-client-17 Goto Github PK

It would be cool to see the sensor radii (unit vision and/or bullet vision) for a selected unit. Something like what the 'c' key does right now.

Can't figure out why the game canvas is aliased but the map editor canvas is not.

We need a central 'Game Loop'.
It should:

• Update the turn counter
• Update the world model, if necessary
• Re-render the game state
• Update the UI, if necessary

Note that we don't really need to handle user input in the game loop, we can just have user input callbacks modify the game state and then go from there.

No idea what's going on here, probably some issue with interpolation?

It'd be nice to be able to click somewhere on the timeline and go to that spot in time. I'd also like to be able to rewind time, or perhaps go backwards.

When the player System.out.println stuff, it should show up here.

The tank object is always oriented in one direction. Rotate the tank so it is facing the direction of movement when moving, and facing the direction of shooting when shooting.

Both bullet trees visible on the map should be dead at this point, and the server processes them as dead. Bullets can be shown passing through the one in the top right. Both of them stay there for the rest of the match.

In other matches they are removed as they decay, but sometimes they don't disappear for unknown reasons.
nickplayer-vs-nickplayer-on-simple.bc17.zip

When clicking on neutral trees, you cannot see their health and location information like you can for other units. Having this information might be useful.

We should put all strings into a separate file, for ease of translation into different languages.

Could be useful to have a few settings in between the current fast and normal settings.

Move all options-related things to a new file. Generally try to separate options from the other modules.

So they don't just disappear into nowhere.

Move the Game Queue from app.ts and stats.ts and place it into its own file for organization purposes.

Uploading multiple game files work, but uploading the same file twice does not work. There is possibly some sort of logic which prevents this (which also occurs even after removing the game from the game list in app.ts).

@ygina I think the help panel needs to be updated, as it currently contains "From the scaffold: TODO"

There should be something to display if there are bullets or robots in a tree.

It would be really cool if you could point the app version of a client at a folder containing the scaffold, and have it start matches there.

This is possible because electron lets you use node APIs like fs and child_process.

See #23 for how to use those APIs.

The one right now is so 2016

To show when we haven't loaded a match, instead of the half-empty current client.

Once a file is uploaded, the client is not allowing a second upload.

I was just showing the client to my dad, and he said it would be really helpful to have a win-count tracker of some kind in the client, that shows how much a particular team / AI has won; which I'd really never thought of.

I'm not sure how we would implement this, but I think it's a good idea.

It would also be cool to have a run-tournament function in the client, that shells out to the server in order to compute a tournament of matches. We could also use it for the main tournament.

From last year's specs:

Indicator Items and Control Bits

You'll find that your primary source of debugging is setting one of 3 indicator strings that are viewable in the client. Unlike System.out which is not synchronized to match execution (as the engine precomputes the game faster than the client views it), Indicator strings are synchronized to the round number and can be used for debugging complex robot behaviors.

Use setIndicatorString(int,String) to change a robot's indicator string. The are viewable in the top right corner of the client when the robot is selected. Indicator strings maintain value until they are changed.

In addition, there exist setIndicatorDot() and setIndicatorLine(), which draw visuals on the map when the robot is selected. Second, the user can manually set a long for each robot, which the robot can query using getControlBits().

Let's bring these back.

Clear out all the TypeScript clutter that's manually setting up CSS and move it to the global CSS file.

It's a large 100x100 map with lots of trees. The game runs fine. Map is linked in the client channel.

Just fix the map validation.

Make maps of neutral trees, and write them out to a GameMap.

I'm on Google Chrome, Macbook Air, 1400x900 resolution.

Not sure, but I think a .bc17 file can include multiple matches. Thus we should be able to play all the matches, and not just the first one. This would require

• Buttons in the control bar for going to the next/previous match, and something like "Match 1 of 3"
• The corresponding functionality

We need to be able to play and rewind games.
We want a class with:

• a big list of battlecode-schema.Rounds
• a sparse list of battlecode-playback.GameWorld 'snapshots', one every n turns
• a 'seek' method that picks the previous snapshot and then applies rounds on top of it until it is at the correct turn. It should probably take a callback / return a promise, so that we don't block things.
• A method to add more Rounds to the internal buffer
• A method to perform a single simulation step.
• A getter for how many rounds we have simulated so far.

We should put a basic implementation of the class in battlecode-playback, I think.

Eventually this class should have a WebWorker backend so that we can be multithreaded. This should be an invisible change to users of the class.

We'll also need to put this in the UI, but that can happen later.

Why should we be limited to ~2005 graphics? Let's put in some material design or fancy pause/play/seek/stop/restart controls and other graphics here and there.

We currently use lots of absolute sizes in our CSS, which we should probably change before the competition starts. People have all shapes and sizes of screens.

(This is lower priority than base functionality.)

Both soft buttons and physical key mappings. I feel like this is necessary to see how a player responds in micro.

We want a function that takes a battlecode-playback.GameWorld and draws the current status of the world onto a canvas2d. Minimally fancy, probably just a bunch of circles to start.

We're dropping frames sometimes, which means that we're going over computation budget somewhere. We should do some profiling to see what's causing the slowdown.

When switching between games and matches within the game queue, the game will freeze and only play again once you click on the timeline. The match is also not correctly cleared when all games are removed from the client. Fix this by figuring out how to completely reset the client stats, controls, and board when switching to a new match.

We're still using some placeholder graphics--we can update these now

We should build tests with webpack and run them in a browser.
I will implement this in the next few days.

...As in, remove unused code from the published bundle, in webpack, for production. Not the game tree-shaking. That's different.

It will probably involve Babel, because we aren't using enough abstruse tools yet

In addition to showing the ID, it would be helpful to click on a robot and see its health amount, its location, and its bytecode usage from the last round. Also, # turns left until a robot is done being built.

How else will we know when to worry about our robots? I'm guessing we have to draw rectangular things on the canvas under each bot. Not to be confused with the granola snack.

The robot counts, bullets, victory points, and team names should reflect those of the loaded match file.

I'm not sure what qualifies something on the web as accessible, but I have a feeling that the client is not.

It would be helpful for debugging to be able to hover over the map and know what coordinate your mouse is on top of.

Recruit was just removed from server and schema. This will probably break some flatbuffer stuff, so you'll need to use the latest version of battlecode-scema here: battlecode/battlecode-schema#9. You should also remove the recruit sprite in the unit counts.

We want a UI with:

• A blank canvas to draw the game onto
• A play button
• A pause button
• A "load" that brings up a file picker that lets you pick a .bc17 match to play. See https://developer.mozilla.org/en-US/docs/Web/API/File, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input

...and also a bunch of other stuff / whatever you want to implement, but this is, like, the minimum.

All of these elements should be children of the element we mount on (see src/app.ts). We should create them programmatically using document.createElement and friends; alternatively, we could use something like React or Mithril, but I think those would be overkill.

The client should be a rectangle; you should be able to set how much space the client takes up in the Config you supply when you start the client (see src/config.ts). This could just be flat pixel-sizes, or it could be something smarter; I am not versed in the vagaries of the deep magic that is CSS layout.

Note that when you do npm run watch, the file that loads is index.html. Modify that if you want to change the config for the client when developing.