Engine discussion for Team C

Just making a general engine discussion thread for TEAM C since it's been popping up in the other threads. Please discuss it here instead.

Btw, check out this space game made in Unity 3D.

mulletdulla's picture

"Hi all,

I've been playing around with Unity to see what it's like. While I can see its advantages I would rather use something that allows access to the source code. As a programmer having access to source code just makes life easier.
Using C# script I was able to implement working code for a solar system rather quickly in the matter of an hour. My issues arrived however when I tried to implement a simple GUI for selecting an individual planet, 4 hours later still not working the way I want.
If we do go with Unity I won't mind, I just wanted to throw my opinion out their."

Firstly, thanks for jumpin in and having a good muck around with it.

I didn't realise you couldn't get inside the source code - that does seem like a rather large problem considering the amount of changes we need to make to the engine to make the game an RTS

- RTS cameras
- selectable and moveable interface

althought I am suprised that the gui for selecting objects would be so difficult.

Do you have suggestions for another engine?

designerwatts's picture

Hey Mulletdulla,

I've been playing around with Unity and briefly looking over it's GUI, it seems to have a few pre-built options for it.

Have you as yet investigated the documentation support for Unity? Theres an entire section dedicated to it's GUI system.

Or if you're seeking advice, how about asking on their community forums? They've been helpful and quick to answer with my questions so far. :)

I know that TDEA allows you to edit its source code. But it's also $100USD more expensive per person using it then Unity.

Cheers,
Chris Watts

suggo's picture

I have played around a bit with the gui stuff and the skinning options looks like a lot of the 2D stuff as far as buttons, tooltips, windows and scroll bars etc would be much easier using the built in unity system. Picking in 3D would probably be another story.

I have also looked at their first tutorial about creating a 2D platformer although it does not detail that much of the scripting in the tutorial (pretty much says "use this script"), I beleive a lot of the camera stuff can be handled by the scripts. It may not be as efficient but it should be suffice shouldn't it?

souri's picture

My reasons for going the Unity route has been posted about before (it seems to have so many pros for it like multi-platform, network / physics / sound, good tools and support, plus if we could build a knowledge and sharing base here for future projects, it would be awesome) but I'll be happy with whatever the programmers choose to work with since they'll be the ones dealing with it.

Roger's picture

So I want to get this thing going all ready.
So I'm going to help the decision making process along.
Lets start by defining what we require from the engine.
These are my Ideas and not necessarily the requirements we will be using, here goes.

*Robust Documentation
*Strong supporting community
*Ease of programming
*Asset Support, What tools and file formats supported
*Price, what we can afford
*Supported platforms
*network support

What do you guys think? Anything I missed?

mulletdulla's picture

So far as I have been reading, Unity suites all these purposes.

But what will be really important is having a versatile engine that can create a point and click interface that moves independently from the Camera.

From what you were trying to prototype with Unity, is this possible? If we cannot select planets in an orbit like you described -

"My issues arrived however when I tried to implement a simple GUI for selecting an individual planet, 4 hours later still not working the way I want."

This becomes a really big problem for the development of this game as the interface will be dependent on selecting the various planets, fleets and other misc objects on our battle map.

I had an idea that while we render planets, fleets and misc visually in 3D - could the actual GUI be based on selecting 2D invisible overlays or bounding boxes? Then again I don't know if you already tried that.

If we cannot solve this problem without ripping into the source code of Unity (which we can't do, it only provides scripting) then we should thoroughly look at other options. If we can solve this, I am for Unity all the way for all the features it supports.

Roger's picture

The issue is due to the way I had sorted the planets and moons. Changes you make to certain data cascades down to objects enclosed by the object who's data you changed (if you follow me, damn repetitive sentences). I didn't want to resort to reordering the planets, but it will work.
I guess solving these kind of problems will just require changing ones approach.

And yes I'm using bounding boxes.

mulletdulla's picture

You're talking about changing parent data and having the children data affected yeah? Haha I've had frustrating situations come up from that too.

Just tell me if we can make an effective rts interface with the unity engine or if you have another engine you would prefer to work with.

Personally I'm ok when it comes to scripting, but I'm much better with a really good visual engine editor - that being said most of the development work for game play won't be dependent on using a visual editor haha.

anyone else got input on this subject matter?

suggo's picture

I'm quite pleased with what unity has to offer. Is there a trial version of TGEA? There are demo files on the website but I'm not 100% sure they are a trial of the engine or just demos showcasing what it can do. I'll check them out tonight.

I'm willing to go the Unity route if that is the general consensus. Are there any people that disagree with using unity?

souri's picture

If we cannot solve this problem without ripping into the source code of Unity (which we can't do, it only provides scripting) then we should thoroughly look at other options. If we can solve this, I am for Unity all the way for all the features it supports.

This is definitely where we're at at the moment. Roger, if you could check the support forum at the Unity website, that would be great. If it's an issue that can't be resolved easily, then by all means, look into another engine that fits our requirements.

Roger's picture

I would prefer TGEA, only because it offers me the experience of using C++ language code. Experience with c++ and source code is important if your looking to become a game programmer like I am.
However if everyone is going with Unity I'm still on board, as this is still important experience.

@Suggo I've downloaded the TGEA demoes and they are just demo games not a trial version, sorry.

Roger's picture

This is an issue that I have resolved, so I don't think their will be any problems we can't solve.

suggo's picture

Pity about those demos, I will try and look into TGEA a bit more before we come to a decision.

I would be more comfortable with C++ than C# myself, as I'm more familiar with C++ and it would probably be a very beneficial experience seeing the source code for the engine. However I also feel that the unity documentation is more straightforward and simple compared to what I have looked at with TGEA.

souri's picture

Ultimately, it's yours and Sugo's call since you'll be the guys working on the engine side. I'm happy with what decision you guys make. I don't know how robust the network side of Unity is or what unforseen problems may occur with it, so spend some extra time on researching the best solution for what you guys need to work with and what the project requires, and we'll go with that.

souri's picture

When you guys (Roger and Sugo) make a definite decision on an engine, please let me know. I want to approach some devs on sponsoring us some licenses.

designerwatts's picture

*pouts* You guys can get sponsoring?

Now I feel sheepish for going to pay for licences out of my own pocket. XD

souri's picture

I can't make any promises. We'll probably have to pay it back, however.

suggo's picture

Sounds good Souri, we'll let you know

mulletdulla's picture

Alright we've all had a bit of a hiatus over Easter I'm sure. You guys made a conclusion as to which engine you want to use? I really wanna get the ball rolling.

I did some paper prototyping, I'm pretty happy with the results. Gonna spend the new couple weeks building the basic concept in flash.

Updates on everyone else's status?

souri's picture

Actually, doing a mock up of the UI in flash would be a great help. It doesn't need to be fancy, just some mock up screens starting from the beginning of the game right to game selection showing menu selections as well as in-game UI roughs would be a great help for me.

We're currently waiting on JohnN's concept art, and the programmers to choose the engine. For me, I'll need the programmers to give me some specs on resolution size so I can do work on the menus etc

Roger's picture

Ok,
I've done some researching on unity and TGEA and made some comparisons.

They work out equal with these specifications
*Multiplatform support - they both support PC/mac/web with optional extras
*Partical systems - they both support decent partical systems
*Lighting - they both support per-pixel lighting
*texturing
*physics
*GUI
*networkin - both systems will work
*editors - both engines provide easy to use editors
*Community support - both engines come with a great community

Unity has the advantage with these requirements
*Asset support - unity supports all major file formats
*Documentation - has detailed documentation
*price - 199US vs 295US per seat

TGEA has the advantages with these requirements
*Ease of programming - TGEA allows access to the source code with a decent code library

Conclusion
Unities Asset support counters TGEA's advantage of being easier to program as far as development time goes. Leaving Unity as the winner with better documentation and price.

I am disappointed that I won't be programming in C++ but that's how it is. Let's see Sugo's oppinion on this matter.

mulletdulla's picture

There will be plenty of time for you to program with C++ in this lifetime I'm sure haha.

Thanks for the comparison Roger. The only real stand out Unity has is the support as far as I can see, which would undoubtably be very useful considering we are all entering this at an amateur level.

~ edit i cant think proprerly, whats redoubtedly? haha

suggo's picture

I don't think there is anything you have missed, good work. the only thing I would have also mentioned is that TGEA was built around network code, placing it at the core of the engine, which could be advantageous when it comes to implementing the networking side of things (according to what I read on the website it is a top notch networking framework, however I can't tell if that is marketing or fact) but I don't think this outweighs the Unity so much to justify us going with TGEA, after all it can still be implemented with Unity at a lower cost.

I am happy to go with Unity, The asset importing I also think is very important, while testing it out I could very easily create objects in blender and just drag them into the engine which could become very useful. Source code and C++ would have been nice too. In the long run I think TGEA would cost us more time.

on a side note, I also noticed that the new torque 3D release that is coming up has a licensing scheme similar to unity, US$250, no source code and it also lacks the web publishing that unity has, just thought this was interesting.

So I agree it looks like Unity is the engine for us!

Roger's picture

Any news on the Unity licenses. Will we be paying for them ourselves?

souri's picture

Ok, I'm feeling a bit bad because I've been pushing Unity all this time, but it means you guys don't get to work with C+++ and source code. I know how important this is for you guys, particular since it will be you two who'll deal with the actual engine anyway, and I know how important this project can be for your portfolio. I am more than happy if you want to go the TGEA way, so please ponder on it a bit more and give me your final choice on Sunday night, and on Monday I will be seeking companies to sponsor a few licenses of which ever engine you choose.

mulletdulla's picture

Can I just add to this that the scale of the game we are attempting to make is quite large. Larger than we all are really anticipating. In all honestly it could be a 6 to 8 month development cycle.

I personally don't want this as just an item for my portfolio. I want to make a somewhat successful indie game out of this; we have the means and the capabilities to do so. There is nothing to stop us from doing so except ourselves.

Working with C++ is definitely important for professional development but having a shipped title is more invaluable than anything else. I don't mind which engine we use, I would just prefer the one which will make this game the best it can be, if TGEA with C++ will do that then let that be the deciding factor.

Roger's picture

You can't really say which engine will let the game be the best it can be, both engines will result in a very similar game.

I went with Unity because it seems to have an advantage in production time allowing us to put more time into polish. So given equal production time Unity leaves us with a more polished game.

If however you don't care how many months our project takes to complete TGEA has the advantage over Unity.

Hope that helps. Anything extra Suggo?

designerwatts's picture

I would advise this team exercise caution and take on a methodical process to the idea of making this project a long term, published and profitable indie game. Rather then a demo or free-to-download experience.

Taking a project from something that's designed to improve everyone's folio to the level of making it a polished, published and money making indie title comes with a number of considerations. Here's a few:

- Profits : Who gets the profits of this project? Is it intended that profits will be split up equally between all contributors of the project. And additional to this point:
- Who will pay for the expenses of the project? And will they receive the majority profit to cover their costs.
- How will you measure the value of each members stake in the profits?
- You will need to write a contract and agreement for all who work on the project. Getting a lawyer to proof it is a good idea as well.

- Project Management : The scale of this game is quite ambitious, and as such your going to need at least one person dedicated to being the project manager. He'll monitor and measure everyone's tasks and progress. I can't stress how much any team over 2-3 people needs a project manager.

- Production Plan: Design documents are the first step of a game design. But to bring that design into reality the team will need a well considered production plan that elaborates on how the production of this project will be carried out. Without this plan putting together the game and assets will be a haphazard process.

To give you guys just an idea of how much work can go into keeping a team together. I work 30-40 hours a week on my design folio in creating design documents, video logs and level designs for the tower city prototype demo.

I also spend an additional 15-30 hours a week in keeping up with e-mails to the prototype team, writing up production plans, bringing art and code assets together into unity to create something tangible and the other bits of bobs of leading a project. The position of project leader can't be taken lightly.

Overall though from reading the posts about this game. I think, for the fact that this is the first project for many on the team that it needs to be simplified somewhat. You guys have some awesome ideas. :) But one needs to sit down and consider each feature on it's own merit and how much it'll bring to the player experience.

So in summery:
- If this indie game is for profit, work out the details and write up a consented contract for all who work on it.
- Find a dedicated production Manager and nominate a leader. Make sure the leader is willing to accept some harsh time requirements for the project.
- Create a production plan to work out how this game is going to be created from pre-production to polish.
- Refine the feature list and make sure all features are worth their implementation time and resources required to create it.

I hope all this helps you guys out. :)

Cheers,
Chris Watts.

suggo's picture

No matter which engine we go with we are going to be doing some learning. I suppose that is the main purpose, to gain experience. If we look at what we want to get out as far as experience is concerned, access to the TGEA source code could be very good for our education. This decision just keeps getting more difficult. I think Unity provides a simpler way for us to get the finished product but TGEA allows us more access as to how we get this result.

Both engines are quite capable of completing the task. TGEA has a different approach to the object import. Unity allowed me to drag and drop, it doesn't get much simpler. TGEA we have to export in a specific format which shouldn't be a problem as there are numerous exporters and scripts out there for most major 3D modeling packages I had a quick look into an export script for Blender but have not been able to test it but the facilities are there.

So I am leaning a bit more to the TGEA side now. if we go this route it will provide more experience for myself and roger. I think TGEA would be a good choice and provide a more professional level of experience. I do like the look of how Unity works, it speeds up game development as an engine is supposed to. let's say for experience I would go with TGEA and if the production schedule was my main concern I would go Unity. I'm still a little torn as to which way to go. but as has been mentioned myself and roger will be the only ones really affected and what we are more comfortable with could be just as beneficial as an efficient engine like Unity. I for one have never really used c# except for one hello world test I did a few months back, C++ is more my thing and learning a bit of torque script would be fine with me.

Roger if you would rather use C++ and torque script we should go that route. I'm still a bit unsure as to the better choice. I suppose I'm a little worried that we will get tied up in too much code if we go TGEA. Roger do you have any concerns with either engine?

EDIT: Sorry for being indecisive about this. If you are already shopping around for Unity licenses that is fine. I just had some thoughts and wanted to throw them out there.

Roger's picture

I think we should be treating this project more as a learning experience then a successful product. While it will be great to be a part of the process for delivering a successful product, and a great feather in our caps. This is a first time project for many of us and having experience is more important then contributing to a successful product.

So just in case this product sees very little interest lets concentrate on homing our skills. If our end product does earn recognition and success that will be a great bonus.

Having said all that, with the intention of earning valuable experience I would choose TGEA.