Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Wed Dec 12, 2018 2:04 am

All times are UTC




Post new topic  Reply to topic  [ 41 posts ]  Go to page 1 2 3 Next
Author Message
 Post subject: Dead or on life support?
PostPosted: Tue Jul 27, 2010 7:39 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
Whats the status of the project. I really like to help, but the project looks out of shape. Is anyone still working on it?


Top
   
PostPosted: Wed Jul 28, 2010 10:57 am 
Offline
Engineer
Engineer
User avatar

Joined: Mon Aug 27, 2007 6:46 pm
Posts: 97
Location: mapy.cz/?query=rajhrad
Hello Matsv.

Thanks for showing interest in this project. It really seems quite dead, but there are few who are still slowly working on it or are willing to help if they're contacted.

First, there's Uzurpator, currently the only active coder. He's working on a terrain code and perhaps some general stuff like resource management, I haven't looked in a while. He rarely checks this forum, so send him a PM if you want to talk to him. You can get the code at svn.transportempire.com SVN repo.

Then, there's me. I'm currently learning the OGRE engine and working on a small sandbox app where I test track implementation. It's not done yet, so I'm not presenting it anywhere. I'll PM you with details.

Finally, there's Lonwolf. He's currently inactive because his attempt to rewrite TE from scratch wasn't too well accepted, but I'm sure he'd be interested to work on my current code if I called him.

That's it for programming. Yep, we really need help in this area, since currently it's the only thing which can push this project towards.

As for graphics, there are many talented Blender artists around this forum and some of them already showed interest in TE in the past. But since the codebase is in so early stage of development, there was no use for their inputs, so they stopped working. But I'm sure they hadn't lost their interest and will contribute again if some workable code appears.

Note TE also has a website at transportempire.com. It's pretty outdated and has a quite poor design. I'm planning to do a major revamp once my code starts working.

Cheers
~An00biS

_________________
[Update Aug 2013] FlexRails track buiding demo coming soon!


Top
   
PostPosted: Wed Jul 28, 2010 9:59 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
I see 2 things the project seems to be needing. Coding and project managing.

Sure GFX and SFX is needed in some point.

I was looking at blender game engine, it look to be realy easy to code for.

I can do a couple of things:
Project managing (because is a big part of my engineering degree)
Building modeling (It to is a part of my degree)
Data handling an processing
Engineering/Math/Physics
Scripting (not complex programing)


Top
   
PostPosted: Thu Jul 29, 2010 2:39 pm 
Offline
Engineer
Engineer
User avatar

Joined: Mon Aug 27, 2007 6:46 pm
Posts: 97
Location: mapy.cz/?query=rajhrad
matsv2011 wrote:
... needing. Coding and project managing.

Coding: Definitely.
Managing: Maybe. I've had some classes on managing projects too, but they dealt mainly with larger enterprise stuff, I don't really think those practices would help TE. But I would like to hear what particular actions do you have in mind.

As for skills, I'm a moderate C++ coder. I've been programming for several years but not too frequently, as school projects mostly required other languages. I can also do a little modelling in blender, nothing much, but enough to create simple game models. I've already made a few houses, one loco and one waggon and I exported it to OGRE format to experiment with it.

I really don't think Blender game engine is appropriate for this project. It's a simplistic thing, closely integrated with the modelling capabilities of blender, made for easy composing games using the GUI and python scripts. The problem is: it's easy and fun at the beginning, but when you get deeper into the game, you begin to bump into the limited capabilities. Engines which contain a lot of automated/integrated stuff use to have internal relations and dependencies which start to get in your way when you want to perform more complex tasks. Also I don't think it's performance is enough for a stategy game. An FPS or racing game would sure be fine, but real-time strategy is too much.
On the other hand, OGRE, which Uzurpator and myself are using, is a bare, industrial-strength C++ library for 3d graphics. It's not a game engine, there's nothing integrated, not even an input system. This means some more coding has to be done, but the coder has a complete control over anything, so the possibilities of the program are unlimited. And, some TE code has already been written with it.

~An00biS

_________________
[Update Aug 2013] FlexRails track buiding demo coming soon!


Top
   
PostPosted: Mon Aug 02, 2010 2:24 pm 
Offline
Tycoon
Tycoon

Joined: Mon Jul 10, 2006 12:43 am
Posts: 1808
Location: Spain
If You need train models, You can use (and modify or simplify) my models.

_________________
Sorry if my english is too poor, I want learn it, but it isn't too easy.


Top
   
PostPosted: Mon Aug 02, 2010 3:49 pm 
Offline
Engineer
Engineer
User avatar

Joined: Mon Aug 27, 2007 6:46 pm
Posts: 97
Location: mapy.cz/?query=rajhrad
maquinista wrote:
... You can use (and modify or simplify) my models.

I knew there were contributors around... :))
Thanks, Maquinista, I will, just when the program is capable of displaying a train (it'll take a while, but it's already on the horizon).

_________________
[Update Aug 2013] FlexRails track buiding demo coming soon!


Top
   
PostPosted: Tue Aug 03, 2010 9:54 am 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
Management
"managing projects too, but they dealt mainly with larger enterprise stuff"

Actually, despite that i´m an electronics engineer, in my education the large project course was in software, probably because is easier making a software course rather than an hardware course. The programing management course was quite similar to a normal GNU project, around 40 people involved everyone just writing one or two packages with as little as 10-15 lines of code.

To me it´s quite obvious that the project is not in sync. No body knows who´s doing what, end how is suppose to do what. I think its quite easy, if no one know´s what to be done, noting is getting done.

It sounds like harsh words, but it´s looks like the project is going to crash. A related problem is that new programmers cant contribute easily. A couple of hardcore programmers is doing all the work wile the rest is watching and bench coaching, making the process complicated and slow.

Here management could do a lot. Spreading the workload and making sure that the most effective programmer doing etch and every part, making cooperation more effective.

Every large project is like eating an elephant. How do you eat a elephant? A little piece at e time! And the larger number of people how can eat, the faster it gets. Have no doubt about it, making a game is a huge project.

The better management the more people can work effectively at the same time.

I believe we need at least 5 coders. (2 graphics coder, 2 main-block coder, 2 script interface coder and 1 sound an fx coder). Off cause, one person can have several roles, but for the large part 2 coders are needed to make the code high quality.

Additional around 5 scripters and mathematicians making game logic ruining smooth and the physics realistic. Off loading all the havy math from the programmers.

A secondary great part about management is that skilled coders can be replaced with semiskilled coders. More can be done faster with greater quality.

..... further on....
I really have no opinion about blender, just seems like a easy to do game engine. You might be right.

"but the coder has a complete control over anything"
That´s true, but that makes managing the project more important than ever.

Modeling and graphics
My opinion about this part is that projects tend to lose focus if they get to far in to the future. Modeling and graphics is great, its needed, in abundance, but getting it involved in a to early is risky an can get the coding part of the project losing speed.

My opinion is that the programing part of the project shod be around 80-90% finished before advanced graphics be imported. Off course the GFX programers have to use advanced graphics to test performance, but in my opinion the logic and game play mechanics shod be done mostly with just simple geometrical objects making easier to have a over all view of the project.

Of course when the time is right, we can call on all the 3D artist and the SFX modelers to make there part making a lot of 3d models and making the game look ultra realistic.

Sum it up
Managing the project could get the project going much faster, improving quality, and involving more and lesser skilled persons lowering the workload of the already involved coders.

Making my point, om not really a programmer, but if i was:
What could i do in this moment to ad to the game, what lines of cod could i write?


Top
   
PostPosted: Tue Aug 03, 2010 2:14 pm 
Offline
Engineer
Engineer
User avatar

Joined: Mon Aug 27, 2007 6:46 pm
Posts: 97
Location: mapy.cz/?query=rajhrad
matsv2011 wrote:
... management course was quite similar to a normal GNU project, around 40 people ...

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:
... the project is not in sync. No body knows who´s doing what ...

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.
As for me, I didn't tell anybody I worked on anything because I don't like talking about projects which just started - I never know how they work out.

matsv2011 wrote:
... new programmers cant contribute easily. ...the the rest is watching and bench coaching

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:
... do in this moment to ad to the game, what lines of cod could i write?

I'll think of this and get in touch.

In general, I know what are the benefits of a well managed project and I'll be glad if TE was one such. If you'd like to try to manage TE, I'm all for it. I'm just a little sceptical about how it'll actually work out. the problem is that working the way you present it, i.e. splitting the workload into smaller parts would require the game to be quite well designed, and not everyone can do that - It takes a coder who's already done something similar, building the design based on assumptions and expectations bears a high risk that something significant is forgotten/underestimated and the result is a lot of nothing. However, this is just a minor general concern, I'm not saying I won't cooperate if you lead us.

~An00biS

_________________
[Update Aug 2013] FlexRails track buiding demo coming soon!


Top
   
PostPosted: Wed Aug 04, 2010 12:26 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
Quote:
If they're GNU, where did you get them?

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.

Quote:
I don't follow it closely because my code isn't related to these things.

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 bet that every line of code written of today have to be re written. That´s really not a huge problem but it will be if the project get a lot larger.

Quote:
glad if TE was one such. If you'd like to try to manage TE, I'm all for it.

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.

Quote:
splitting the workload into smaller parts would require the game to be quite well designed

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.

Quote:
- It takes a coder who's already done something similar, building the design based on assumptions and expectations bears a high risk

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.

Quote:
high risk that something significant is forgotten/underestimated and the result is a lot of nothing

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.

Every problem can be broken down to a core problem. The core problem is usually very small, taking about just e few lines of code. If it just can be broken down, the problem most offend can be solved in e easy matter, the issue usually just about breaking down the problem.

The great thing about this is the rest can continue working not caring about the problem, but they can simultaneously help with the problem if its correctly broken down. A lot more people can understand the problem, making it more likely that the problem getting solved quickly.

Quote:
I'm not saying I won't cooperate if you lead us.

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 think TE can be the best GNU game ever, and even outclass any commercial game. If everyone can agree on working as a team. Everybody can make there on part and be proved about it.

I make a draft project map....
http://img713.imageshack.us/img713/7848/dependancy.png


Top
   
PostPosted: Fri Aug 06, 2010 11:09 am 
Offline
Engineer
Engineer
User avatar

Joined: Mon Aug 27, 2007 6:46 pm
Posts: 97
Location: mapy.cz/?query=rajhrad
Allright, let's get this project organized then.

matsv2011 wrote:

Not bad, but needs modification, dealing both content and form.

As for form, the graph is quite difficult to read because there's a lot of dependency-lines, some of which are overlapped by the nodes. Let's use smaller fonts in the nodes and leave more space between nodes so the deps are easier to follow. Coloring the deps could help, too.

As for content, two things must be taken into account:
  • Priorities of features. For instance, an essential feature is placement and removal of trees. Everybody expects this. However, tree growth and multiplication is, by nature, an additional feature, because it's built on top of the basic functionality described earlier. Also, not everyone cares about it - for instance, I don't like tree growth in games. That's why things like this should be secondary without any things depending on them.
  • The functionality should be decomposed and arranged into layers. This is because many features are technically built atop of another, and we should use this to our advantage. For example, an essential feature is: Trains follow their track at a constant speed and query routing information on crossings. The API allows to place a train on track, adjust it's speed, provide means to query routing data, and remove the train from track. This is the bare bone of train implementation. Things like physics, pathfinding or interaction between vehicles are secondary because they're built atop this basic functionality. Physics is just adjusting the vehicle's speed, so is waiting on signals or breakdowns. Pathfinding is just feeding routing info to the train when it asks. I'm not even mentioning things like cargo and finances, those are yet another layer.

Here are my drafts, which deal with my current work (just tracks and vehicles). I'll ask Uzurpator to bring his own and we'll merge them to create a final doc.
Roadmap draft (partial):
  • Create an universal track implementation using Bezier curves (done)
  • Create a basic track vehicle, which can follow the track. (in work ~ 65%)
  • Add visual representation of the track vehicle. (in work ~80%)
  • Write code which renders the track.
  • Handle implicit interactions among vehicles (rail crossing, tram tracks on road.)
  • Handle routing vehicles (giving orders, pathfinding, waypoints, manual routing data).
  • Vehicle physics
  • Integrate GUI library
  • Build a track-construction API
  • Design a vehicle file format.
  • Integrate a vehicle loading and management system.
  • Create a vehicle management GUI
To be resolved:
  • Coding style (!)
  • Pathfinding
  • Physics
  • Vehicle format (general resource loading)
  • Track construction (survey mode solution)

So much from me at the moment.
~An00biS
Edit: added 'track construction' to list.

_________________
[Update Aug 2013] FlexRails track buiding demo coming soon!


Top
   
PostPosted: Fri Aug 06, 2010 9:39 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
Quote:
nodes and leave more space between nodes so the deps are easier to follow.


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.


Quote:
an essential feature is placement and removal of trees

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.

They key is that every square (or area if not using square) just having a couple of parameters. Date of creation and what it is. That´s the only thing the game engine needs to know. Then a plug in tho the graphics engine calculate the size position and defects depending on algorithms making it look random but exactly the same every time just aging. Because all this is handeld in the GFX department, we don´t have to care about it unless we develop GFX.

My idea is theres only 3 databases. 1 landscape, 1road network and 1 objects. If you wan to change the landscape (or the computer wana do it), just take a tool and write to the landscape database. The GFX the read from the database and change the landscape. The rood network and objects can work exactly in the same way, making it possible to recycle some code.

This is already included in the graph

Quote:
Things like physics, pathfinding or interaction between vehicles are secondary because they're built atop this basic functionali

Already included, that´s the thing about doing it that modular

Quote:
I'm not even mentioning things like cargo and finances

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.

With a generic Track/Landscape/vehicle database i guess it shod be possible to use the same API and GUI to manipulate in the databases. What i´m thinking of is treating everything the same, writing the code for vehicle just recycling it for landscape and Track. My thinking:

There is a vehicle at X,Y,Z heading in angel Xa and Ya at speed V, its a model A1
There is a roadway at X,Y,Z heading in angel Xa and Ya, it have no speed, its model B2
There is a tree/building/eye-candy at X,Y,Z heading in angel Xa and Ya, it have no speed, its model C3

When i model 3D i usually use a short bit of roadway (rail or asphalt), than i just iterate it in a length of a vector. As log as the model is exactly orthogonal to the vector, it looks perfect, my GPU can handle several 1000nds blocks with realistic rail with no problem, and its 4 years old. Zooming out the blocks can be replaced with just squerd textured ones, or intermediate textured syls with block rails.

There fore its not neaded any code rendering anything else than vehicles and ground, everything is just objects.

Same thing. If you wana plant a tree. Just write in the database. If you wana buy a train, just writ in the database, if you wana build a rail, just write in the database. If you wana modify the landscape, just write in the database.

Well of cause it need some math to work out how the database shod work, only programed C, note C++, but i use to program Java, and from what i heard its quite similar to C++ with integrated database functions (hopefully)

Because we have a deficiency in the quantity of the coders, i think we have to use the one we have at a absolute optimum, breaking out a lot of the coding to external math.

[EDIT by uzu]
Short additional question:
How many coders are available for TE at this moment?


Top
   
PostPosted: Sun Aug 08, 2010 6:53 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2131
Location: Wroclaw, Poland / Katowice, Poland
matsv2011: Edit your posts. Don't double post :)

Anyway. You need just 1 database - the global space partitioning database ( read: how are cells assigned/transferred to different game "manager" entities). All other data should be encapsulated within a manager objects.

Manager object is an entity which implements one "cluster" of game objects. For an example - town is an example object, forest is etc.

Next problem - you are designing from a veeery high level, where everything is easy. Does your design take topics such as efficient instancing, batching into mind? Because, like it or not, your game needs to take those gory details into mind.

Anyhow - I will monitor where this is going, and join in as a coder, once I see that it is going into right direction.
Anyhow2 - svn://svn.transportempire.com/trunk/transport_empire_4 is the current trunk. Please skim through the code, and maybe we can discuss more important details on irc/forum somday.
Anyhow3 - I visit the forums daily, so don't hesitate to PM me.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
PostPosted: Sun Aug 08, 2010 11:21 pm 
Offline
Tycoon
Tycoon

Joined: Mon Jul 10, 2006 12:43 am
Posts: 1808
Location: Spain
One question: Do You need road sprites? I have some sprites that could be useful.

_________________
Sorry if my english is too poor, I want learn it, but it isn't too easy.


Top
   
PostPosted: Mon Aug 09, 2010 4:27 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
"read: how are cells assigned/transferred to different game "manager" entities"
Sorry, can´t find it

"Next problem - you are designing from a veeery high level"
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. You might wana believe me about this, that is what i do for a living.
"where everything is easy."
Of cause, it´s not very wise to start from the hard end, then its just getting harder.

"Does your design take topics such as efficient instancing, batching into mind?"
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. 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. But they are all connected at some point. The whole design idea is to disconnect everything and run it separately.

Actually now when a think about it, the graph i written is way to complex to start with, i´ll make a new one later on.

"Anyhow2"
I don´t have a account for the moment.

"Anyhow3"
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.

What i was talking about An00biS before, i work´t with a lot of medium and small industrial project in my line of work, thow no dedicated software project but a lot of close interconnect hardware/software project. But from a project coordination point of view its really no difference between software, hardware, mechanical, civil or social projects. Actually in a telecommunication project hardware, software and mechanics is often equally important. Ironically the hardware company i work on is actually in sales turns a software company and is rated as the 5 largest in the world in sales.


Top
   
PostPosted: Mon Aug 09, 2010 7:09 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2131
Location: Wroclaw, Poland / Katowice, Poland
matsv2011:

Please, use the quote tags. They make reading your posts much easier.

Quote:
Sorry, can´t find it


Sorry, my bad. I meant just to explain what I meant under the term of world space partitioning.

Quote:
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.


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.

Anyhow - your credibility drops sharply when you start talking about databases and, at the same time, dismiss other implementation topics.

Quote:
You might wana believe me about this, that is what i do for a living.


On the internet, everyone is a specialist.

Quote:
Of cause, it´s not very wise to start from the hard end, then its just getting harder.


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?

Quote:
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.

Implementation requirements _always_ incur additional constraints on the design.

Quote:
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.


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.
Example: buildings and trees are two distinctively different objects, most likely will use different fragment/vertex/geometry programs and different textures. 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.

Ergo - it is wise to group buildings and trees in an entities which cluster them togather. Forests for trees and Towns for buildings.

Notice that forest and town are actual high level design objects, that just were constrained by low level requirements. Notice also that towns and forests interact with the player differently, thus constraints we placed will have ramifications in the complete gameplay.

Quote:
The whole design idea is to disconnect everything and run it separately.


This _never_ works.

Quote:
I don´t have a account for the moment.


PM orudge. He should make you an account.

Quote:
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.


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.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
PostPosted: Tue Aug 10, 2010 3:49 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
Quote:
So maybe we should also consider the other direction.


Well, with the risk of sounding negative, bottom up isn´t really a design philosophy, more of a design by accident.

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.

Quote:
your credibility drops sharply when you start talking about databases

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.

Quote:
How about starting at the hard end and work your way up, easing things up?

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.

Quote:
Or, starting somewhere in the middle, understand the problem domain and then design the solition naturally

Then you just fool yourself believing you solving the problem while actually creating a top down project inside of a bottom up.

Quote:
so both technical constraints are taken into consideration, but without gory impelementation details obscuring the view?

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.

Quote:
Implementation requirements _always_ incur additional constraints on the design.

That is exactly why every detail is limited by boundary, thow making boundary's in the limitation.

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.

Quote:
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.

With bottom up, yes, top down, no, then you can simply ignore them, no rework needed.

Quote:
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.

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.
Quote:
Notice also that towns and forests interact with the player differently, thus constraints we placed will have ramifications in the complete gameplay.

Well, have you actually thought about that before you wrote that?

Quote:
This _never_ works.

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?

Quote:
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.


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.

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.


Top
   
PostPosted: Tue Aug 10, 2010 5:57 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2131
Location: Wroclaw, Poland / Katowice, Poland
matsv2011 wrote:
Well, with the risk of sounding negative, bottom up isn´t really a design philosophy, more of a design by accident.


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.

Quote:
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.


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.

Quote:
Quote:
your credibility drops sharply when you start talking about databases

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.


Don't manipulate the quotes. Strawman does not an argument create.

Quote:
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.


It is mumbo-jumbo. Phrase this better, because it sounds like some sort of dogma.

Quote:
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.


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.

Quote:
Quote:
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.

With bottom up, yes, top down, no, then you can simply ignore them, no rework needed.


Justify, using my example.

Quote:
Quote:
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.

That´s exactly why top down is to prefer, because then you can treat every object in a optimal fashion for the different process.


Justify, using my example.

Quote:
I have a problem with how you thing, your seems only to be concerned about graphics.


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?

Quote:
Well, have you actually thought about that before you wrote that?

yes

Quote:
Well, how do you know it don´t work, have you tryed it?

Yes.

Quote:
What you really are saying is that you actually don´t know anything.


I could've sworn, that is precisely not what I said.

Quote:
You cant route workloads with out proper planing, it don´t work. Well, try it all you like, it wont work.


I can route workloads. I just don't want to manage this project. Management and design are to distinctively different things tho.

Quote:
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.


I have never claimed to be a manager of TE.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
PostPosted: Tue Aug 10, 2010 8:30 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Tue Dec 03, 2002 10:36 am
Posts: 13179
Location: The Netherlands
Bickering is for high school guys. It's OK to disagree but keep it friendly and don't rip up each other's quotes just to make your point. It's very awkward for those trying to follow the discussion.

_________________
Image
Dutch Trainset for OpenTTD | Dutch Trainset Topic | Combined Roadset v0.10


Top
   
PostPosted: Wed Aug 11, 2010 4:09 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 22, 2010 4:27 pm
Posts: 22
Location: Norrköping, Sweden
Quote:
was being designed from both ends at the same time

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.

Quote:
Don't manipulate the quotes.

I cut it, i did´t edit it in any way (just reconfirmed that). You statement sounds somewhat unfriendly.

Quote:
Phrase this better, because it sounds like some sort of dogma.

Well, i let Wikipedia do the job for me, because that the page was fairly well written.
http://en.wikipedia.org/wiki/Top_down
Contain most of the thing i tryed to say.

Quote:
At the same time tho someone else can design the interior of the module

How could that be possible if there is no plan, no interface, no interconnection, no specification... ?

Quote:
A module does not know what kind of functionality can be used

Actually, the complete opposite is true. You know, because its decided. Maybe not flexible nor innovative, but very effective.

Quote:
Or maybe you want to imply, that in order to prove my point I'd need to provide examples from each possible game module?/

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".

Quote:
Well, have you actually thought about that before you wrote that?

yes

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.

Quote:
Yes.

And you still clam its not possible? I´ll bet you, no scientist make that claim.

Quote:
I could've sworn, that is precisely not what I said.

Sorry, it shod be figurative

Quote:
Management and design are to distinctively different things tho.

I agree with that.

Quote:
I can route workloads

Well, maybe with some documentation.

Quote:
I have never claimed to be a manager of TE.
[/quote]
Some one else made it sound like that. Well, really, hows coordinating workload?

Hyronymus:
I try to be nicer, its really not part of my persona, i´m just your average evil managing/coordinator. Well, really, there is one difference, most managers get evil on the job. i was it in advance. (some level of evil is needed for the job)

*edit* (wrongly quoted)


Last edited by matsv2011 on Sun Aug 15, 2010 7:12 am, edited 2 times in total.

Top
   
PostPosted: Sat Aug 14, 2010 3:00 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2131
Location: Wroclaw, Poland / Katowice, Poland
MMky. Methinks we start talking about religious issues atm, which is kind of pointless.

Proposition: lay out your idea of how to proceed with the project, and we shall see how can it be done.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 41 posts ]  Go to page 1 2 3 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2018 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2018.
Hosted by Zernebok Hosting.