All the Unity licenses are a one time payment. No yearly.

Well I guess I should have mentioned we want to get into enterprise mobile development not game development.

You shouldn't really use any of these game engines for anything other then creating games.
[/quote]

Frameworks suitable for the enterprise apps aren't really suitable for games and vice versa. You *can* do it, but really you want to use the right tools for the job.

Agreed...use the right tool for the job. Just like GameMaker is better for 2d games, and Unity3d is better for 3d games, neither of these is good for non-game apps. sure, GameMaker has a bit of 3d, and you can use Unity3d to make 2d games, both can make non-game apps, but really, it isn't worth the workarounds you need.

[quote name='MannyG' timestamp='1354154811' post='5005168']
Is it $800 a year, or a one time purchase so I can put the apps on the android/iphone markets respectively without having to worry about paying to keep them up there for fear unity will file some crazy complaint to tear them down? No question is a stupid question...right? guys?....guys...

As far as the Unity3d licensing, the fees are all one off payments, Unlike Corona and GameSalad which require you to pay yearly.

Not 100% sure but iOS and android may be yearly as they are essentially monotouch and monodroid licenses which themselves are yearly.
[/quote]

monodroid and monotouch are only yearly if you want additional updates. You can keep using it after the subscription has expired, you just won't get new versions of it, With Unity3d you pay once per major version. (so if you buy Unity3D 4.x you will get all unity 4.x updates, but you have to buy an upgrade for Unity3D 5.x when it is released)

You can use the Free version of Unity3D professionally as long as your turnover for the previous fiscal year was below $100.000.

Has anyone here ever built their own engine or worked on one? Perhaps even peeked behind the scenes of one and know what it is like bare-bones wise?

Yes i have, sort of.. allthough they were quite integrated with the target games (So it really depends on your definition of "engine"). It might be more accurate to say that i made heavily datadriven games rather than engines.

The hardest part with making an engine is not really the low level details (That is reasonably easy and there are tons of information out there on how to implement <insert feature/function X here> in an efficient way), The hard part when you make engines (rather than games) is that engines has to be flexible and easy to use in order to have any real value.

To make a game without using an engine you really only need to know how to write a game loop, check the time check for input, update the simulation and generate some output. (generating output and checking time and input is done differently on different platforms, the rest is essentially the same).

[quote name='SimonForsman' timestamp='1354635090' post='5007101']
[quote name='MannyG' timestamp='1354631915' post='5007082']
Has anyone here ever built their own engine or worked on one? Perhaps even peeked behind the scenes of one and know what it is like bare-bones wise?

Yes i have, sort of.. allthough they were quite integrated with the target games (So it really depends on your definition of "engine"). It might be more accurate to say that i made heavily datadriven games rather than engines.

The hardest part with making an engine is not really the low level details (That is reasonably easy and there are tons of information out there on how to implement <insert feature/function X here> in an efficient way), The hard part when you make engines (rather than games) is that engines has to be flexible and easy to use in order to have any real value.

To make a game without using an engine you really only need to know how to write a game loop, check the time check for input, update the simulation and generate some output. (generating output and checking time and input is done differently on different platforms, the rest is essentially the same).
[/quote]

We would like our engine to be multi-platform, that is to say write once and deploy on multiple platforms (android, iphone, tablets for both respectively). How do you think this will fare when building an engine? Is it more along the lines of a library where you build the application in it's native environment but the engine we build is used for certain functions to save time/coding?

Thank you for your reply, btw
[/quote]

a library with time saving game related functions tend to be called a framework rather than an engine. (Engine isn't something that is very strictly defined though), Most modern engines however draw the line between engine and game at a very high level.

Most engines are platforms of their own, the game essentially becomes a bunch of data and scripts(or in some engines, native code(often dynamically linked as a .dll or .so) that run inside the engine. I'd recommend looking at games like Starcraft2 or The Elder Scrolls (3+) for an idea of where high level engines draw the line. (Everything that belongs to those games can be modified using the editor that ships with them, the rest is pretty much the engine).

Lower level engines such as Unity3D draws the line at the GameObject level, (The game consist of GameObjects(With various components attached) and scripts controlling their behaviour, while the engine is responsible for executing those scripts, rendering the scene, etc)