Suggestions on tiles

[Peter Dobrovka]

Well, since the height is encoded, I see no problems.

Peter

[Lilman424]

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?

[Raichase]

If the tiles were smaller but, there would be no room for double railway! I hope subsidies will continue

[Hajo]

With some thinking I think it can be avoided that the compiler produces 12 redundant bytes per tile.

What do you suggest?

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

[Peter Dobrovka]

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

[Hajo]

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?

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.

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.

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

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.

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

[Peter Dobrovka]

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.

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.

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.

Ah, that´s too hard! I would call it refactoring instead...

switch(object_type)
{
case street call function_street
case rail call function_rail
case building call function_object
}

Ask some OO experts.

That would be like asking the pope on Buddhism.

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.

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

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

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.

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.

Mistakes?

Well, everything has its pros and cons ... OOP isn't just bad, even if it comes with an overhead often.

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.

Peter

[Hajo]

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.

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.

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.

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

[SHADOW-XIII]

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
}

btw.. maybe this one ... so it will be possible to have all climates in one map ... (so we can create changin seasons of year)

[Hajo]

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.

Mistakes?

Peter

Mistakes = errors, misconceptions, omissons ...

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