T2D.NET : Upcomming Beta

#1 T2D.NET A C# Wrapper of the Torque 2D Engine.
.NET Dev, meet T2D

A new generation of developers

As programming languages advance, they arguably become more and more "dumbed down", to the point where developers can lead full and productive careers building applications from the ground-up and never even once have to know what a pointer is. This is the type of developer, the person born and raised on .NET that We would like to target with a wrapper of the Torque Engines.

This class of developer born and raised on .NET, is a rapidly growing segment of the development community. These .NET devs are not only used to, but dependant on the rich benefits of the Visual Studio IDE, the seamless build environment and ease of integration, the rich debugging abilities, and mostly the flexible languages and rich language APIs.

The benefits of a .NET wrapper.

Wrapping T2D in a way that allows .NET devs to leverage the existing Torque resources (TorqueScript for example) but also allows the full capabilities of T2D within a .NET development environment would be a huge productivity gain, and allow the opportunity for a new class of hobbyists to become engaged in the Torque line of game engines.

This would allow .NET devs to easily leverage all the benefits of .NET and apply them to T2D development: ranging from asynchronous functions to community resources for algorithms such as A+.

Why Torque 2D

The Torque 2D Engine, while not being released yet, is We believe the simplest of the Torque Engines in terms of functionality. Both the fact that it is relatively simple, plus a new product makes T2D the ideal target for a project of this type.


Interoperability: T2D -> C# -> T2D

We have found the following method that allows access to the T2D engine sufficiently to allow T2D to C# to T2D interoperability, while still allowing developers to not only use existing means of extending T2D (TorqueScript and C++) but also allowing C# to be used side-by-side, complementary to existing code.


Work done so-far

We have created a prototype Wrapper that hooks all ConsoleFunctions and SimObjects accessable to TorqueScript, implementing C# versions of these. (And also hooking the OnCollision event)

From this, We wrote an implementation of the Introduction Basic Tutorial in C#. (See the screenshot for details).

We then created a .NET Forms UI which allows the user to pick what scenario to run, those being picked from the following enum:

public enum SimulationList{
/// <summary>
/// Loads T2D/Client/BasicTutorial.TorqueScript.ts and executes initializeClient_BasicTutorial_TorqueScript();
/// <para>This allows Your Existing TorqueScript apps to run with zero modifications!</para>
/// </summary>
BasicTutorial_TorqueScript,

/// <summary>
/// This Tutorial is a C# port of the TorqueScript version.  No other modifications or optimizations have been made.
/// </summary>
BasicTutorial_CSharp_Flat,

/// <summary>
/// This Tutorial restructures the BasicTutorial into seperate classes, showing an example of how an Game can mix C# and T2D.NET
/// <para>OOP==Object Oriented Programming.</para>
/// </summary>
BasicTutorial_CSharp_OOP,
}

Overall, this is a big success so far!

We know that T2D is still undergoing a lot of revolutionary changes, and things are not yet stabilized. This beta is designed to help determine the usability of existing T2D.NET functionality, and what of the existing wrapper should be changed.

Please note that this is not a rewrite of T2D. You must have the T2D sourcecode for this to be useful. This is a dev tool, not a port.

-Jason

#2 FYI, the following functionality has not yet been wrapped (or at least not tested):

Torque Arrays
Torque GUI controlls
Any Callbacks (except OnCollision, this is working)

Basically, only the functionality needed for running the Basic Tutorial has been wrapped. (All ConsoleFunctions and SimObjects) plus the OnCollision callback.

The purpose of this beta is to obtain feedback as to the usability of the wrapper, and get suggestions on how you would like to see this project proceed.

Ultimatly, I envision this "T2D.NET" not only being a .NET wrapper of T2D, but a collection of very usefull utilities that will give the .NET dev significant added-value. (Such as a ".NET Forms" based gui system, isometrics abstraction, pathfinding algorithms, etc)

#3 Wow. This is very cool! If I wasn't married to Python, I'd definitely go out with this C# version. :)

Edit: will it work with Mono? Mac compatibility is a must for indie games (so far, I get more sales from Mac users than PC users).

#4 As I have very low visibility to the mono project, my assumptions are that it does not.

Reasons:

I targets .NET 2005 (clr v2). What I know about mono is that they are still catching up on the clr1.1 functionality. It shouldnt be too difficult to retarget this to clr1.1 though.

I am using C++/CLI for the C++ to C# interop. I doubt that Mono has (or will in the near future) have support for C++/CLI. It is probably possible to adapt the interop, but I'm not a mac guy, and not a mono guy, so if anyone wants to offer a suggestion on a good way to do this, i'm all ears.

===================

I might as well mention some of the (obvious) benifits to writing your T2D app in .NET

Ability to use any .NET functionality in your game. (There is a huge amount of code you could use on the web, look at places like codeproject.com)

Ability to debug your applications at runtime, attaching a debugger at any point.

Ability to use built-in intelisence, just like any .NET development environment should

Ability to use still any existing TorqueScript you have, unmodified.

Easy ability to execute .NET methods directly from torqueScript.

All the power, fullness, and maturity of C# or any .NET language in your game.

=======================================

Now for the 'bad stuff'

.NET is only portable to Microsoft devices. That means no mac or linux games. (This is theoretically reversable, though I dont know Mono so I wont be doing it anytime soon)

This is a beta. Meaning there is funcitonality missing. The biggest thing you'll be missing is GUI stuff, and callbacks. (The only working callback is OnCollision). But again, remember that you can leverage torquescript to do anything else, so dont let this beta of t2d.net hold you back :)

#5 If anyone else is interested in the beta, email me at jaytau@taocorp.com and I will send you a link to download the files. (aprox 2mb)

#6 Why not use TorqueScript? I have used it, and it works very well.

#7 ... WELL, there are many reasons why I choose C# over TorqueScript anyday:

=====================

1) TorqueScript is not a fully featured programming language, C# is.

2) Many many resources exist (gaming and otherwise) for C# that are hard to find, difficult to implement, or impossible to implement in torquescript.

3) With C#, you get the full benifits of the .NET CLR and IDE. That means easy debugging, error finding, breakpoints, tracepoints, asserts, compilation error reporting, intelisence, auto-documentation,

4) Strongly typed variables

5) C# is a "programming language" with the ease of use of a scripting language.

6) All sorts of compile time optimizations, to make it faster than torquescript.

7) C# is Fully Object-Orriented

8) Get all the reflection, Generics, Anonymous Delegates, etc goodness that anyone who's uses .NET (v2) knows and appreciates.

9) Ability to write in your favorite language, C#, VB, J#, Python, Perl, C++, LUA, etc etc.

=========

I guess if you never used .NET before, then I can see why you would wonder. But anyone who's programmed professionally in .NET would quickly recognize the benifits.

#8 I just wanted to pop in and say that I think this is very cool. Jason has been coordinating with me via email. If you are interested in trying this thing out, please post here and email Jason. Then let us know what you think!

#9 A few questions.

I was going to hack the source and bind Lua to allow me to use that instead of TorqueScript since I'm already very familiar with Lua. I have little experience with .NET, but I read it allows you to use any language. How does that work?

Lua can be embedded and is cross platform... is this a good alternative to embedding and binding Lua to T2D manually? If this saves me work I will love you.

Will this require VS.NET or can it work with Eclipse too?

#10

Quote:4) Strongly typed variables

An interesting opinion, but strongly typed variables are not an advantage in all circumstances. Indeed, they make code a bit more difficult to work with, as they require you to declare variables and so froth.

Quote:5) C# is a "programming language" with the ease of use of a scripting language.

That is worse of an opinion, as C# does in fact not have the ease of use of a scripting language. The fact that you have to define your variables with explicit types automatically makes it more difficult to use than a normal scripting language. And there are plenty of other reasons as well (not all of which TScript has, btw, but that can't be helped).

Quote:6) All sorts of compile time optimizations, to make it faster than torquescript.

Just changing the TScript/C++ interface to not be string-based would make TScript faster. If you just want faster use of TScript, there are other, potentially easier, ways to go about doing it. More importantly, I would suggest that if you rely on the speed of your scripting language interpreter, you're probably not using the scripting language correctly.

Now, I'm not saying that a .NET binding for T2D is a bad idea (though the lack of a cross-platform implementation makes this a non-starter for me. I would like to use C# for some of the higher-end portion of game development). I'm just suggesting that not all of your justifications are as good as you might think.

Quote:I have little experience with .NET, but I read it allows you to use any language.

It lets you use any language that compiles to .NET bytecode. Look here for more information on this.

#11 @Smaug: your points are valid, but a tad too far on the "negative" side I think. By that, I mean for basically any of my points, you could (legitimatly) find a counter-argument or rebuttal to my claims. However, as a whole, the inclusive sum of all of the benifits I state combine to form a very attractive package.

Now to offer a counter-counterpoint to your statements:

Strongly Typed variables: Sometimes good, sometimes bad. If you are in a loose syntax scripting language, probably a good thing. But with this "freedom to be sloppy" comes its crippling effects once you try to scale an application past the prototype stage. So overall, in a "real" programming languge, I think a strict language is a good thing. (And FYI, .NET is strict, but forgiving, in that it is very very easy to catch these syntax errors at development-time)

C# is a "programming language" with the ease fo use of a scripting language: OK OK, you got me on that one. Chalk my statement up to simplification. To elaborate on my statement, and to make it "true", lets instead say: C# is as easy to use as VisualBASIC, but with the power and functionality of C++. C# (like Java) is an evolutionary improvement over it's predicessors. Meaning that it is easier to use while maintaining rich functionality. That is what my initial statement was inferring on.


6) All sorts of compile time optimizations, to make it faster than torquescript.: You are right, there are various ways to improve the performance of TorqueScript, such as removing the string conversions. However, my point here is just that using my C# wrapper lets you bypass this entirely. It is not the primary purpose of the T2D.NET, just a very nice added benifit.

And yes, I totally agree that the biggest (and most valid) issue people will have with T2D.NET is it's lack of cross-platform support. This is very valid. Each developer has to weigh the pro's cons of each issue. If a dev wants to write a prototype, or want to target a Microsoft platform, then T2D.NET would be worth considering.

==================

@Joe Rossi: While you can write for T2D.NET in basically any language you wish, it all gets compiled down to a .NET Assembly, which is currently only runable on microsoft operating systems. Those that want to argue this point, sure there is something out there called "mono" which is supposed to let you run .NET on Mac and Linux, but I dont support that so I'm definatly not going to claim T2D.NET would work under it :)

#12 An update:

From now on, Please post a reply to this thread if you'd like to try the beta out. I will then email you the URL to download it.

Again, let me re-iterate that this version is VS2005 only. I'm working on back-porting things to VS2003 (clr 1.1) which may also help those mono users out there, so if it's not too difficult, this will be an option in the next beta.

#13 @Jason Swearingen ( apologize in advance for posting reply... )
I've used Mono and it was easy to compile some C# code. It has some problems with Windows.Forms IIRC. Once you get this up and running I think someone can port it to Mono.

@Smaug Thanks for the link, neat stuff.

#14 Looks very interesting, I would like to try it out: drivehappy@gmail.com

#15 Impressive. I'm doing similar work, using T2D as a DLL with Smalltalk. Another similarity: my implementation is currently Windows-only but doesn't have to be. Even though I have no plans to use .NET, I'm interested in studying your code. You can email it to mythteller AT gmail DOT com (the drawback of getting people to post their requests to the forum is that they have to obfuscate their email address in order to avoid spam).

Oh, and if you'll forgive a "negative" remark -- well, really a positive remark in favour of untyped variables -- there's nothing unscalable about dynamic typing. Some of the largest software systems in production are implemented in dynamically typed languages, and for good reason. It's just as easy to argue that static typing doesn't scale because it is too brittle; with dynamic typing, you get looser coupling for free -- all interactions are mediated via implicit interfaces. With static typing, you need to explicitly design and use those interfaces up-front, or pay a heavy refactoring/compilation cost later. And whether the error is caught when you press "compile" or when you press "run tests", it's still "development-time".

But that's just a passionate quibble. ;-)

#16 Hi,

I'd love to test this beta. I'm a .NET developer with several years experience, so I'm sure I can find any wrinkles should they exist.

my email addy is lee@designrealm.co.uk

#17 Hi,

I'd love to test this beta. I'm a .NET developer with several years experience, so I'm sure I can find any wrinkles should they exist.

my email addy is lee@designrealm.co.uk

Can I add, though, that I feel there are really only two main drawbacks to using .NET with T2D. The first drawback is that you are restricted on what platforms your compiled system can run. The second issue, and one no-one has yet commented on, is that it leaves a very big footprint. My current application that I am working on in .NET stands at 42Mb, whereas I'm sure I could get this down to under 3Mb if I wrote it in C++ (though it would have added about a year to my development time).

On the other hand, the one main (and clearly only important) positive aspect is that it makes the whole development cycle that much faster and feature rich.

That's my 2 cents worth, anyway.

#18 Mark, Aaron and Lee were all sent the download urls.

@aaron: Honestly, I've not used dynamic typing languages enough to learn to appreciate them. The closest I come to dynamic typing in .NET is to cast things to System.Object. Which is good enough for me I suppose.

@lee: I'm guessing you are talking about the footprint of the .NET CLR in addition to your project? I agree that it is rather big, but thankfully (or maybe not) microsoft is pretty aggressive these days about pushing the .NET framework via MicrosoftUpdate... Also, I've seen some (very expensive) tools you could purchase that let your .NET app remove dependancies from the CLR... to allow you to redistribute your app without people neededing .NET installed on their system.. How expensive? I think it was about $1200 per dev.

#19 Jason,

I am also a very experienced C# coder. You can email me the like at dave AT auspient DOT com. I was actually starting down this road myself (only in the design phase havent written any code yet)... but it looks as though you are way ahead of me :-)

thanks,
Dave

#20 @David: email sent.

==============

A little blurb about how long I've been working on this project and how much further I have to go:


I'm a little embarased to admit, but I've spent about 250hrs on the wrapper thus far. (Most of it writing tools to auto-generate the Wrapper code)

I figure that to reach my goal of 100% TorqueScript parity, i have about 50hrs left. But alas, there are a lot of features that I want to (or need to) implement in addition to the TorqueScript parity level, so I probably have a good 200hrs more to go before I'm happy with a "v1"

The beta2 will probably be reduced to the people from beta1 who give good feedback, and should be at around the time I'm at 100% parity with the next version of T2D (whenever it comes out). Minus refactor changes needed for the next version of T2D, I expect to be ready for beta2 sometime next week.

For the v1 release, I am planning on adding various code protection features, .NET forms GUI's, tutorials, and one or more "Starter Packs" (such as an isometric starter pack). I cant give a timeframe on this however, as I am too uncertain on the work needed to estimate with any degree of accuracy.