07 Sep, 2013, Idealiad wrote in the 41st comment:
Votes: 0
I watched an interesting talk on application design the other day and one of the comparisons was between making music and developing software.

One point talked about how a musician looks at their instrument. Someone can play a guitar, and to make the leap to taking apart and rebuilding that guitar is not something most guitarists will do. Now take the programmer. It's much more possible for that programmer to take apart their tools (i.e. engines, codebases) and rebuild (rewrite) them before getting to the actual game (i.e. music). That possibility creates a lot of friction in the development process.

I notice this issue a lot in my own development process. I'm trying to fight it. It's hard. :)
07 Sep, 2013, KaVir wrote in the 42nd comment:
Votes: 0
quixadhal said:
Misdirect.

Because you are attributing Activision Blizzard's *CURRENT* success with an action that took place *TWENTY YEARS EARLIER*.

No, I'm doing nothing of the sort. You're the one who brought up Return to Zork, implying it was the reason why Infocom ceased to exist. What I'm doing is pointing out that Infocom shut down years before that game was developed, and that the company who actually released Return to Zork is still thriving. Whether Return to Zork had any impact on their success can only be speculated, but the move to graphical games certainly didn't drive them out of business like you were implying.

Ssolvarain said:
And Lucas Arts was a great game studio back in the day…

Look at where they are now.

The success or failure of a company obviously depends on many different factors.
07 Sep, 2013, Ssolvarain wrote in the 43rd comment:
Votes: 0
They never made a remake of tie fighter/x-wing :(


And yeah that's what I was getting at kavir.

But a lot of the old game studios didn't survive the coming of true 3d. Apogee is another good example. Commander Keen was the man. Er, boy?

Edit: Ok, since I actually checked… Apogee is a bad example since it had the 3d Realms brand, too.
07 Sep, 2013, Rarva.Riendf wrote in the 44th comment:
Votes: 0
Aelius said:
But then reality hit me - converting a huge, 15 year-old C mud to C++ would be difficult, tedious, and time consuming.


Or something like 2 days. You didn't need to rewrite it, just to make it compile. And from then you can use all C++ niceties in new code. No need to touch the old code if it works.
07 Sep, 2013, Davion wrote in the 45th comment:
Votes: 0
Rarva.Riendf said:
Or something like 2 days. You didn't need to rewrite it, just to make it compile. And from then you can use all C++ niceties in new code. No need to touch the old code if it works.


That is, until you want to start using STL classes as data members in your C structs…
07 Sep, 2013, Aelius wrote in the 46th comment:
Votes: 0
Rarva.Riendf said:
Aelius said:
But then reality hit me - converting a huge, 15 year-old C mud to C++ would be difficult, tedious, and time consuming.


Or something like 2 days. You didn't need to rewrite it, just to make it compile. And from then you can use all C++ niceties in new code. No need to touch the old code if it works.


Well, duh. It took me maybe two hours to get it to compile in C++. But there's no point in doing so unless you're going to take advantage of everything C++ has to offer. The old code may "work", but that doesn't mean that it's efficient or particularly well-written. To me, the point of "converting" from C to C++ would be to use C++ everywhere. If my converted code would still have the same 15 year-old C conventions and horrible memory management everywhere, that's not really worth it, since the amount of new code I would be writing would pale in comparison to the size of the existing code.
07 Sep, 2013, KaVir wrote in the 47th comment:
Votes: 0
Aelius said:
Well, duh. It took me maybe two hours to get it to compile in C++. But there's no point in doing so unless you're going to take advantage of everything C++ has to offer. The old code may "work", but that doesn't mean that it's efficient or particularly well-written. To me, the point of "converting" from C to C++ would be to use C++ everywhere. If my converted code would still have the same 15 year-old C conventions and horrible memory management everywhere, that's not really worth it, since the amount of new code I would be writing would pale in comparison to the size of the existing code.

I couldn't disagree more. If your goal is to develop a playable game (rather than a public codebase), then there's little practical benefit in rewriting code that already does exactly what you want. But if C++ makes it quicker and easier to add new features, then those two hours represent a tiny investment that will pay itself off many times over.
07 Sep, 2013, quixadhal wrote in the 48th comment:
Votes: 0
And if you were going to go to that much effort, you might as well rewrite it in a less annoying langauge that actually has a native string type and works well with text processing (perl, python, ruby… take your pick, there are plenty more).
07 Sep, 2013, Aelius wrote in the 49th comment:
Votes: 0
KaVir said:
Aelius said:
Well, duh. It took me maybe two hours to get it to compile in C++. But there's no point in doing so unless you're going to take advantage of everything C++ has to offer. The old code may "work", but that doesn't mean that it's efficient or particularly well-written. To me, the point of "converting" from C to C++ would be to use C++ everywhere. If my converted code would still have the same 15 year-old C conventions and horrible memory management everywhere, that's not really worth it, since the amount of new code I would be writing would pale in comparison to the size of the existing code.

I couldn't disagree more. If your goal is to develop a playable game (rather than a public codebase), then there's little practical benefit in rewriting code that already does exactly what you want. But if C++ makes it quicker and easier to add new features, then those two hours represent a tiny investment that will pay itself off many times over.


I don't know - in my travels as a programmer (my career before my current one, law), refactoring was always a very important part of coding for me. There's a fine line between refactoring and over-engineering, but I think that a lot of the old ROM (and other Diku) systems would benefit from a C++ refactor.

And, at any rate, that's why I decided to write one from scratch, in a different language. I will hopefully be releasing it at some point.
07 Sep, 2013, Runter wrote in the 50th comment:
Votes: 0
I can see it both ways, but from my perspective the parts of C++ that are C can still be considered valid C++, as per the superset definition. So I find it totally legit to heavily use C in my Cpp without feeling a need to convert it over just for the sake of it all being more differentiated from valid C.
07 Sep, 2013, Aelius wrote in the 51st comment:
Votes: 0
Runter said:
I can see it both ways, but from my perspective the parts of C++ that are C can still be considered valid C++, as per the superset definition. So I find it totally legit to heavily use C in my Cpp without feeling a need to convert it over just for the sake of it all being more differentiated from valid C.


I find some parts of ROM code pretty poorly written, especially when it comes to memory management and string manipulation. So that's why I'd redo a bunch of those systems.

That is, redo if I thought it were worth it. But it's not really, so that's why I'd just write a new codebase instead.
07 Sep, 2013, KaVir wrote in the 52nd comment:
Votes: 0
Refactoring has its uses, but rewriting an entire codebase that already works is just giving yourself a massive pile of work that won't actually improve the game. However my main point was that you don't have to rewrite everything in order to benefit from C++. There's absolutely nothing wrong with encapsulating the old C code in a namespace and using C++ for your new features.
07 Sep, 2013, Aelius wrote in the 53rd comment:
Votes: 0
KaVir said:
Refactoring has its uses, but rewriting an entire codebase that already works is just giving yourself a massive pile of work that won't actually improve the game. However my main point was that you don't have to rewrite everything in order to benefit from C++. There's absolutely nothing wrong with encapsulating the old C code in a namespace and using C++ for your new features.


I don't think I ever said that I wanted to rewrite the whole thing. Just large parts of it. :)

In particular I had wanted to convert all of the flat storage files to a database (likely MySQL) and then take advantage of a C++ ORM, like ODB. That would have indeed required a large-scale rewrite, and, in the end, totally wouldn't have been worth the effort.
07 Sep, 2013, Nathan wrote in the 54th comment:
Votes: 0
KaVir said:
quixadhal said:
Misdirect.

Because you are attributing Activision Blizzard's *CURRENT* success with an action that took place *TWENTY YEARS EARLIER*.

No, I'm doing nothing of the sort. You're the one who brought up Return to Zork, implying it was the reason why Infocom ceased to exist. What I'm doing is pointing out that Infocom shut down years before that game was developed, and that the company who actually released Return to Zork is still thriving. Whether Return to Zork had any impact on their success can only be speculated, but the move to graphical games certainly didn't drive them out of business like you were implying.

Ssolvarain said:
And Lucas Arts was a great game studio back in the day…

Look at where they are now.

The success or failure of a company obviously depends on many different factors.


Even if having to move to the graphical game arena caused company to close, fail, etc that doesn't necessarily means that their games were bad. It just means that the market demand for non-graphical games and the money to make them, dried up.
08 Sep, 2013, Rarva.Riendf wrote in the 55th comment:
Votes: 0
Aelius said:
KaVir said:
Refactoring has its uses, but rewriting an entire codebase that already works is just giving yourself a massive pile of work that won't actually improve the game. However my main point was that you don't have to rewrite everything in order to benefit from C++. There's absolutely nothing wrong with encapsulating the old C code in a namespace and using C++ for your new features.


I don't think I ever said that I wanted to rewrite the whole thing. Just large parts of it. :)

In particular I had wanted to convert all of the flat storage files to a database (likely MySQL) and then take advantage of a C++ ORM, like ODB. That would have indeed required a large-scale rewrite, and, in the end, totally wouldn't have been worth the effort.


String manipulation: why change it if it works. If you write a new method, use C++ String if needed. Effort ? none.
Change flat files to sql ? Not related at all to the language.
Memory management: indeed there was a major shortcomings since it prevents anything affecting numerous players at the same time (like death). That has to be rewritten in ROM. But even in C anyway, it is the logic that was wrong to begin with, nothing related to the langage itself. That is even the reason why I registrered here, to ask how people dealt with it, since I discovered the stupidity of it when I took the coder role of my old mud.


All these needed not a total rewrite in C++. You prefer to rewrite eveyrthing to have code that 'look' the same everywhere, but that is really just a matter of personnal preferences. If you were a professional coder, you must have seen that a lot of code is not refactored everytime you add a feature.

And while you rewrite your codebase it means your game does not evolve a bit. Losing potential players. Also means that you cannot access to any of your flatfile unless you write an import routine in your new code (that would have been easier to write as an export routine in the old code to begin with, since all the logic was there to exploit)

You just wanted to have your own codebase. No need to invent poor justification to it. There is nothing wrong to want to use your own code. If only for the license.
08 Sep, 2013, Runter wrote in the 56th comment:
Votes: 0
Davion said:
Rarva.Riendf said:
Or something like 2 days. You didn't need to rewrite it, just to make it compile. And from then you can use all C++ niceties in new code. No need to touch the old code if it works.


That is, until you want to start using STL classes as data members in your C structs…


Actually, it shouldn't be a problem since in C++ class and struct are fundamentally the same thing, with distinction on defaulting to public in struct s case.
08 Sep, 2013, Aelius wrote in the 57th comment:
Votes: 0
Rarva.Riendf said:
Change flat files to sql ? Not related at all to the language.


Just a small point here - it is most definitely related in this case, since I explicitly said that I wanted to use ODB, which is a C++ object-relational mapper.

At any rate, all I was trying to say was that, at some point, these old codebases become more trouble than they're worth. Hence, starting from scratch.
08 Sep, 2013, Rarva.Riendf wrote in the 58th comment:
Votes: 0
Aelius said:
Rarva.Riendf said:
Change flat files to sql ? Not related at all to the language.


Just a small point here - it is most definitely related in this case, since I explicitly said that I wanted to use ODB, which is a C++ object-relational mapper.


Then two hours so it compiles in C++ you said heh. Even with the two days it took me (mainly cause I wanted to erradicate a lot of warnings of deprecated behaviours though, I don't remind exactly how long it actually took to just compile and run fine, but it was a lot shorter for sure) I would still have been faster than to rewrite a new mud and migrate all the gameply to it.

Rewriting 400+ skills/spells for the sake of changing of langage still take ages. Whatever the langage.
08 Sep, 2013, Aelius wrote in the 59th comment:
Votes: 0
Rarva.Riendf said:
Aelius said:
Rarva.Riendf said:
Change flat files to sql ? Not related at all to the language.


Just a small point here - it is most definitely related in this case, since I explicitly said that I wanted to use ODB, which is a C++ object-relational mapper.


Then two hours so it compiles in C++ you said heh. Even with the two days it took me (mainly cause I wanted to erradicate a lot of warnings of deprecated behaviours though, I don't remind exactly how long it actually took to just compile and run fine, but it was a lot shorter for sure) I would still have been faster than to rewrite a new mud and migrate all the gameply to it.

Rewriting 400+ skills/spells for the sake of changing of langage still take ages. Whatever the langage.


Fully agree there. Luckily, I'm not doing any of that - starting from a clean slate.
08 Sep, 2013, quixadhal wrote in the 60th comment:
Votes: 0
That's why I suggest using some language that's actually GOOD with text manipulation, if you're going to be rewriting things anyways. C -> C++ buys you some things, but C++ really isn't all that good at text manipulation. You can use std::string, but you'll still find yourself having to muck about with pointers and whatnot as you invoke system calls.

Why not use a language where strings are a base type, and that lets you easily manipulate them without counting bytes and converting back and forth all the time?

There are large chunks of most of the Dikurivative codebases that would be entirely unneeded if you used a language like perl, since all that one_argument() parsing stuff would be replaced by a few lines using split()…. all the memory management nonsense would be totally unused, since perl/ruby/python all use garbage collection, and allocate as you need things.
40.0/74