Sign in to follow this  
uggibuggi

[.net] Would a rewrite make sense?

Recommended Posts

uggibuggi    116
Hi! Here's my problem: A year ago I started writing a small 3D engine released under the GPL. I wrote it in C# using .Net 2.0 and MDX. Of course I knew C# it's not the common language for game programming, but I thought it was good to make my engine object-oriented and flexible. Well, I'm working on it for almost a year now and I'm thinking about rewriting the whole engine. I see the following advantages in a rewrite:
  • I could completely redesign the engine, because since I started I learned so much that there are douzens things and new ideas I would implement in a new design
  • I could rewrite it in C++, and making the more low-level code faster in several areas this way. (I don't mind what you .Net-fans say, the ability to use pointers freely IS useful sometimes)
  • I could use OpenGL (or a plugin architecture to support both), together with the switch to C++ making the engine more easily portable
Of course it would have the disadvantage that I had to rewrite some thousand lines of code (current line count is luckily only somewhat over 9k, the engine is not that advanced at this point). Now, I don't know wether I should take this big step to start from scratch again or not and I'm asking you to give me some wise advise ;) thanks for your attention and forgive my bad english, ~uggibuggi [Edited by - uggibuggi on May 7, 2007 10:01:01 AM]

Share this post


Link to post
Share on other sites
jpetrie    13099
Quote:

I could completely redesign the engine, because since I started I learned so much that there are douzens things and new ideas I would implement in a new design

"Complete re-writes" are bad ideas. If you're uncomfortable with the design, refactor do not rewrite. The key difference is that refactoring involves making (usually small) iterative changes to the existing implementation (ideally, changes which never break the ability for the system to be compiled and used, although you can change APIs and consequently break dependent code if necessary) to bring the implementation in line with a new design.

Why is refactoring better? Because it forces you to actually think about the design you have, and its current implementation issues, and the design you're going for, and its potential implementation issues. 95% of the time, complete rewrites end up being just as broken as the original, and only superficially different (like more coherent naming conventions or a different API style). By simply wiping the slate clean and starting over, you don't learn from your mistakes (you just blissfully ignore them), and you tend to simply make them again the second time around.

Quote:

I could rewrite it in C++, and making the more low-level code faster in several areas this way. (I don't mind what you .Net-fans say, the ability to use pointers freely IS useful sometimes)

Of course they're useful, but not in all cases, and probably not for your cases. And the performance issue is laughable. You should read Washu's in-depth investigation of performance issues with managed/unmanaged code (the latest article is here).

Your original choice to use a managed language was good - it will allow you to write safer, more solid code much quicker than you would in C++. You can achieve equivalent performance with managed code, it just requires a bit of effort. It requires a bit of effort in unmanaged code, too -- probably about the same amount of effort, actually, it's just that the effort is of a different nature.

Quote:

I could use OpenGL (or a plugin architecture to support both), together with the switch to C++ making the engine more easily portable

The ability to support both OpenGL and D3D is usually a waste of time unless you are a serious, professional middleware developer. In any case, a good API design on your part should allow you to refactor in support for render API switches without requiring a full-on rewrite. If your current design exposes too much that indicates its D3D-based, for example, you're likely only going to repeat that mistake in a rewrite to use OpenGL. If you instead tried to refactor the support in with the existing design, you'd gain a more in-depth understanding of the issues involved and the subtle differences inherent in doing so.

So my advice is not to rewrite, and not to switch languages or underlying technologies yet. Refactor. It's an important skill to have -- in the real world, the cost-effectiveness of full-on rewrites is almost never in your favor, and consequently refactoring is your only sane option.

Your engine isn't all that big -- nine thousand lines is not much. While rewriting at this point wouldn't be a huge time sink, you'd still be prone to making the same design mistakes; after all, that size most of the code is boilerplate anyway. And by the same token, refactoring such a small codebase is easier than a large one, so it will be a good place to start. If your primary motivation (as you seem to imply in the news post on your project website) is because you've learned a lot of new stuff, consider that you'll always be learning new stuff and you cannot constantly rewrite the engine if you ever want it to be usable.

Share this post


Link to post
Share on other sites
remigius    1172
Quote:
I could rewrite it in C++, and making the more low-level code faster in several areas this way. (I don't mind what you .Net-fans say, the ability to use pointers freely IS useful sometimes)


You might have posted in the wrong forum then [wink]

But seriously, if you think you can structurally improve your engine with a rewrite and if C++ is a better platform for your new requirements, then go for it by all means. Just be careful you don't get stuck in the endless rewrite loop I ended up in when I was working on my engine. It can be tempting to go over the top with rewriting, which can really hurt your productivity.

If you're in it for the learning experience though, I'd really recommend you create yourself a game before doing any rewriting. From my experience even a simple game can give you a fresh perspective on your design choices and help improve the quality and usefulness of the engine. An 'engine' is often used as a vehicle for impressive techdemos, but more often than not it doesn't really fit the bill as the foundation on which to make a real game. This consideration is basically the only advice I can offer, since you probably know best if the current incarnation of your engine has a future.


Ugh, beaten and with a post trice the size of mine at that. I really gotta learn to type faster ;) The refactoring thingy is another very good point though.

Share this post


Link to post
Share on other sites
uggibuggi    116
Thanks. I think that helped me. I think I know what I'll do now. I'm currently reading Akenine-Möller's "Real-Time Rendering" and continuously learning new things.
When I'm done with that book, I'll think about my current design and what design I actually would want and wether it's possible to get something similar with a redesign of the current engine.

~Uggibuggi

Share this post


Link to post
Share on other sites
ruistola    719
Quote:
The ability to support both OpenGL and D3D is usually a waste of time unless you are a serious, professional middleware developer. In any case, a good API design on your part should allow you to refactor in support for render API switches without requiring a full-on rewrite. If your current design exposes too much that indicates its D3D-based, for example, you're likely only going to repeat that mistake in a rewrite to use OpenGL. If you instead tried to refactor the support in with the existing design, you'd gain a more in-depth understanding of the issues involved and the subtle differences inherent in doing so.


So true. I am a professional middleware developer and I've just spent the last couple of months refactoring D3D support into what used to be a pure OpenGL based renderer. Nowadays I'm a huge fan of refactoring, especially with a large codebase. People have limits and IMO developing software in baby steps is A Good Thing (tm). Keep things small, even if they are part of something big.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this