Evaluating Unity for upcoming Serious Game

Hello all,

Sorry for the intrusion if this is not the correct board, didn’t see anything specifically for demo/evaluation questions.

Our company is currently evaluating engines for a somewhat basic 3D survival game that will be featured in a Native American museum. I just returned from the Austin GDC where I had to chance to see a demo of the upcoming release and was very impressed with the toolset among other things. The bombshell was the Mac>>PC pipeline.

We are primarily a PC shop, and I have a little heartburn about 1. Buying new hardware for the developers and 2. Trusting the 1-button publish for PC. We really like the package and we feel it has everything we are looking for in a engine to grow with… but I wanted to get some feedback from the developer community before we begin testing the engine and/or buying Macs for the team.

I appreciate any feedback specifically relating to PC deployment/performance. Looking forward to collaborating.

Sincerely,
Matt Johnson
Red Knight Learning Systems

For a small project you would probably only need one mac for programming and publishing. All of the other assets and testing could be done on your existing hardware.

I’ve never published anything for the PC with it but I’m sure many here have and can let you know if they have run into any problems.

Publishing for the PC always has worked for me (also doing serious games) and with the new DX based renderer everything should be pretty smooth.

I spent the better part of 2006 either working with or testing a number of PC-based engines (Torque, DX Studio, Anark Studio, RH Deep Creator, Virtools) before turning to Unity for our serious games development. In exchange for the additional investment in hardware (which I needed to upgrade anyways) I got a much more stable, flexible and capable tool than any of those I’ve listed. I know there are at least a couple other “dedicated Windows” developers here, who like myself, got Macs purely because it’s the only way we could get Unity. In retrospect, I’m very happy with my decision.

@All:

Thanks for the feedback, sounds like it is at least worth a look considering the shortcomings of alot of the engines servicing this market.

It is also good to hear that companies are accepting and developing Serious Games… and using great tools like this to develop them!

How is the GUI editor in the engine?

@bigkahuna

We built the prototype for our project in TGE, but I have never felt like it was a complete product or flexible enough (without a great deal of rework) to handle the variety of interactions necessary for Serious Games.

I agree with you in the long run, I would rather invest in the hardware now then be stuck mid-project with the little engine that “couldn’t”

Cheers,
MJ

Right now GUI stuff is a little bit tricky, but the next release (sometime this summer):

So it should be perfectly fine. :slight_smile: Good luck!

Matt_RKLS, I’ve never had any problem taking whatever project I was working on, going into the build setting, selecting Windows, and compiling a Windows game. I’ve done a custom game for a company in England and it worked flawlessly, and am in the later stages of my own first “serious” game and also have had no problems doing a Windows compile.

This is a rare engine indeed and well worth an investment in a single iMac ($1200) to do all the Unity work in. Use another local PC for your assets if you need be or turn on Windows file sharing and let the PC guys doing the art, textures and scripts simply put their work into your project folder on the iMac.

What you saw in Unity is what you get. A stellar game engine, perfect workflow, stable, and a great community of developers and users here. I’ve tried (almost) every game engine since the dawn of computing and Unity is simply the best ever for almost any developer.

Welcome aboard (it’ll save me saying that later :smile: )

David

PS. Unity 2 will rock even harder.

What you want to do you will be able to do with ease.

The new release of Unity has a new GUI system, and while It is quite different, the guys testing it love it.
I pretty much mastered the old way, and will stick with that until I have the playtime to look at the new system. It is very impressive in the demo that the testers are using for reference.

I also tested Unity Pro a year or so ago, and built a couple of Standalones for Windows. No problems, but only build testing will show how the shaders perfom, and the Unity shader system gives you many options for how things look down the line. So if you give yourself a little time to test the builds and make changes if necess, theres pretty much a solution for any pc hardware configuration.

The loweset spec pc I have tested on is a 300mhtz HP, with a Geforce4 64mb-
Sweet as…
HTH
AC

This is all great feedback, thanks everyone. After viewing all the videos and demos and reading a great deal on the site last night, I’m convinced its worth investing in a Mac.

I have just a few more questions, then I will go to the Apple store :).

I have read that the scripting system is based off JavaScript and C#… is that “either” or “or” when it comes to the two languages? Most of our experience is in multimedia scripting like ActionScript and Lingo. Does anyone have specific links to learning resources for these languages as they relate to Unity?

We are also using 3DS Max 9 for our art pipeline, I saw where it is not a native import, but can be exported into a universal format with all animation/bones etc. in tact. Just wanted to know if anyone had experiences with the Max>>Unity pipeline?

Thanks again for all the insight, it seems like this is a great community, I look forward to contibuting as well once our team gets up to speed!

Thanks,
Matt

You can use both JavaScript and C# scripts in the same game, or even attached to the same object if you want… assuming that’s what you’re asking.

Unfortunately, I haven’t found any “game oriented” Javascript books, but the transition from ActionScript to JavaScript should be painless enough. Tom Higgins, the Unity Evangelist, was formerly with Macromedia and Director, and he got up to speed in a couple of days, didn’t ya Tom?

I work with sub contractors who use 3DS Max, and the format of choice is .FBX. No major issues that I can recall. We are having some problems with .FBX files from Maya at the moment, but I’m sure we’ll sort it out.

Welcome to the club!

Here’s the doc on using 3DSMax with Unity: http://unity3d.com/Documentation/Manual/HOWTO-ImportObjectMax.html

With Unity, as bigkihuna noted, you can use Javascript and C# together, or separately. You can also use Boo with or without the other two languages if the python syntax floats your boat.

not quite done yet but this is a good start:

i recommend going through the tuts the scripts on the wiki as well - it will all start to make sense pretty quickly. welcome ; )

If you know ActionScript then jumping into scripting with JavaScript in Unity will be a simple matter for a decent programmer. I’ve done some Flash stuff and Actionscript (v2) and the syntax between the two seems similar to me. I came from a background of doing only simply JavaScript stuff for websites and now have a very good (if still basic) knowledge of how to do stuff in Javascript.

With regards to Studio Max, Ron (the other widget monkey) does all our modeling in the latest version of Max (the firm we work for has licenses for it) and there has never been a problem importing anything he’s done for me into a Unity project, fully textured etc etc. If that’s the art pipeline you have available, you’re all set.

And my recommendation for an iMac that handle Unity well and gives you the best cost-performance ration is the higher end (2.4GHz) 20". Throw an extra 1GB RAM stick in there (NOT from Apple, just grab one from NewEgg or wherever, lots cheaper) and you’ll be thrilled with Unity’s performance.

If lower end model 24" screen model appeals for the real estate, I’d still say to simply go out and grab a $200 20" flatscreen and just plug that into the 20". Lots of screen real estate then.

Good luck!

I will check out those links for the 3DS Max import and the JavaScript / C# primer. Is there any speed benefit of one of these languages over the other, or since they are both pre-compiled to a IL… does the engine execute them the same?

Got someone to bring me a mac in the next couple of days… so here goes the 30 day trial. Thanks for all the feedback.

Cheers,
Matt

There really isn’t a speed benefit between any three languages.

One might argue it’s easier to find areas in C# where an optimization could be made, but that’s really not the point. If you wrote the same exact code in both languages, they should perform equally.

That’s one of the “selling points” of Unity, that a game can be written in JavaScript and not run any slower than had it been written in a more complex language.

I understand that the bytecode generated by Javascript/C#/Boo is 50% slower than if it was hand-coded in C++. However, that’s rarely an issue unless your game logic itself is massively CPU intensive for some reason. (Maybe if you were doing hard-core AI stuff, for example? And if that’s the case, you can write a C++ plugin to get full speed.) All the “hard stuff” in Unity is already fully native optimized code (3D/physics/animation/audio), and it’s reasonably likely that you’re going to end up waiting on the graphics card anyway unless your graphics are relatively simple.

–Eric

Well, for someone who hesitant to make the switch, 50% slower for SCRIPTING and logic is WAY FASTER than if you were to use most other engines or use your own and use a language like Lua for script. So, it’s still win for us and Unity :smile:

Edit - Is it really 50% slower? I got the impression .NET code is only about 10%-20%… Hmm

It says 50% in the docs. And yes, my point is that this is unlikely to be an issue, just something to be aware of. :slight_smile: Generally stuff made with Unity seems as fast or faster than “traditionally” coded stuff because Unity itself is fast, so if you’re using some extra cycles for the scripting logic, it hardly matters in most cases. A small price to pay for much increased ease and speed of development.

–Eric

The 50% figure really depends on what you are doing of course. If you iterate through an array and modify ints it can be 30% slower than C++. Other cases it can be 50% or if you use JavaScript’s dynamic typing it can be lower than that.

Dynamic typing in JavaScript can always be avoided though, we even have a #pragma strict which issues compile errors whereever dynamic typing is being used.

The main point is what to compare against though, if you compare against LUA or Mozilla JavaScript etc. They are somewhere between 8-30 times slower than C++.
So the JavaScript / C# provided in Unity is somewhere between 4-15 times faster than scripting languages provided in other engines. The result of that is developers can do practically everything in script code. In other engines, you would be - rightly so - called crazy to do heavy things like mesh deformation each frame, in Unity it’s just fine. Same for heavy AI calculations.

As an example. When we created the terrain engine for Unity 2.0 we wrote it completely in C# at first. All LOD calculations, tree rendering, detail mesh generation, billboarding, rendering, terrain editing tools everything. It was pretty fast, we got ok framerates on 2049*2049 large heightmaps with 30.000 trees. I was actually surprised myself how fast it was running in C#.

In the end we decided to port part of the terrain engine to C++. For us getting the last ounce of performance from the terrain renderer was important. And some areas like generating grass patches surrounding the camera, really benefitted from the speed increase. On the other hand porting the code to C++ took quite a while of course.

Some parts of it are still written in C# and only the parts that really were performance heavy we ported to C++. The terrain editing tools are written completely in C#.

The tradeoff with scripting languages is always one of iteration time and development speed. If i can modify a script while in playmode or even without having to restart the editor in less than 2 seconds. Thats a huge deal, it means i am actually being encouraged to experiment. Thats interesting because it means script code will most likely translate into better game code than if you had written it in C++. Simply because you will try out more things before settling on something. In the case of the terrain engine, we were able to experiment with so many things which we simply wouldn’t have had time for had we written it in C++.

In engine programming this might not be so important but game code is hardly science. There is no one true way of game play. It’s all experimentation. Iteration time is key here and this is where scripting languages rule.
Jit’d script runtimes give you the iteration time and at the same time make you pay very little in performance for it. The other important thing to consider is that the algorithms that are actually taking up performance, like rendering, animation, physics, raycasting are all in highly optimized C++ code. Game code usally takes up somewhere around 20% of the total cpu budget. Thus the 50% loss over C++ for gamecode results only in a 10% overall loss in performance as compared to C++.