Comments on: Drivey in C++

By: shaun

shaun — Fri, 04 Feb 2005 03:12:36 +0000

Although the shadows may have been just a test, the above screenshot is certainly an nifty look in itself. Hmmm, decisions, decisions.

By: Ashwin

Ashwin — Wed, 16 Feb 2005 02:31:47 +0000

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?

By: mark

mark — Wed, 16 Feb 2005 03:54:27 +0000

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.

By: mark

mark — Wed, 16 Feb 2005 04:20:10 +0000

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

By: Ashwin

Ashwin — Sat, 26 Feb 2005 06:21:00 +0000

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… [;-)]