Drivey in C++
Thursday, February 3rd, 2005
First screen. Although it’s obviously still a long way from the functionality of the original demo, this is just to show that, you know, I am working on it. A bit.
Recoding in C++ [refactoring?] is pretty frikkin annoying after playing around in the forgivingly sloppy for so long but, as I’ve said before, JujuScript is just way too damn slow for any kind of serious number crunching, and if I want to take Drivey beyond the simple demo stage — with larger maps, better physics and more active objects whirling about the place — I’ll really need the speed/power that only a compiled language like C++ can offer.
Problem now is, do I slavishly recreate what I’ve already done in Jujuscript, or do I just go where I feel like as though it was a whole new project? The latter feels like the best option [less limiting], but at the same time if I don’t recreate what I’ve already done then I can’t guarantee that what I create in C++ will retain the positive qualities of the original.
Should be interesting.
__________
* In the picture above you can already see a minor feature which departs from the established style of the demo — the posts have shadows. That doesn’t mean that shadows will stay; it just occurred to me that there was an easy way to do them.
February 4th, 2005 at 2:12 pm
Although the shadows may have been just a test, the above screenshot is certainly an nifty look in itself. Hmmm, decisions, decisions.
February 16th, 2005 at 1:31 pm
I meant to add this a while back, but work has kept me from doing so:
As a bit of a follow-up to my earlier C++ comment: why don’t you go for a more hybrid approach and develop Drivey in a mixture of scripting and C++/C?
This approach is fairly common in game development [and not so well-known outside of it, alas], since it enables you to get the best of both worlds:
While scripting keeps things flexible and dynamic, the C/C++ side of the system makes sure you keep performance (where it matters).
If for nothing else, such a hybrid setup could save you a substantial number of edit / compile / link / debug cycles.
Some food for thought?
February 16th, 2005 at 2:54 pm
It’s a definite possibility, but for now I’m just using a simple batch style scripting to define environments in DriveyC++.
One reason I am hesitant to commit to using a fully fledged script language is that it requires a reasonably “fat” interface layer between the C++ core and the script engine [in order to expose/bind internal structures so that they are accessible via script] and could bog down the architecture a bit too much because of this extra linkage.
February 16th, 2005 at 3:20 pm
I should clarify: You are absolutely right re the best of both worlds, and if Drivey development continues, embedded scripting will probably happen at some point… but until I know what I really want the C++ guts to do I’m going to hold off on adding it [and then i have to decide whether to use JujuScript or a more mature 3rd party solution … preferably something portable so I don’t lock myself further into Win32 land… I haven’t really looked into this much yet].
February 26th, 2005 at 5:21 pm
You’re right to be concerned about code bloat, of course. However, I think that if done right the advantages will definitely outweigh any possible downsides.
I agree that if you’re still noodling with the audio or graphics primitives, it may be a bit too early. But once you start adding more dynamic behaviour, any form of AI or event driven handlers, scripting can (and will!) be your friend.
Also, if you’re already convinced scripting will have to be in place at some point in the future, I think it’s better to tinker with it now. That way you’ll have a much better understanding of the issues (and possibilities) early on.
The good news is that if you don’t mind stepping away from Jujuscript, there are viable scripting options out there. Some of them are even incredible easy to incorporate, portable and efficient [yes, I know it sounds too good to be true, but there you have it :-)].
As a final pointer: I often find that people who start out binding a script engine to their software tend to try and wire every little nook & cranny. My advice: Don’t! You’re far better off binding just the essentials (and do those in a fairly high-level way). Not only does it take much less time to create the glue code, it’s also a great way to structure that part of your app you want to control.
Anyway, that’s it for now.
P.S. I wish these edit-boxes weren’t so *tiny*! Or maybe it’s just me, and I simply shouldn’t be typing these long messages… [;-)]