Acceptance criteria:

• Construction Yard is drawn on map
• Ability to select Construction Yard

To test:

• point and click anywhere on the map and it will place a Construction Yard

Let units and structures uncover shroud.

Acceptance criteria:

• by default, all cells are shrouded
• units / structures have 'visibility range' (sight) (circular!)
• sight can be configured per unit / structure

For instance, the StructureRepository initializes itself in the constructor. This should be done via a configuration file, or perhaps dynamic language script? (ie Jython?)

Purpose: to make configuration and setup of game easier to customize.

In the original Dune (2) or C&C series, there where INI files.

I don't think we need to use that. Rather we could use XML (easy to parse - but verbose), or YML, or something with a hierarchy.

Now the unit instantly faces the desired direction. Instead it should turn to (with a turn speed) the next cell.

Given a unit that has a body and a top part (ie tanks) ,the top part should face the target cell and the body cell should only face the adjacent/next cell.

depends on #8

Related PR's:

• #117

Acceptance Criteria:

• Player must select Construction Yard
• Player can ONLY select a Const Yard to build stuff (:P)
• Player can select a building it wants to build
• Player can place a building on the map (anywhere!)

Drag box and select multiple units.

Depends on #25

Acceptance criteria:

• mouse left button is pressed
• mouse starts move (while button is pressed) - renders a rectangle from where mouse was pressed to where the mouse is now
• when mouse left button is released all units within the rectangle are selected.

Use events to handle input, game logic, etc.

One of the first practical usages would be to react upon keyboard and mouse events. Consider this task done when:

• game can quit using keyboard key event
• scrolling is done using mouse events hitting border of screen

When unit is on same 'height':

• Units on rock cannot see past mountains (although sight params permit it)
• Units on mountain can see past other mountain(s)
• Units on mountain can see past 'walls'

Airborn units have no hindered sight.

Depends on #9 and #25

Acceptance criteria:

• ability to build and place it
• ability to build a trike and quad
• once unit is built, it will appear next to the building on a free cell
• when no free cells are found then no unit will be deployed (for now)

more info:
http://duneii.com/buildings/#312

Ie, mountains, walls, etc.

• impacts path finding

Quads, Trikes.

Acceptance criteria:

• Unit is drawn on map
• Unit is drawn within viewport
• Unit has several facings (randomly shown)

It seems you can see the 'outer border' of the map at the right and at the bottom.

Add nuclear missile

• Add missile sprite
• Add some kind of 'projectile' thing flies from A to B with a given speed
• Let projectile detonate (create explosion) upon arrival at destination
• Introduce particle engine to show explosions
• Draw stuff accordingly to viewport/camera position
• Produce sound on explosion?
• point where to detonate
• gives a very large area of explosions - go wild here
• make it configurable in code
• let the 'ring of fire' do damage (but less and less the further away)
  And for the fun of it:
• spawn and fly a nuclear missile where the mouse is clicked (would be nice for testing purposes anyway)

Do note:
This shows the detonation in Dune 2000 of a Death Hand.
That is underwhelming to say the least.

Inspiration for the detonation/launching here

For inspiration:
this or this

One idea:
use Slick Particle System. To get that 'circle around explosion' feel we could use something like this

See:

https://github.com/haifengl/smile

We could possibly train the AI and let it decide what to do next based on previous attempts/learnings/input ?

What do you think @arjenvanderende ?

Acceptance criteria:

• select a unit
• mouse cursor changes to 'move here' icon
• when 'move here' icon is shown, and left mouse button is pressed on cell then selected units must move to that cell
• when unit does not face the next 'cell to go to' it should update its facing
• no need for path finding

Currently there is a very crude way to reveal shroud, which is also inefficient. This can be improved. We also have tests for this so its easy to see if the results are still ok regardless of the algorithm used.

Instead of fixed colors, a player can choose his own from any of the zillion colors available.

Instead of #39 where a unit/structure gets destroyed immediately - this ticket introduces the concept of 'health'.

Acceptance criteria:

• structure / unit has health
• structure / unit has health bar when hovering over by mouse
• health bar turns from green (healthy) to yellow (mwah) to orange (oh noes) to red (omg)

Have to see how tough it is to do (and how much it hits performance).

It would be nice to have certain plug points in the game where you can script your way out. Ie, the AI, Unit behavior, Structure behavior, World/tick behavior, etc.

With more complex interactions with the game coming, the need for a GUI arises.

It looks like Slick2D has some GUI's , this stackexchange post has quite a nice answer

basically boils down to:

• do it yourself (see link post above)
• NiftyUI (saw recent update of 25th 2015)
• TWL (not sure when latest release was)

Decision has to be made at some time.

Depends on #38 and #25

Acceptance criteria:

• select unit
• when mouse cursor is hovering over an enemy unit (or structure) then it becomes a 'attack here' icon
• when left mouse button pressed when 'attack here' icon then the units will move closer to target (if needed) and destroys structure (doing damage is other story)

depends on #9

Acceptance Criteria:

• Player clicks building it wants to place
• Player sees visual representation of building to be placed (can be anything) and gets feedback if it is ok to build there or not
• Player can place structure when terrain is rock or concrete
• Player can place structure nearby other (friendly) structures only
• Player cannot place structure on sand, walls, mountains, spice, hills, spice hills
• Player cannot place when too far away from other (friendly) buildings
• Prohibit placing buildings on top of existing buildings & units
• when units move beneath the structure to place, the state should reflect the unit movement

Many modern strategy games have a second shroud layer that is revealed only when within living unit's sight radius, anything else is remained covered. Terrain is still visible, along with structures previously scouted, but this information is not updated until a unit's sight passes through again.

This makes it more important to keep units on the map, as you will have no knowledge of enemy troop movements, even through previous explored areas, unless your units are nearby to see them.

I believe this would add a very interesting element to strategy, as many contemporary strategy games have proven already.

See EntityRepository where it setups an OpenGL context

The game should have a time component, for instance "Dune" mentions the year 10191. It might be nice to have the game start 100 years earlier. Then the game should have a concept of 'days' (standard days).

• figure out how many days == a year
• every x time (in real time) == 1 day on Arrakis
• after x days the year increases
• Year + days are visible on screen

With this it will be possible to have time based goals (like delivering spice every X time to the Emperor)

Befriending a fremen sietch takes more time, but has also long(er) term benefits

• get in touch with Fremen Sietch
• make intentions clear (alliance)
• Fremen will give you a mission to help them out
• If mission is completed with succes, the Fremen will favor your side more and more (you gain trust factor)
• When the fremen have enough trust in you, the Sietch will be befriended to you. (only that sietch!)
• When Fremen are under attack (ie, some other player wants to take Sietch by force) and you help them out it will greatly be in your benefit.

Benefits:

• a periodical gain of water
• harvesters within this area will not be attacked by worms (ie, fremen will make sure worms will keep out of the way)
• ... possibly some others
• with enough sietches befriended you might learn the secret of the water of life...

Downsides:

• takes (much) longer than simply taking over by force

More thought required

Requires #50 and #51 and a bunch more...

Acceptance criteria

• After X time (tbd) a specific unrefined spice quota must be delivered to the emperor
• Spice is delivered by accumulating this on a Starport and transporting this to the stratosphere of Dune

Consequences:

• Successful delivery keeps the Emperor pleased, but he will raise the amount of spice every time (the quota will rise)
• Unsuccessful delivery will have consequences like the Emperor sending troops and cutting of connections on the Trading market (meaning no more spice->money conversion). (need more thinking!)

From comment on #62

I'm noticing a z-index issue with the unit selection box: when a unit is selected and it drives diagonally past another unit, then the selection box is draw underneath the other unit. This seems logical: we draw the unit and the selection box in one pass, but they should probably be separate. Either we need to draw selection boxes after all units are rendered, or we need to change the draw order of units so it draws selected units last. I prefer the 1st option.

Acceptance criteria:

• left mouse button click on unit
• unit appears selected
• right mouse button click deselects unit

For an impression see this youtube video (~ 5 seconds)

About Coveralls: https://coveralls.io/

For this project, we need a maven plugin:
https://github.com/trautonen/coveralls-maven-plugin

The drawing logic is now allocating a texture of screenWidthxscreenHeight. Which results in an error:

Sun Jan 25 21:17:01 CET 2015 ERROR:Attempt to allocate a texture to big for the current hardware
java.io.IOException: Attempt to allocate a texture to big for the current hardware
    at org.newdawn.slick.opengl.InternalTextureLoader.getTexture(InternalTextureLoader.java:431)
    at org.newdawn.slick.opengl.InternalTextureLoader.createTexture(InternalTextureLoader.java:374)
    at org.newdawn.slick.Image.<init>(Image.java:237)
    at org.newdawn.slick.Image.<init>(Image.java:221)
    at com.fundynamic.d2tm.game.map.MapRenderer.makeImage(MapRenderer.java:25)

To solve this, the drawing should be done by the respective Viewport and it should only draw that part it sees (instread of drawing all and then simply taking a piece of the 'terrain texture').

Especially since we want to support MUCH BIGGER maps than this.

Acceptance criteria:

• When Refinery is placed a Harvester is supplied with it (no need for CarryAll to bring it!)
• The Harvester will mine spice until it is 'full'
• Harvester can dump spice at refinery
• Amount of spice is accumulated and visible to player

This opens the door to trading, goal of the game, etc. Which are not included in this issue.

Given: The player built a base on a territory that is not claimed his own or adjacent to an territory that is not his

When: Randomly

Then: The base will be attacked by the Mercenaries.

Acceptance criteria:

• map must be reproducible with a given seed

See also:
https://en.wikipedia.org/wiki/Perlin_noise
https://stackoverflow.com/questions/18279456/any-simplex-noise-tutorials-or-resources

Acceptance criteria:

• A key is assigned that makes the console appear or dissapear
• Given the console focus, when I type a command and press enter it must be executed
• Console gives output (perhaps hook it up as logger in the code instead of system out/log4j?)

This is one way to assume control over an area:

• attack fremen Sietch
• send troops within sietch, with enough troops the sietch becomes 'yours'

Benefits:

• if applicable, a one time benefit of water
• the area is marked yours to control

Downsides:

• Fremen will hate you even more

Tanks, Siege tanks

Builds upon #25

Acceptance Criteria:

• Have separate image for cannon of tank
• Cannon has separate facing of tank

needs more thought

There are multiple ways to 'conquer' Dune. This assumes on cellular level.

This is a relatively easy way to 'conquer' Dune.

• place a constyard + windtrap + outpost (minimum required) (const yard for constructing, windtrap for power, and outpost eventually)

Benefits:

• relatively easy way to conquer dune
• it will keep mercenaries away a bit

Downsides:

• will 'conquer' a much smaller region
• since mercenaries still spawn outside of your vision you might not have as much benefit when conquering a much larger region (ie with a sietch)

Acceptance criteria:

Depends on:
#25 - for units (closed)
#21 - for the concept of 'teams' / factions (closed)

• format has to be decided
• has terrain data
• has team start positions
• has team units (depends on #25)
• has team structures

Currently all game logic is FPS based. This should be detached from FPS and become time(r) based.

It looks like Slick provides delta's between two frames. We know how much time has passed and use that to increase timers/etc whatsoever to make sure entities/world things behave on a different pace.

Some info here:

• http://stackoverflow.com/questions/8282501/how-do-i-work-with-delta-in-slick2d-lwjgl-or-game-programming-in-general
• http://stackoverflow.com/questions/15906500/setting-the-max-and-min-value-for-delta-in-slick2d
• discussion: Maescool/Catacomb-Snatch#979

Although it is nice to have multiple viewports technically... in the game we have one viewport only and we should use one. It should be full-screen.

Soldiers

This should be like C&C , and not like the original Dune 2 where you have either 1 or 3 units at one cell.
C&C handles infantry 5 at one cell at max.

Possibly builds upon #25

Acceptance Criteria:

• Can place up to 5 infantry units on one cell
• Have different facings

This may look like a trivial thing to build, but it is not. It would be best to have other units drawing working before going to this one. (/cc @arjenvanderende )

Add shroud to the map

Ie. Place a Const Yard and scroll so that the topleft of the structure is not visible.

I would expect the lower / right half to be drawn. This does not happen.

Depends on:

• #25 rendering units
• #37 revealing shroud

Acceptance criteria:

• A team has a base color
• The base color is visible on units/structures
• A team has their own unshrouded map data (see #37)
• Renders units with team color (depends on #25)
• Renders structures with team color

Note: players are not 'humans' but more like 'sides' (teams).