-
Notifications
You must be signed in to change notification settings - Fork 7
Todo
larspensjo edited this page Jan 23, 2013
·
6 revisions
Instead of defining "issues" for everything, this is a list of possibilities and ideas. The issue list will be used for distinct tasks that are easy to classify as done or not done.
- The player itself is currently a frog model. Instead, it should be a humanoid.
- There are only two kinds of monster models. This should be extended to more types.
- It could be possible to have a better physical simulation. For example, when walking on ground that slopes, one leg should fall lower than the other.
- The models shown for other players is even worse than the frog.
- Monsters can have more variations, using colors and textures, for the same model.
- Investigate the use of IQM files for models instead of dae (Collada files).
- There should be sound from monsters moving.
- Use echo from sound when in a cave.
- Support footstep sounds that depends on the material. Currently, there are only two sounds depending on being in water or not.
- It would be possible to have a better "select-manipulate" way of working. A face on a block is selected, and then a command is requested that does something. E.g. deleting the block, adding another block, adding a copy of the same block type. It would allow for multiple face selection.
- Add a mechanism that allows activator blocks to be updated. Today, they have to be removed and replaced with a new one.
- Show chunk borders on the minimap and the full map.
libRocket will be used for dialogs. All dialogs will gradually be redesigned using libRocket. This gives some really exciting possibilities:
- Using libRocket, I can now present information in a pretty and flexible way. When the players steps into a trap, the owner of the trap can configure what message to produce. I just realised that this message, which will be shown in a libRocket document, can contain any type of libRocket-supported html formatting. That also includes the possibilities to select pictures for backgrounds, etc.
- Not only that, but it is possible to create proper forms, including choice elements and buttons. That would allow for interactive dialogs, where the adventure depends on the player choices.
- Another possibility with libRocket is to produce a document that is projected onto a wall in the game. That would allow for the adventure designer to create any type of "painting" or thing they want to show.
- Yet another possibility is to allow dialogs to be persistent. The player shall be able to move them, minimize them, or close them, at will.
- Sometimes, the view will show things behind walls. This happens when the camera is too near walls. Either an algorithm can be used that prevents the camera from coming too near, or a mechanism that shows a replacement instead of what is behind the wall.
- The borders between the chunks can be seen today. There is a mechanism to make the world smooth, which need to be improved.
- The underground look need to be improved. E.g. adding stalactites, wet surfaces.
- There should be a tool tip with information that says a little about the destination.
- Implement for Screen Space Ambient Occlusion. There is an attempt already, but it doesn't work.
- Use compressed textures. This will save GP memory, as well as speed up rendering.
- Use a LOD algorithm for chunks.
- The current use of billboarding is only basic. Trees far away are replaced, and shadows from trees are replaced. But it is too easy to notice the change. The technique can be extended to more types of objects.
- The attack buttons should be shown in the UI, with tooltips.
- Support distribution to Linux
- Chunks are not freed from RAM. Sooner or later, the game client will run out of RAM and crash. But it seems to take a while.
The idea is to allow users to define objects. These can then be instantiated where wanted. See User defined objects for design ideas.