This page is mostly used to WIP work and coordination purpose.
It can be outdated and can change without further notice. (You'll be warned.)
Overall Roadmaps
Here are the main roadmap components that *should* be completed (IMHO) before the ManaServ release:
- Both Mantis roadmaps:
- Crush todo list:
- CR1 graphics (to indeed bring something worthy with all that shiny stuff):
Repositories cartography
Since we've starting to have a billion different git repo for the mana/tmw client binary, server, data. Each used on different goals, I added here simple cartography of every git repositories to actually get an idea about what is stored where.
| GIT repository | Description |
|---|---|
| Development | |
| Mana client (Development clone) http://gitorious.org/~bertram/mana/mana-attributes-system-test |
This repository stores the client sources. It is used to test highly experimental new features and POCs. Once the code here is mature enough, it goes to the mana:master repository. |
| Manaserv server (Development clone) http://gitorious.org/~bertram/mana/manaserv-attributes-system-test |
This repository stores the new server sources. It is used to test highly experimental new features and POCs. Once the code here is mature enough, it goes to the manaserv:master repository. |
| Mana client development data http://gitorious.org/+tmw-admins/tmw/client-dev |
The client data stored here are used for highly experimental purpose with the new Manaserv server. Once they'll get mature enough, they will be used to bring out the content release 1 at the time of writing this section. |
| Manaserv server development data http://gitorious.org/+tmw-admins/tmw/server-dev |
The server data stored here are used for highly experimental purpose with the new Manaserv server. Once they'll get mature enough, they will be used to bring out the content release 1 at the time of writing this section. |
| Testing | |
| Mana Client (Master branch) http://gitorious.org/mana/mana |
This is the main branch of the mana client development, and thus, is the most active repository. New small features and minor refactorings are added here directly. Bigger changes go through the development clones. |
| Manaserv server (Master branch) http://gitorious.org/mana/manaserv |
This is the main branch of the mana server development, and thus, is the most active repository. New small features and minor refactorings are added here directly. Bigger changes go through the development clones. |
| Manaserv server data http://gitorious.org/tmwserv-data/mainline |
This is the currently server data testing repository for manaserv. It's also stored as a reference of files used to how configure it. |
| TmwAthena server testing data http://gitorious.org/+tmw-developers/tmw-eathena-data/testing |
This repository stores the data used by the TmwAthena server currently in use for future content release. |
| Production | |
| Mana Client (Production branch) http://gitorious.org/mana/mana/commits/1.0 |
At the time of writing this section, the current production branch is the 1.0, but it will be upgraded to a new one whenever the 1.0 release is done. Only bugfixes and show-stoppers are allowed here. |
| Manaserv Server (Production branch) | No repositories are used for production now since the new server isn't enough mature now to get a production release. Let's hope it will change soon :) |
| TmwAthena server data http://gitorious.org/tmw-eathena-data/mainline |
This repository stores the data used by the TmwAthena server currently in use in production. |
| TMW client data http://gitorious.org/tmwdata/mainline |
This repository stores the client data currently used by everyone playing the game. Small additions not forcefully yet online can be added, but it's quite in sync most of the time. |
| TMW client branding data http://gitorious.org/tmw/tmw |
Here are stored the files used to actually shape the mana client into a TMW specific client. Custom branding and gui files usually go there. |
| Tools | |
| Tiled (Working) http://gitorious.org/tiled/tiled-qt |
Tool used to create maps for both servers. |
| Fairy Glow (Alpha) http://gitorious.org/fairy-glow/fairy-glow |
This tool will be used to create particle effects. Since this is still more a fresh start than a real project, you can use this (older) project instead for testing purpose: http://gitorious.org/fairy-glow/particled-igneus |
| Resources | |
| Artists repository http://gitorious.org/tmwart/mainline |
This repository is used to store the original files, templates, etc, everything used to actually get content into the game. |
| Music repository http://gitorious.org/tmw/music |
This repository is used to store the music files used in-game. |
This part aims to bring a finished version the multi-level maps and everything related to 2D layer rendering, called action layers previously. Most of the text is inspired by the original pages and is trying to complete the initial effort, here:
Some part can already be finished and some may not, the aim is also to gather that kind of specifications in one page.
Multi-level maps
As in the first Map layer proposal, multi-levelled maps should be supported (under Manaserv 1.1 or 2.0). In order to know the map current level of a layer, we make use of the collision layer which will be considered as the last layer of a level. The map reader will then be able to increment the level of the layers next to it:
| Map Layer | Level |
|---|---|
| ... | |
| 10 | 2 |
| 9 (Collision) | 1 |
| 8 | |
| 7 | |
| 6 (Fringe) | |
| 5 | |
| 4 (Collision) | 0 |
| 3 | |
| 2 (Fringe) | |
| 1 | |
| 0 | |
As told here, the 'collision' layer
should handle more than one collision type. This was copy pasted from the previous page with some slight modifications:
The Monster Problem
Another important collision tile type we need is a tile that blocks only monsters.
This would come in handy to prevent narrow passages and bridges to get clogged with monsters.
Another good example this could be used for are portal areas, like the cave entrance.
The entrance of the cave from the inside is crowded with red slimes and black scorpions sometimes as it is now.
I don't think these tiles should block the creatures in a normal way.
They should block them as long as they haven't been attacked.
The monsters should follow players who hit them.
So basically these tiles should not be picked as a target for roaming monsters:
This image could be used very conveniently: 
Fences and firing problems
The archer on this picture is separated from the enemies. He shouldn't be able to hit the right enemy with an arrow because there is a cavewall in the way he can't shoot through. But there is no reason why he shouldn't be able to shoot an arrow over the unwalkable pond to hit the left enemy. To give mappers the possibility to mark areas that are blocking movement but not ranged attacks I suggest the "Not walkable but shootable" tile.
N.B. : "Not walkable but shootable" -> And also flyable and why not jumpable tiles.
The same goes for fences. It should be doable to fire through windows, fences and so other things, even if the shooter isn't on the same level than the victim.
The image showing a red cross and a blue bow could be used very conveniently for this purpose.
Beings' level changes handling
The level changes can be handled using a special collision tile setting to which level the being is on when walking on it. When making the map, the 'change level' collision tile will have to be set on both collision layers of each concerned levels.
The level tile integer property will have to tell on which level the player is when walking on the tile.
Technically, a Level 1 collision tile or group of tiles will always have to be next to another level -1 or +1 group of tile, to permit the level switch in both direction.
Handling the path steepness
Another good idea given in the collision layer improvement, is to handle the walking upstairs effect and similar effect while walking on something looking steep.
In a 2d world, it is hard to handle a z coordinate without starting to handle real 3d objects calculation. The effects used in SoM for instance are really ingenious as they don't use any 3d calculation and still handle stairs nicefully:
When a character is walking on something looking steep, its speed will be decreased to show the inclination. A tile should be able to get an inclination integer property which would be used to show how steep is the current tile. Also, a steepness_direction could be used to make the engine know if the slope vertical or horizontal, and then decrease speed only for x, y coord value changes, or both.
These two tiles properties would suffice for stairs going north or south, for instance.
But there is a third effect missing when going upstairs while actually moving left or right: Give the illusion that the being is actually moving upstairs, for instance.
Make use of the z coord to show how high is a character would lead to problems with mapping higher levels, as we'd need to offset the current coord and it would be a mess.
The simpler solution is to give the illusion of moving up as the being is actually moving diagonally instead. Two special collision tiles could be then used to force {north-east;south-west} and {south-east;north-west} being movements when it's trying to move left or right.
This, combined with the above two tiles properties would lead to an illusion of moving to another map level without requiring to do so yet. No offset would have to be done on coordinates as the being is simply moving on the same layer, and level so far.
How to combine levels and steepness?
When a being has reached what looks like the upper part of your stairs, you'll then be able to make the level switch, for instance before adding a bridge.
The error where I lost myself also was to try directly to combine both steepness and level switching in one tile. I should be feasible, but certainly harder and less understandable.
Main rendering z-order
Now, for each map level one after another, the engine will have to render the world in the following order:
- Every non fringe layers (First map layer, until fringe layer - 1)
Then before drawing the fringe layer: Every being should be sorted by y value, the precedence given below is for beings with the same y coord pixel-wise value:
- Draw floor items
- Draw monsters
- Draw NPCs
- Draw Players
- Draw Localplayer
and at last:
- Draw Fringe tiles
and then:
- Draw every layers between fringe + 1 and collision -1.
As told above, if a layer after the collision exists, it will be taken into account with level + 1.
...
- Finally, after every map levels, draw ambient layers.
Note: This z-order rendering doesn't take particle effects into account yet because I didn't want to mix subjects. See below to get a more descriptive order including particle effects.
Particles z-order
The particle effects are an important part of a living world. There are two main types of particle effects : The static ones and the ones linked to a being or an item.
Common effects are usually meant to surround a being, and then the particle effect should be divided into two parts: - The part behind the being. - The part in front of it.
By default, the bottom part should be drawn just before the beings itself, and the above part just after it.
There are also particle effect that should always be, for many reasons, behind or in front of a specific layer.
A z-placement string value or such should be handled in the particle-effects.xml files in order to tell before or after which layer, the effect should be drawn. "Below-Beings", "Above-Beings", "Below-Fringe", "Above-Fringe", "Below-Collision", "Above-Collision", "Above-Ambient" would be useful values.
These flag would handle effects drawn at the same map level than a given being's ones.
For static effects, not linked to some being, a maplevel integer value should be given in combination with the above property. defaulted to 1.
