robinstephenson / jbt Goto Github PK

Bare in mind we will have ComputerPlayer too

Fix roboticoncustomisation, it will not work with null as a parameter for prior customizations. Instead we should have a base customization that all new roboticons have that just have their multipliers set to x1, this is required for roboticons to function correctly anyway, since we go off their customization when calculating production returns for tiles. The base customization should be a static member of the roboticoncustomisation class.
MikeyWalsh

For an example, in the buy method we throw an ArgumentOutOfRangeException both for an error to do with stock and if the user hasn't got enough money. The exceptions would be more descriptive if we had a NotEnoughMoneyException, and a NotEnoughStockException. This also means anyone using the buy method can know why the exception happened which at the moment they cant very easily.
The NotEnoughMoneyException will also be useful in any other classes where players might be buying

We don't need to worry about players seeing each other's values yet but bare in mind we will have to in the future.

you can use the when it will be thrown to give info about error a method can throw

Its possible they should have been updated to other exceptions (not enough money or stock)

Finish testing for roboticon, roboticon customisation and market classes.

Markets and other classes that are only "open" in certain phases had open/closed in their original design but with the new system of time outs in player this wont be necessary. I think they weren't really implemented anyway

https://msdn.microsoft.com/en-us/library/ms229043(v=vs.100).aspx is the style to follow.

I think only the market should decide whether it should perform this operation so it should be private not public. We dont want any class to be able to call this

Should throw an error when someone adds a negative amount of money

implement Market.MaxWillBuy(ItemType) which should return the maximum quantity the shop will buy of an item. It should take into account how much money the market has, the market not wanting to own too much of an item (this doesnt have to be perfect, it could just be something like wont buy more than a constant in a round).
Return the min of the two above.

A limited map that is subdivided into plots. Bare in mind that we may have to change the number of plots later on.
There is no need to make the map pretty or show any landmarks.

When transferring a tile to a new inventory the inventory should update the owner of the tile. Probably best to do this in add tile, inventory will need a reference to its owner

The turn controller is in charge of controlling the phases of each turn eg whether the market is open whether tiles can be bought

This is so that we can enforce the time limits on phases

A method for producing for the market based on its inventory.
Method for players to buy roboticons for a fee
Method for players to customise roboticons for a fee.
Should throw an error if player interactions happen in the wrong phase

This is just a UX enhancement so only implement it if we have time. Also could be quite tricky to implement nicely

Create a getter to allow people to see a list of roboticons in a players inventory

Class used to ensure any transactions involving money happen properly

Tile art (one for each player and a neutral), sprite for roboticon, ore and energy image

Create a minimal menu which allows the player to start a game.
This is mostly a placeholder for later assessments when there will have to be more than just a play button, for example choosing whether they want a computer or two players.

I think when we moved ItemType into its own file but in the tests folder the actual inventory class cant find it. Can we move it in with the rest of the code and is there a way we can get the tests to reference it from there without having to have 2 copies of the same file?

Some people might not have seen callbacks before so putting this here to remind me to write some documentation

Just read through documentation and check that documentation matches implementation. Check names match parameters in methods etc, check the return is still correct and so on.

! Start this only when coding is finished !

Just needs to be purchasable and have production / roboticon support

Tile controller should be able to open and close it for different phases.
Should throw an error if someone tries to use it when closed.

Tidying and finishing classes in tile-player-robo, now that all 3 people have had their pull requests confirmed. Todo list includes:

1. Remove sprites folder, as it is unnessessary
2. Remove TilesGridTest scene
3. Add an ID field to AbstractPlayer, and make it work with the CreateTile test in TileTest
4. Finish ProduceTest in TileTest, and add any tests you deem appropriate
5. Fix roboticoncustomisation, it will not work with null as a parameter for prior customizations. Instead we should have a base customization that all new roboticons have that just have their multipliers set to x1, this is required for roboticons to function correctly anyway, since we go off their customization when calculating production returns for tiles. The base customization should be a static member of the roboticoncustomisation class.
6. Fix SuccessfulAddCustomisation in RoboticonTest and add any new tests if you can think of any.
7. Fix FinishUnstartedTest in TimeoutTest

Just make it really dumb at first as were not required to implement supply and demand yet

In Tile-Player-Robo

food is not required yet but bare in mind that it will be

Some fields in market are using the old underscore convention for privates