Suggestions on tiles
Moderator: Transport Empire Moderators
-
- Engineer
- Posts: 44
- Joined: 03 Feb 2003 20:07
I think It'd be great to have multiway railroad in 1 tile, but only for my subsidy games...hmm...there will be subsidies...right?
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction. - Albert Einstein
- Raichase
- Moderizzle
- Posts: 11509
- Joined: 15 Dec 2002 00:58
- Location: Sydney, Australia. Usually at work in the underground railway station...
- Contact:
If the tiles were smaller but, there would be no room for double railway! I hope subsidies will continue
Posted by Raichase. Visit my Flickr! Gallery, Blog (get a feed of everyone at once at Planet TT-Forums).
Raichase - Perfect timing, all the time: [13:37] * Now talking in #tycoon
Official TT-Dave Worley Fan Club
Official TT-Andel-in-a-pink-hat Fan Club
Raichase - Perfect timing, all the time: [13:37] * Now talking in #tycoon
Official TT-Dave Worley Fan Club
Official TT-Andel-in-a-pink-hat Fan Club
What do you suggest?Peter Dobrovka wrote: With some thinking I think it can be avoided that the compiler produces 12 redundant bytes per tile.
4 of those bytes are a pointer to the virtual function table IIRC. 4 seem to be a pointer to parent class or something. The latter 4 seem to be the object size, maybe needed for the 'delete' operator.
c.u.
Hajo
-
- Engineer
- Posts: 44
- Joined: 03 Feb 2003 20:07
Ah, classes.
Well, we had some discussion about OOP already, and you know which features I do like and which I do not. For purposes like ours I do evangelize SEPARATION of data and code instead of the opposite.
What about avoiding classes and virtual functions? Code it into the program code by a case or something:
switch(object_type)
{
case street call function_street
case rail call function_rail
case building call function_object
}
This is also better readable and understandable (seriously).
Peter
Well, we had some discussion about OOP already, and you know which features I do like and which I do not. For purposes like ours I do evangelize SEPARATION of data and code instead of the opposite.
What about avoiding classes and virtual functions? Code it into the program code by a case or something:
switch(object_type)
{
case street call function_street
case rail call function_rail
case building call function_object
}
This is also better readable and understandable (seriously).
Peter
You know that initally I started Simutrans also because I wanted to learn OOP. So Simutrans initial design tried to follow the OO ideas as closely as possible.Peter Dobrovka wrote:Ah, classes.
Well, we had some discussion about OOP already, and you know which features I do like and which I do not. For purposes like ours I do evangelize SEPARATION of data and code instead of the opposite.
What about avoiding classes and virtual functions?
If you start a new project, you're fre in your decision, but in case of Simutrans using another approach means writing a new program which I do not want to do.
Ask some OO experts. They say this is horrible and virtual function shall be used instead. One of the reasons is that if you add a new object type, you need to find and alter all the switch statements. If the method is virtual the old code doesn't need to be altered if a new subclass is added that overrides that method.Peter Dobrovka wrote: Code it into the program code by a case or something:
switch(object_type)
{
case street call function_street
case rail call function_rail
case building call function_object
}
This is also better readable and understandable (seriously).
Peter
IMO that reason is a good reason.
Another reason is that switches cause pipeline stalls (very bad on modern processors) while virtual methods don't need switches (but come with an additional indirection).
A third reason is that switches/if statement are statistically proven to have a higher chance of mistakes than other code. So the experts say they are to be avoided, and virtual methods help to remove some of them.
Well, everything has its pros and cons ... OOP isn't just bad, even if it comes with an overhead often.
c.u.
Hajo
-
- Engineer
- Posts: 44
- Joined: 03 Feb 2003 20:07
This is very respectable, but learning about something is also learning about its weaknesses and to judge when to use and when rather not to use.Hajo wrote: You know that initally I started Simutrans also because I wanted to learn OOP. So Simutrans initial design tried to follow the OO ideas as closely as possible.
Ah, that´s too hard! I would call it refactoring instead...Hajo wrote: If you start a new project, you're fre in your decision, but in case of Simutrans using another approach means writing a new program which I do not want to do.
That would be like asking the pope on Buddhism.Hajo wrote:Ask some OO experts.switch(object_type)
{
case street call function_street
case rail call function_rail
case building call function_object
}
Every thing in its context. For a tile based game it is no good reason since there is not much to deal with polymorphics and there must be only that ONE switch statement in your code. If unavoidable, use a macro!Hajo wrote: They say this is horrible and virtual function shall be used instead. One of the reasons is that if you add a new object type, you need to find and alter all the switch statements. If the method is virtual the old code doesn't need to be altered if a new subclass is added that overrides that method.
IMO that reason is a good reason.
Anyway if you want to have a default function for new entries:
switch(object_type)
{
case street call function_street
case rail call function_rail
case building call function_object
default call function_warning:_not_implemented
}
Of course you have to implement it or to add it to one of the cases.
This might be a good point. But this is only one of many statements, so I don´t think you could profile out any difference.Hajo wrote: Another reason is that switches cause pipeline stalls (very bad on modern processors) while virtual methods don't need switches (but come with an additional indirection).
Mistakes?Hajo wrote: A third reason is that switches/if statement are statistically proven to have a higher chance of mistakes than other code. So the experts say they are to be avoided, and virtual methods help to remove some of them.
I don´t say OOP is bad and I don´t say it is good. But I say that it is not the last word spoken in software engineering.Hajo wrote: Well, everything has its pros and cons ... OOP isn't just bad, even if it comes with an overhead often.
Peter
Yes of course. I just wanted to tell why I made the decison for OO design. Not because it is particularly good for games like Simutrans, but becuase I wanted to learn this style of program design and development. That time I didn't expect Simutrans to be a successful game. It was just an experiment to learn new things - and an interesting project because I liked transport simulations. When I say "I try/tried to make a better TTD" this is serious, it is really what I want to do, but in the beginning I didn't seriously expect to reach that goal.Peter Dobrovka wrote:This is very respectable, but learning about something is also learning about its weaknesses and to judge when to use and when rather not to use.Hajo wrote: You know that initally I started Simutrans also because I wanted to learn OOP. So Simutrans initial design tried to follow the OO ideas as closely as possible.
Peter
I don't say you need to use OO for your game.
We already talked a lot about this in the past, and we agreed that we just have different opinions. I don't want to go through this discussion again.
I might say Simutrans is moving towards traditional game design in some areas, but since all current developers like the OO approach, we rather try to optimize within the rules of OO design instead of changing to another methodology. IMO the overhead of OOP is not big enough to outweight the benefits that it brings. But this is a personal opinion. Of coursed biased by training and work ...
When bashing on Simutrans (i.e why does the map need so much memory) you must consider that if someone starts learning something new by using it, he will make many mistakes. With my current experience, I don't consider my initial design of Simutrans to be very good. But I don't like being constantly critisized for past mistakes that I know to be mistakes just too well. Nowadays I'd do many things differently, but that doesn't help much ... except for my new projects if I ever start something new again.
c.u.
Hajo
-
- Tycoon
- Posts: 14275
- Joined: 09 Jan 2003 08:37
Code: Select all
switch(object_type)
{
case street call function_street
case rail call function_rail
case building call function_object
case terrain call function_terraintype // this one
}
Last edited by SHADOW-XIII on 05 Feb 2003 14:37, edited 1 time in total.
what are you looking at? it's a signature!
Mistakes = errors, misconceptions, omissons ...Peter Dobrovka wrote:Mistakes?Hajo wrote: A third reason is that switches/if statement are statistically proven to have a higher chance of mistakes than other code. So the experts say they are to be avoided, and virtual methods help to remove some of them.
Peter
Statistics had been made, to determine "average number of bugs per line of code". They showed a dependency of the number of if/switch statements and the number of bugs. The more switches the more bugs. (Also: the more loops the more bugs).
This result is independant from OO in first place. The idea is just to avoid if/switch staments to lower the chance of mistakes. In procedural programming you can use tables, function pointers and some more to reduce the number of if/switch statements in your code.
In OOP inheritance and virtual methods help to remove if/switch statements (plus all the options you have in procedural development). Often bugs, or even the chance to make mistakes, are considered to be worse that a performance penalty and so the use of virtual methods is adviced.
I know you say virtual methods are ununderstandable and therefore very likely to introduce just a different class of mistakes ... well, so one expert says this and the other says that.
I made my own decision which style I prefer, and I like the OO approach. This makes me vulnerable because in average my programs are slower and need more memory than other people but I still believe that OO design helps to create better maintaineable and reuseable code. At least the reuseability is proven IMO, maintaineability ... well I still hope
If you just think in terms of one project reuseability is unimportant. Maintaineability is only important if it shall be a long-term project. Maintainebility is influenced by coding style more than by methodology so using OO development is only a supportive decision to raise maintaineability.
Please note that I don't think that Simutrans is a good example for proper OO development. I was just learning OO when I started Simutrans (other way ropund - I started Simutrans to learn OO development) so it is full of bugs and misdesigns. But that's not he fault of OO, but me being a newby to C++ and OO in 1997.
Many parts of Simutrans have indeed been reuseable for new projects.
Maintaineabilty of Simutrans code is mediocre I'd say. New features require often major rework of existing components. OTOH there is lot's of potential in the structures, just a very few things are hard to implement.
Worst thing in Simutrans is the UI elements library IMO. Changes to the UI are very time consuming usually.
But still, I think if done right OOD/OOP is the superior appraoch for big projects.
c.u.
Hajo
Topic locked, really old moot (12112006).
Who is online
Users browsing this forum: No registered users and 2 guests