1) This is current planning, not a promise - plans might change. It has also not really been discussed yet by the GAC or the ProgD - this is really my personal perspective at the moment.
2) There is no timepath specified - I have no idea how long it will take to implement those ideas.
3) Rude as it may sound, and although I am interested in any suggestions, this is not a request for permission from the players at large

Jos Elkink wrote:Hi guys,
This note is mainly meant for programmers, and it is the kind of issue
that I normally don't really ask the GAC permission for *smiles*, but
I thought it would be nice if you are all a bit aware of what I'm
planning with Cantr at the moment, programming-wise. I could have
called it 'Cantr 2.0' instead of 'roadmap', actually, as that is the
main subject. But then, the reason I write it, is to explain that I'm
more or less dropping the idea of a Cantr 2.0. Well, let me explain.
The original idea of Cantr 2.0 was to create a new standalone client
application that communicates with a new standalone server. This would
mean that people download a client program to log in to Cantr, which
would be written in either C++ or Java. This client program would be
more graphical, initially 2D and for Cantr 3.0 3D, and the style of
the game would thus quite dramatically change. The main idea was that
some things I wanted to have in Cantr would require such an interface
and thus a rewrite of the program, the main thing being free walking
around (instead of having to take existing roads).
There is several serious problems with this idea:
1) It is a hugely daunting task to completely rewrite the whole game.
I have made many attempts to start and several to get others involved,
and nothing worked. It is simply too big.
2) This is further exacerbated by the fact that Cantr 1.0 still needs
continuous maintenance and a lot of programming. Thus, it takes
basically all attention.
3) People don't seem to want a client that is not webbased. Many
people access the game from school or something and would not be able
to play if it were not webbased.
4) People don't seem to be too happy about graphics and like Cantr
partly because it is an old-fashioned text-based game. (Which was
actually never my intention, but just necessity, so it's kind of odd
that this is restricting me now.)
Now, where I am gradually changing my mind is that the main reason for
2.0, namely that what I want is not possible in 1.0, might not hold as
much as I used to think. And it is exactly this that I intend to work
towards: implementing the ideas I had for 2.0 in the current
interface. This avoids problem 3, it makes developing it part of
problem 2, it makes it less daunting (solving problem 1), and I think
it will be possible to leave most if not all of it text-based (problem
4). (In fact, I would try to make the graphics more or less optional,
but still possible.)
The approach I take in this is to write it in such a way that later on
it would be possible to write a standalone client in addition to the
web interface, so we can have both. But that is definitely long long
term and not the main target right now.
How is this done? What I am working on at the moment is rewriting the
Cantr server. The server is now written as a standalone process that
keeps running permanently on the server and that handles all
server-side scheduled tasks. Currently it updates our clock, sets our
timeleft value, and decreases tiredness on a daily basis - the rest is
still done by the old server scripts. But I am far progressed with
implementing the sailing functionality in the new server and after
that will continue with animals. At a next stage, we can implement
other kinds of functionality in the server and have the web scripts
for the web client communicate with this server to gather its data.
This would allow us to keep some often used information in working
memory as opposed to reading them from the harddisk everytime when it
is needed (which is slow).
The most important difference between 2.0 and 1.0 was going to be how
walking works and how locations are interpreted. Currently, we have a
set of locations, with set roads between them, which you can follow to
reach other locations. This was implemented because I saw no other way
of implementing a large world in a reasonably sized database.
Nowadays, I see better ways. What I would really like to see is that
characters (and animals, vehicles, etc.) could walk freely on the map,
without being restricted to the roads. This would also mean they can
build anywhere, drop goods anywhere, dig for resources anywhere, etc.
The advantages would be: more 'natural' development of settlements;
more exploratory approach to finding resources; more interesting types
of borders between states (instead of just one location=one state).
Disadvantages might be that the world will be rather big relative to
the population size and that the character of the game changes rather
dramatically (but, I think, for the better).
Current locations would simply become stones planted somewhere stating
the name of the area. Characters can remove such stones, or place new
ones anywhere (of course this should take time and should be very
visible to others, so people can stop that person). Thus, people can
create their own location names, their own locations, etc. The
locations (these stones) will still have a major function in that we
can make it that a traveller will automatically stop (or choose to do
so) whenever (s)he is near a location stone. So a player can say
'travel in direction 300 until you are near a location stone'. Walking
directions one could set by either entering a direction in degrees
(necessary for the text-based approach) or by using a map, where you
click on a cell and the direction you are going is the direction of
that cell relative to the cell you're on (the more graphical and nicer
approach). The old roads should also still work that you can just
follow them until the next location. So this free walking does not
necessarily replace the old one, but will be in addition to it. A
problem to be worked out, however, is how it then works for roads
created by the player, over different routes than those currently
existing, but that is not of immediate concern.
I would like to already implement the animals as walking around
freely. The animals would just be visible on a location whenever they
are near. This would be a nice way perhaps for us to experiment with
this free walking idea without altering much of the interface. It
would also mean, however, that a large percentage of the animals would
be basically invisible / out of reach, which would perhaps reduce the
animal population too much for those areas where people are dependent
on meat for their food. But I don't think this is the case in many
areas. But I think the animals would be the right place to start for a
gradual transfer to free walking.
The next step would be the placement of raw materials. This would have
to be in place before characters can walk freely, and this new system
of placement would work perfectly fine within the current system.
Currently, raw materials are assigned to locations. Obviously, with
free walking, this won't work. Instead we can define areas on the map
where certain resources can be found. This is, in fact, probably less
work for the New Lands department than the current system, especially
for resources that can be found in large areas. For this new resources
system, we should figure out a few things before implementing it and
make a few changes at once:
1) Some resources should be of a fixed size. One area containing that
resource could have a fixed amount of that resource available and thus
this resource can be emptied. An example would be gold or oil.
2) Some resources should be planted or possible to be moved. E.g.
potatoes could be brought to other areas and planted. For this kind of
resource, we should have some wild versions occuring at random places,
and have large areas that have the potential for this resource. But it
would require preparing the land and putting the seeds to actually get
the resource. (This will also mean that land is required for farming
etc., thus land scarcity will be implemented and is a crucial element
of this whole scheme.)
3) We need to find ways to find the resources in the first place. E.g.
how does now know whether oil is available? Or should it simply be
visible when walking on the location?
Well, perhaps there are more issues. It is technically possible to
implement this all, and I think we should do it all at once because we
have to rewrite the resources system anyway. Or at least, have a clear
idea of what kind of changes we'll implement so that we write the new
code in a way that it is all possible - it doesn't all have to be
activated at the same time.
The above also relates to animals, which should eat resources on
locations where they are and where the depletion of those resources
should affect the movements or lives of those animals. That, again,
can be a later addition.
After animals can freely walk and resources can be found at random
locations, pretty much everything is in place to start working on
freely walking, which will be the biggest change to program (because
it requires many parts of the game code to be slightly altered). One
probably minor problem when changing to a free walking system is that
buildings, which are now simply attached to a location, will have to
get a precisely defined location and orientation (where's the door?).
Some will also need decisions on what is ground floor and what is up.
This will be a bit of a difficult thing to do. It would be nice to
simply have an algorithm, but would there be an algorithm that gives
reasonable positions? And to what extent can we decide as opposed to
ask players involved? But we don't have 'building ownership' as such
in the game, so who to ask? And wouldn't it be way too much work to
ask everybody about all those buildings. Anyway, so worst case is that
we have to do it manually, which first requires writing an interface
to do so, and then a load of work to place them, or we need some kind
of algorithm, which is kind of difficult. Well, perhaps they should
just be randomly distributed along the main square and the exit roads... There's different options for such an algorithm, I think.
Buildings will gradually be changed to having walls and ceiling and
floors etc. so that people can design their own models. How to do that
kind of stuff text-based instead of graphically, I don't know yet. So
far, I think, all I mentioned is possible with text only.
Now, this note is called a roadmap, but it really is the main roadmap
for as far as walking freely goes. There are of course several other
main threads in our programming, which are also very important.
Personally I will focus on the above, however, for as far as possible.
Other main projects are:
1) Babies. We still need to have everything implemented that determine
the difference between babies and grownups- e.g. the effect of being
young on how you participate in projects etc. David has done a lot of
this work, but it is unclear how far from finishing we are. I am still
waiting for someone to pick up this project again... It will be
hugely welcomed by many players, I think, if we finish this.
2) Translations. Although events are now translated, there are still
some main elements left, especially names of objecttypes and animals.
This is kind of tricky to implement, though, but has fairly high
priority. I presume this will be me cooperating with Judith to
implement it.
3) Item deterioriation. Although not high on my personal priority
list, it is high on that of many players, so it should be implemented
sometime soon. Jur is making serious progress on this and as I
understand, has run successful tests in the testing environment
already. Thus, this should be implemented soon.
4) Weather. We want weather ever since Cantr was created - I always
thought I'd implement it in one of the first weeks - and we still
don't have it. It starts to get ridiculous... It should be very
easy to implement and should add a lot to the game experience.
5) Furniture. A more minor thread, but characters should be able to
sit down or lay down and this should affect energy mainly.
Then there are more minor issues, of course. E.g. the projects table
should get an additional field stating what skill helps for that
project and this field should be set by the code wherever a project is
started or in the objecttypes table for manufacturing that type of
objects. The functionality of eating raws should be changed so that
different rawtypes can heal different states (e.g. sugar helps for
energy rather than health). And, well, I'm sure we can find a whole
list of other additional ideas (Anthony seemed to have some good ones
on the forum).
Enough for now - the basic idea of this email is clear...
Jos
P.S. Should this email be published on the forum? I actually think it should ...