davidfidge / marsundiscovered Goto Github PK

If a morgue fails to send it is lost as it has been implemented as a fire-and-forget async call and has no retry logic. Possible Improvements:

• Add retry logic
• Disallow exit app if morgue is still waiting to be sent or send morgues synchronously
• Add morgue json to the morgue text file or dump it out in its own file. That way it can be sent later.

#41 fixed load game prompt speed. However actually performing a save game and load game is slow.

Most of the current problems are in the Monsters where it must serialize a large list of seen tiles. This means it will get worse as more levels are added to the game.

Writing a custom serializer for serializing map-related data such as map tile information, monster seen tiles etc should help:
https://www.newtonsoft.com/json/help/html/Performance.htm

Another thing to try would be to use BSON which would mean ints etc won't have to be converted to strings, though I doubt this is where the performance problems are:
https://www.newtonsoft.com/json/help/html/SerializeToBson.htm

Currently all textures are individual Texture2D objects.

During the graphics rework to fix slow graphics performance a workaround was added - the Sprite Batch mode draws tiles of the same texture at the same time. Thus the graphics code has to maintain an explicit 'order' value to define what order the tiles should be drawn in so that floors get draw before items etc. As a reminder, the reason that tiles of the same texture need to be drawn at once is that the graphics card does not like switching textures between draw calls.

The benefit of a texture atlas would mean that 'order' values won't need to be maintained anymore and tiles could just be drawn by type e.g. floors first then walls then items then actors. The graphics card will not need to switch textures as all textures are in the one texture atlas. The graphics card would use texture coordinates to draw a subset of that texture.

Ascii textures are currently created at runtime. This does not seem to hinder startup performance so this system can probably stay - they will need to be packed into an atlas.

Another thing to consider is that it is planned to have animating textures even when nothing is happening. The tile graphics being made have 2 animation frames but should be able to support more than 2.

Have seen this bug once when going to level 2, coming back to level 1 and moving around a bit.

Try adding a bunch of monsters to both levels to see if it can be reproduced.

This problem will get worse when more complicated monster attacks and traps are implemented.
Movements as well as animations need to be done sequentially.

Item description methods have become too complicated to work with. They deal with long descriptions, short descriptions for inventory, prefixes and suffixes, whether an item is discovered and if discovered, whether the enchantment level is known. Ideas to address this:

• Rather than trying to adhere to Don't Repeat Yourself, it may be a lot clearer to just copy and paste description code across concrete classes, or only have non-tokenised static strings that can be reused in the base class.
• Still go with a DRY solution but rewrite all the code.

Also, the item type discovery system does work but it feels a bit difficult to work with sometimes.

Will decide on an approach as I add more items into the game. Leaning towards first idea due to its straightforwardness and simplicity.

Items have 0 attack after loading a save game

Currently the player must exit to the main menu to change game options such as Morgue username and Ascii tiles. They should be able to do this within the game and the changes should apply immediately.

As part of this work it would also be useful to change the game options system so that reads come from an in-memory cache rather than re-reading the file all the time.

Requires investigation, but I suspect that it is loading the entire save to retrieve the metadata.

A tiled graphics mode is required if the game will ever make a steam release or be accepted by a wider audience.

When a player is in a choke point e.g. corridor and a monster blocks other monsters then those other monsters have no goal and move between two spots.

It would be preferable if the monsters still progressed towards the player otherwise the player will not be pressured when there's a high density of monsters in their area.

The game runs very slow with more than 10 enemies on the map.

Investigate better ways for parsing parameters next time I need to do extensive additions to this feature. It should be easy to do using the Parser nuget library, which is already being used for application command line arguments (refer to Program.cs).

Currently GameOptionsStore reads from file each time it is accessed. It should instead read on demand once then cache the results in memory.

Writes should always save to file as well as update cache.

Currently the view and game layers are in the same project. The desire is for the game and view to be split into separate projects.

• The game project must have no dependencies on the view project.
• The view project can depend on the game project.

This separation of concerns makes the game layer much easier to test as well as being conceptually easier as view concerns are not getting in the way.

In an ideal world we would separate view->game dependencies into a separate library which contains only interfaces and DTO's to achieve true separation of concerns and allow the view even more flexibility to move without the game. However this adds significant overhead for a one-man project as everything being returned back must be converted to a DTO.

The view code will need to be disciplined with its use of the returned objects to make sure it uses them in a 'data-get' manner only. It is enough of a separation so that later down the line it wouldn't be too overwhelming to go further with the separation and add a new view e.g. implementing a JavaScript client.

In this work

• Rework the current code to remove Game->View dependencies. Currently there are one or two Mediator calls that are done in GameWorld and handled in the View. If possible, rework this so the View does the call. If not possible, create an explicit back channel system so that any required back channels are easily discoverable (IGameWorldBackChannel - actual implementation could come from the view, or just use existing Mediator code - just as long as it is behind and interface and all in one spot)
• Game Options may need to be reworked somewhat as both the back end and front end need to use them.
• Create a new project with suffix .Game
• Move all the game world code and interfaces to the .Game project and also move the game installer here too
• Use the existing project as the View project, which will also contain the composite root and main game loop (MarsUndiscovered.cs)

Minor display bug which needs to be fixed.