Game studio vs torque

Tuesday, August 22, PM. From what's been posted by the team it sounds like there will be a sample project that sets up a skeleton game that you fill in. I can almost guarantee that there won't be a full 3D engine that's part of GS. If you want that, look into TorqueX. Thanks for the information. It's about what can be expected and a very good start. Additional question: I have little knowledge in the difference between managed and unmanaged code.

Thanks Joachim. We're not providing a 3D engine as part of the framework, but we are providing several things that point in that direction: A much nicer effect API, along with our new Model class, makes it considerably easier to get graphics onto the screen. The Content Pipeline takes care of a lot of the data conversion and preparation that would previously have needed to be handled by an engine.

Our starter kits are of course going to include more complete engine infrastructures, and they are shipped as source so you use their code if it meets your needs.

And of course there will be full engines available from Torque, and I would imagine from some of you guys in the community! So we're concentrating on underlying things like the Content Pipeline that will make it easier to write any kind of engine, but not actually writing an engine ourselves. That's excellent! I guess I have to do some of the programming myself :. Some nice to haves: - It would be great with a white paper regarding scen graphs and other structural information to help out with the implementation - Ways to switch between different shader models Can HLSL interpret any kind of code and make it into 1.

Wednesday, August 23, AM. Wednesday, August 23, PM. That of course leads me to wonder more about the content pipeline. It would be really helpful with information on the following areas: - Scene graphs didn't I mention that already : - Content guide lines poly count, different kind of effects that can be applied detail textures etc.

I am sure I will come to think of more when I have posted this. Thursday, August 24, AM. The content pipeline does not include any kind of level editor functionality. It basically handles everything after the original content has been created in some other tool, right up to your game runtime.

You can think of it as very roughly occupying the same space that D3DX was used for, but with a very different and I think much more powerful architecture. A lot of the underlying work we have been doing is to build infrastructure and set policy that can apply to any kind of content: A mechanism for plugging in importer and content processor components Mechanisms for serializing content to XML and binary formats A generic ingame content loader that reads the binary serialized format Incremental rebuilds, so only modified content needs to be processed each time User interface hooking all this up to Visual Studio But we've also used this infrastructure to implement some more specific content types that will be available out of the box: Importers for.

FX, etc A DOM document object model designed for storing graphics data meshes, textures, animations in a easily editable format Some standard processors that do useful things to that DOM generate mipmaps, convert texture formats, calculate tangent frames, optimize vertex cache ordering Processors and serializers that convert DOM format objects into Direct3D textures, vertex buffers, and our new Framework Model class So all this gives you a couple of options.

Out of the box, you can just drop. FBX files into Visual Studio, use just a single line of code to load them into your game, and get back a Model instance that you can render.

But if you want to go beyond that, there's a lot of I think very cool infrastructure that you can use to add your own new data types, importers, processing behaviors, and so on. Thursday, August 24, PM.

Aha ok. Friday, August 25, AM. Friday, August 25, PM. With regards to the content pipeline, will it be possible to extend it to package and possibly encrypt content, and if so, to what degree; write a single class, or rewrite a dozen? Tuesday, August 29, AM.

We don't have an out-of-the-box packaging system for version 1, but would appreciate feedback if this is something you would find useful in future. Tuesday, August 29, PM. User content isn't something we've spent a lot of time thinking about yet, so this is all off the top of my head, but I don't see any immediate reason why that shouldn't be doable. You'd probably want to package up the build operation in some other way than using C Express, to give more a user facing "get my content reader" interface as opposed to the developer focused experience we are putting together inside Visual Studio.

But that's just a matter of writing UI. That sound like a lot of immediate data The loader get the data and transforms this in the content DOM. The mesh the loads it's data from this DOM. In my current engine I just map the archive resource file into memory and do a simple memory copy Jepg decoder library I have rewritten a bit to encode from memory to memory. For all other game assets I do the same - meshes, etc. Gives damn fast loading without any immediate allocations, transformations, etc.

At the end, there is just an unlock of all levels, a simple AddDirtyRect 0 and if the resource is needed in the first few frames a PreLoad. Any chance we can do a "load without immediates" in the content pipeline of XNA? Or plug into it, so we can implement by outself? Wednesday, August 30, AM. I'm totally with you on the long loading times issue - that's a pet peeve of mine too!

Fear not, the pipeline is designed to encourage the kind of good practices that lead to good loading times. The intermediate DOM only exists at build time, not inside the actual game.

The reason we have this is to provide common ground so that different kinds of data processing code can all work on the same objects, and thus can be reused and rearranged more flexibly than if eac hone had its own format.

I could download the demos of various engines and borrow a Mac, but maybe this user base could save me some time Joined: Apr 30, Posts: 5, For me, the biggest hot buttons were application stability and developer support, which is where Unity and OTEE get top marks.

The feature set is top notch and soon to be even better with 2. More than good enough to tap into everything Unity can do. Hope this is helpful. Joined: Oct 19, Posts: 1, Joined: Aug 11, Posts: Hi Adam, I too started out on the PC side researching various engines, and like many other people here ended up with Unity on a Mac.

I'm not yet set on what genre I'm going to concentrate on, so my requirements were a little less specific than yours. For example, it was one reason I decided to not use Torque, since it seemed a little too FPS-biased unless you wanted to do a ton of work. In Unity it's all in one IDE, and you do some work, hit the play button in the corner to check it out, do some more changes, hit play again, etc.

In A6 it was code, build, wait for build to finish, try it out and see the issues in a separate window , then go back to coding, then build again, etc..

Things just flowed much better in Unity. Same for the asset workflow, I just found things much quicker in Unity in terms of dropping something in a project directory, having it pop up in the IDE, and dragging it into my project to work on. I also really appreciated the easily available tutorials and documentation that Unity provides. A6 also had a large library of documentation, it just felt a little more scattered and version-dependent, IMHO. Especially with their recent switch to lite-c Those were some of my reaons, but in the end I agree with the prior posters in that trying Unity out is the best and quickest way to see if it's a "fit" for you.

I really enjoy working with Unity, unlike some of the other tools, which just felt a little to much like work for me. In any case, good luck with your research! Joined: Jun 6, Posts: 1, In my experience, Torque and GameStudio kind of force their idea of what a game is down your throat. Unity isn't designed around building FPSes, and yet you can put together a very solid FPS using sample code in nothing flat, and when you decide to do something that the engine developers didn't anticipate you won't have to wrestle with their assumptions.

Obviously, you're talking to a convert here my previous engines were Blitz3D and before that Torque. Joined: Aug 16, Posts: What initially sold me and still sells me on Unity is the fantastic integration with third party tools, everything from Blender to Maya. You don't have to jump through the conversion hoops as with Torque, A7, Virtools, Shockwave, etc.. This magic under the hood, that allows you see your tweaks so quickly, makes a lot of difference to me, and I think to a lot of aspiring independent developers - it's an order of magnitude less annoying and more fun to build stuff.

Add to that the web and cross platform publishing capability, price and not least the community support, and I think it's totally worth the price of a mac as a premium to get in. It was to me. That said, If I wasn't able to justify a mac, I'd probably still be using Torque, which paired with the XNA framework which does a lot of the conversion and object linking stuff may become the platform to beat on Windows.

Or you can wait for the Windows port of Unity, which I predict we'll see early? Advice to both you and me in the meantime: build your assets! Unity's workflow is insanely nice and flexible. Joined: Aug 28, Posts: Darko , Sep 18, Joined: Jun 30, Posts: Jokerminator , Sep 18, Joined: Nov 10, Posts: