The Wiki?

[Lilman424]

I just registered on the TE Wiki, for I am big fan of Wikis, having been an active Wikipedian for a good 3 or 4 months. However, after registering I realized that the Wiki is pretty much non-existant. There seems to only be a draft of a couple design documents that haven't been touched since July and that's about it.

What I'm wondering is
A.) Is a wiki wanted/needed at this time? While wikis are very useful, especially for ease of finding things and for quickly changing things, one may not be needed too much now, since there's not much visible progress, nor is it coming very fast.

If yes,
B.) What sort of format do we want the wiki to be? Should it be a strict and professional sort like Wikipedia, or something more loose, where comments can be placed on the page itself, right where they apply?

[Steve]

Are you kidding me?

We're keeping the goddamn wiki.

http://tempire.phoenixscripts.co.uk/wik ... n_Document
Tells you how to use the DD bit.

[Lilman424]

Steve, i know we're keeping it. perhaps i should rephrase that.

A.) Is a wiki wanted/needed at this time? That is, is it worth trying RIGHT NOW to develop it?

[aarona]

I'm not having a go at you (directly) Lilman424, but I've noticed these words before from other people too...

"at this time" and "right now"

[rant]
Why is the attitude here that things should be done later? Why is it never the time for this or that?

The time for gathering of models is NOW.
The time for completing the DD is NOW.
The time for gathering data is NOW.
There is nothing which should be put off.

This project will continue on its slow and painful journey the more people put things off...I feel that I have missed the punchline of an in-joke on this forum. I suspect that people don't really want to finish this game. Do people just want to think about what such a game might be like and discuss it, because the sense of community is more important than the end result?
[/rant]

Do we need a meeting to kick-start this again?
Where is Hyronymus?

Is this obligatory December slow period?
BTW, nice to see you again Steve.

[Hyronymus]

I'm here aarona but I'm lost at this moment as what to do.

[Purno]

Ok, since Hyro's lost, and me too actually, I just keep thinking loudly;

I think we need some code as a base. I think it's now up to the coders to make something, I don't care what ATM, as long as it's something we can comment on. Once we have some code, we'll get additional things to put on the wiki and such. I think the coders know quite well what we want as basics. Such as, we want trains and trees, that's for sure. (Correct me if I'm wrong tho.)

I think the coders should ask us questions they run into when coding, in stead of us thinking about what the coders (eventually) should do.

But, that might be the wrong approach. Anyone who knows what to do, tell us

[Hyronymus]

And tell us here, not on IRC.

[eis_os]

Todo list:

1) Write a map/heightmap class that stores information by tile (I hope you decided on the internal scale finally), create some basic load and save function. (nothing fancy, no compression, simple binary stream data, this can be used later in the savegame/loadgame function to store the whole thing in a right savegame)
2) Write a terrain engine that can use the data from 1
3) Write a object loader, let the terrain engine of 2 display the objects.
4) Writa a bare bone vehicle class that has a object (like a car, train, whatever), let the engine display it.
5) Write a basic gui/console to control loading saveing, the vehicle class.

as you see with 1) you need to decide finally how scales work, and how the damn landscape should be stored and what it need to be stored.

PS: You asked for it, I hope this rough way of writeing helps a bit...

[aarona]

As I see it, the game logic is the extremely easy part of it and thats great! The hard part is going to be the graphics side of it. In fact, the game logic could be started right now, so why don't we? The danger is that the graphics and logic wont line up. Which is why the graphics need to be done first and we need to see things happen as they happen. (Maybe other coders have different ideas but this has been my experience, time after time)

If I could ask for anything to get started it would be the following.

1. Model of a train
2. Model of train tracks
[Stage 1]

3. Model of coal loader station
4. Model of coal unloader station
[Stage 2]

5. Model of coal wagons
[Stage 3]

Summary:
[Stage 1]
The first step is to lay some tracks and to show that a train can travel on these tracks, and it looks reasonable. (This will not be a trivial task. It will certainly be impossible without the graphics)

[Stage 2]
By having stations we now define the end points and can show that a train can travel between the two, obeying correct speeding up and slowing down rules etc. (This will be more easy to accomplish, it could be done without the graphics)

[Stage 3]
By enabling the loading and unloading of wagons we can show that we have an in-principle working model. (Again, this may not need graphics)

Without the following it would almost be impossible to get started because you need something to work with. One could work with white boxes which hopefully replicate where the objects would be, but whats the point if you have to change it all when the models arrive?

Let's be realistic here, there is very little chance of planning every little detail such that there never needs to be a code rewrite in the future.

The point I am trying to make is that we need resources. You cannot expect the coders to come up with something without these resources because how can you "see" what we have done, and how do you know it will work...

[eis_os]

Well the logic part isn't that much of a problem, but as I said earlier you need to do have some barebones, to calculate the distance you need to actually know some part of the internal scale.

Doing logic isn't the problem, doing it fast, low memory consumeing and without bugs is the most challengeing stuff. But it will be quite boring to look at 1000 trains in a console window, you want to see them ingame, even if that means they are represented with bad or broken or box models, atleast then people who are not coders can start to find logic bugs aswell...

[aarona]

I didn't see your post when I wrote mine but yes I completely agree with you. Of course what you said is more for the coders.

[Lilman424]

aarona: i certainly understand where you're coming from with the time issue, but the problem with Wikis is that, to use a transport metaphor, they are not producing industries, but middlemen. Wiki's don't necessarily produce anything, just pull it together and disseminate information. I used the the phrase "at this time" and the like because i don't know if there is enough information right now to justify a lot of work on the wiki.

[XeryusTC]

Todo list:

1) Write a map/heightmap class that stores information by tile (I hope you decided on the internal scale finally), create some basic load and save function. (nothing fancy, no compression, simple binary stream data, this can be used later in the savegame/loadgame function to store the whole thing in a right savegame)
2) Write a terrain engine that can use the data from 1
3) Write a object loader, let the terrain engine of 2 display the objects.
4) Writa a bare bone vehicle class that has a object (like a car, train, whatever), let the engine display it.
5) Write a basic gui/console to control loading saveing, the vehicle class.

Point 2 and 3 are part of TRoS, part 1 and 5 can be easily implemented by using TRoS.

And we don't need graphics to start working on the logic, the graphics are the method to present the logic to the user, not the other way around. We just need someone who is willing to convert the TRoS Makefiles to the new directory layout, I've done the MSVS files already but I don't have a good understanding of Makefiles