Dead or on life support?
Posted: 27 Jul 2010 19:39
Whats the status of the project. I really like to help, but the project looks out of shape. Is anyone still working on it?
The place to talk about Transport Tycoon
https://www.tt-forums.net/
Coding: Definitely.matsv2011 wrote:... needing. Coding and project managing.
I knew there were contributors around...maquinista wrote:... You can use (and modify or simplify) my models.
Interesting. The numbers you mention - do they refer to your course or 'normal GNU project'? If they're GNU, where did you get them?matsv2011 wrote: ... management course was quite similar to a normal GNU project, around 40 people ...
Sort of. I know Uzurpator works on the terrain, vegetation and buildings. I don't follow it closely because my code isn't related to these things.matsv2011 wrote:... the project is not in sync. No body knows who´s doing what ...
I dont't think there are any new programmers around. Few come around here and say "Hi, anything I can help with"? It's a fact that it's not easy for an eventual new programmer to hop on - there is no roadmap, no proper documentation of the current code and status and generally this project appears pretty much dead. That's one of the main reason I began to develop my own demo app - to have something presentable for TE as fast as possible.matsv2011 wrote:... new programmers cant contribute easily. ...the the rest is watching and bench coaching
I'll think of this and get in touch.matsv2011 wrote:... do in this moment to ad to the game, what lines of cod could i write?
Well sorry, i was very unclear. I meant a normal GNU project of this size and complexity. What i mean is that a large project need more people if its a GNU project than a industrial one. Maybe around 10 people for a industrial project and 40 for a GNU. Maybe that's a little bit over exaggerate, but you probably get the point.If they're GNU, where did you get them?
That is of cause true, but then you just push the problem of interconnecting the code on the future. The longer this problem is delayed, the larger it gets.I don't follow it closely because my code isn't related to these things.
It´s not a large feat. Is really just need a couple of hours of work to manage it in the beginning. Of cause the work will grow as the project does. But if the project grows to such a scale that i cant manage it, i bet there someone else how can and will do it just as good.glad if TE was one such. If you'd like to try to manage TE, I'm all for it.
Well. That´s very true, and its not a easy task. But on the other hand, if the game is going to work, it have to be quite well designed as well.splitting the workload into smaller parts would require the game to be quite well designed
I disagree about that. That is true if you design the whole game from scratch. But there is a outer tactic that probably work better in this kind of environment. To have a flexible road-map that changes with the experiences of the coders an other involved personnel. Actually thatch the way of all research projects. If you do, like me in my every day work, some thing that nobody ever done before, then you cant follow any manual.- It takes a coder who's already done something similar, building the design based on assumptions and expectations bears a high risk
That is of cause true. But that's true anyway if you don´t plan the project. The big different if that if the project is clusters any problem can be defined in e specific set of blocks. The solution to the problem is to make a new block specific to the problem and make it a sub-block to the block the problem use to belong to. If possible, slipt the problem block in several smaller blocks. Then is possible to get a problem description.high risk that something significant is forgotten/underestimated and the result is a lot of nothing
I love to be a project coordinator. Actually i don´t really think it have to be any leader at all. Everybody can do just the task they think is the most rewarding, if just the borders between the different parts of the project is defined well.I'm not saying I won't cooperate if you lead us.
Not bad, but needs modification, dealing both content and form.matsv2011 wrote:...I make a draft project map....
http://img713.imageshack.us/img713/7848/dependancy.png
Yea, i´m thinking about just doing it bigger. Later on adding databases, GFX and SFX objects to. The picture will probobly be around 3000*3000 pixels in the end.nodes and leave more space between nodes so the deps are easier to follow.
Actually i already figured about that out. Of cause, we wana do as little coding as possible. For road, rail, trams and so in its quite easy. Just the same algorithm and just change the graphics. I think about making the same with treas. A tree and scrubs is like buildings and everything else. Buildings grow in citys, treas grows outside. It's also possible to use procedural math to make every tree (and building as well) unique without making to mutch of a problem.an essential feature is placement and removal of trees
Already included, that´s the thing about doing it that modularThings like physics, pathfinding or interaction between vehicles are secondary because they're built atop this basic functionali
I worked trow the cargo handling half way en just glanced over the finance. My idéa is to write a simple one at first, like the one i TTD, than expanding it to one more like Simutrans. If it´s a separate module this part can be developed individual without affecting the rest of the development.I'm not even mentioning things like cargo and finances
Sorry, my bad. I meant just to explain what I meant under the term of world space partitioning.Sorry, can´t find it
Designing in the top down is just one of the design philosophies. Neither good nor bad one. Has its downfalls tho. So maybe we should also consider the other direction.That´s no problem, that´s the whole point. When thing´s are designed you have to look at the big picture first and gradually go down to a lower level. The process is ongoing, if the level isn´t sufficiently detailed , just split it and go on. That´s no problem, that´s part of the whole design idea.
On the internet, everyone is a specialist.You might wana believe me about this, that is what i do for a living.
How about starting at the hard end and work your way up, easing things up? Or, starting somewhere in the middle, understand the problem domain and then design the solition naturally, so both technical constraints are taken into consideration, but without gory impelementation details obscuring the view?Of cause, it´s not very wise to start from the hard end, then its just getting harder.
Implementation requirements _always_ incur additional constraints on the design.Of cause it does, that´s the whole point, its part of the render engine. Of cause, its possible to split it up if needed.
Instancing and batching place certain constraints on the design of the game world. If you omit them now, then you'll end up with a ton of workarounds for problems which those constraints place.The thing is that instancing doesn´t relay have to much to do with economics, and economics with routing, and routing with with landscaping and so on.
This _never_ works.The whole design idea is to disconnect everything and run it separately.
PM orudge. He should make you an account.I don´t have a account for the moment.
Firstly, we already know the high and medium level requirements. The software structure is also more or less known. What is required is someone, who is not me, that also has that knowledge and can route required software tasks to other coders.Well, firstly i will develop a plan in LESS detail, than maybe more detail... then i hope a lot of people can help develop it in minuscule detail.
Well, with the risk of sounding negative, bottom up isn´t really a design philosophy, more of a design by accident.So maybe we should also consider the other direction.
A database is a database what ever you wana call it. I call it a database because that is what it is. I didn´t dismiss anything. Start micromanaging to begin with is always wrong. The project is in its infancy what every you want to believe. I would bother more about your credibility than my about management.your credibility drops sharply when you start talking about databases
because it does´t work that way, If you start in the hard end it will only get harder. Well off cause, it will become harder in the easy end to, but then you end up were you began in the first place.How about starting at the hard end and work your way up, easing things up?
Then you just fool yourself believing you solving the problem while actually creating a top down project inside of a bottom up.Or, starting somewhere in the middle, understand the problem domain and then design the solition naturally
There is no problem considering technical limitation in a top down philosophy, actually, quite in contrary, that´s the only way all limitation is visible from the beginning. The whole point of design trees is to make every detail generic, thow obscuring the view, making it possible to think out side the box. Sounds like managing mombojombo? Well it kind of is, but it works. Its not about doing what feels the best, but do what actually works.so both technical constraints are taken into consideration, but without gory impelementation details obscuring the view?
That is exactly why every detail is limited by boundary, thow making boundary's in the limitation.Implementation requirements _always_ incur additional constraints on the design.
With bottom up, yes, top down, no, then you can simply ignore them, no rework needed.Instancing and batching place certain constraints on the design of the game world. If you omit them now, then you'll end up with a ton of workarounds for problems which those constraints place.
That´s exactly why top down is to prefer, because then you can treat every object in a optimal fashion for the different process. I have a problem with how you thing, your seems only to be concerned about graphics.It is wise to design an uniform way of displaying trees and buildings that will separate those classes of objects from themselves. At the same time most trees can be efficiently rendered using shader branching and exploting the cellular nature of the game.
Well, have you actually thought about that before you wrote that?Notice also that towns and forests interact with the player differently, thus constraints we placed will have ramifications in the complete gameplay.
It does work, because I have tried it, its actually how all big software projects work. Well, of cause, its not the solution to everything, but it help progress along quite nicely. At a point, the blocks have to be interconnected and run in larger blocks and larger. Well, how do you know it don´t work, have you tryed it?This _never_ works.
What you really are saying is that you actually don´t know anything. You cant route workloads with out proper planing, it don´t work. Well, try it all you like, it wont work.Firstly, we already know the high and medium level requirements. The software structure is also more or less known. What is required is someone, who is not me, that also has that knowledge and can route required software tasks to other coders.
Well. Synthesis is a design philosophy. Your personal opinion on the subject does not invalidate that. It has its downfalls, just like analysis does. My point is not to solely use synthesis. My point is not to use solely analysis. Which you seem to propose.matsv2011 wrote:Well, with the risk of sounding negative, bottom up isn´t really a design philosophy, more of a design by accident.
Honestly. I have never seen industrial project being run bottom-up. Neither i have seen a project being run top down. The most successful project I have worked in (as a designer, imagine that), was being designed from both ends at the same time.Most project i seen that claim they use a bottom up philosophy actually run a broken and poorly managed top down. I most cases there actually is some kind of top administration, i.e. delegation of graphics, code and sound. I Never seen a example of a multi person project with a successful bottom up philosophy, and I can really find any example of it at all. Well of cause a bottom up can be used in a block of top down project. Most people tend to wana use bottom up because its easier to start with, and of cause, in small project bottom up is quite easy in total.
Don't manipulate the quotes. Strawman does not an argument create.A database is a database what ever you wana call it. I call it a database because that is what it is. I didn´t dismiss anything. Start micromanaging to begin with is always wrong. The project is in its infancy what every you want to believe. I would bother more about your credibility than my about management.your credibility drops sharply when you start talking about databases
It is mumbo-jumbo. Phrase this better, because it sounds like some sort of dogma.There is no problem considering technical limitation in a top down philosophy, actually, quite in contrary, that´s the only way all limitation is visible from the beginning. The whole point of design trees is to make every detail generic, thow obscuring the view, making it possible to think out side the box. Sounds like managing mombojombo? Well it kind of is, but it works. Its not about doing what feels the best, but do what actually works.
With synthesis, i know i need physics, eco, routing etc. Since i don't know what the clients of these modules will demand, i need to go up from the bottom and design the client of the engine. At the same time tho someone else can design the interior of the module. With analysis the problem is reversed. A module does not know what kind of functionality can be used, thus providers of these functionalities need to be designed.What does the physics engine demand? What does the economics engine demand? What does the routing engine demand? With bottom up, you don´t actually know to your finished. With top down, its easily divided and is possible to simply decided it.
Justify, using my example.With bottom up, yes, top down, no, then you can simply ignore them, no rework needed.Instancing and batching place certain constraints on the design of the game world. If you omit them now, then you'll end up with a ton of workarounds for problems which those constraints place.
Justify, using my example.That´s exactly why top down is to prefer, because then you can treat every object in a optimal fashion for the different process.It is wise to design an uniform way of displaying trees and buildings that will separate those classes of objects from themselves. At the same time most trees can be efficiently rendered using shader branching and exploting the cellular nature of the game.
Would my reasoning be any different if we were talking about, say, economy of the game? or physics? Or maybe you want to imply, that in order to prove my point I'd need to provide examples from each possible game module?I have a problem with how you thing, your seems only to be concerned about graphics.
yesWell, have you actually thought about that before you wrote that?
Yes.Well, how do you know it don´t work, have you tryed it?
I could've sworn, that is precisely not what I said.What you really are saying is that you actually don´t know anything.
I can route workloads. I just don't want to manage this project. Management and design are to distinctively different things tho.You cant route workloads with out proper planing, it don´t work. Well, try it all you like, it wont work.
I have never claimed to be a manager of TE.Im I hard? Maybe, but do you want to know the touth or not?
You might be a great coder, I don´t doubt that, Im a very bad coder, I know that, I never clam anything different. Its not your coding skill that's the problem, its the managing skills.
Its might be a a TD contained in a BU or a BU contained in a TD, or a TD contained in a BU contained in a TD. The to later one works just fine, but its always a TD at the outer most level, that's what i´m talking about.was being designed from both ends at the same time
I cut it, i did´t edit it in any way (just reconfirmed that). You statement sounds somewhat unfriendly.Don't manipulate the quotes.
Well, i let Wikipedia do the job for me, because that the page was fairly well written.Phrase this better, because it sounds like some sort of dogma.
How could that be possible if there is no plan, no interface, no interconnection, no specification... ?At the same time tho someone else can design the interior of the module
Actually, the complete opposite is true. You know, because its decided. Maybe not flexible nor innovative, but very effective.A module does not know what kind of functionality can be used
You seems to misunderstood me completely. I´m not talking about the graphics, sound, economy, routing, what i´m talking about is the survey of the complete game, not a single module. The modules is just a way to "eat the elephant".Or maybe you want to imply, that in order to prove my point I'd need to provide examples from each possible game module?/
Actually, then you realty just contained your Synthesis inside a top down analysis. I have no problem with that, actually that´s what i think is the right way to do it. What i think is its not documented well sufficient. Of cause, all programmers hate documentation, most clam it´s not necessary, that don´t make it any less true.Well, have you actually thought about that before you wrote that?
yes
And you still clam its not possible? I´ll bet you, no scientist make that claim.Yes.
Sorry, it shod be figurativeI could've sworn, that is precisely not what I said.
I agree with that.Management and design are to distinctively different things tho.
Well, maybe with some documentation.I can route workloads
[/quote]I have never claimed to be a manager of TE.