Has anyone ever thought they should just make their game native?

This ain't no Unity gripe thread at all, I'm just curious to get some wisdom from anyone who's maybe followed through on this.

So I'm wanting to embark on a new game project. But I am also simultaneously wanting to get more proficient at Objective-C and deeper level programming with it. So I thought maybe I should just do my game from scratch with OpenGL directly. My game is only a 2.5D side scroller, so I wouldn't have to be implementing any really hard systems like Umbra or CSG or realtime shadows or any fancy rendering effects. Just drawing of meshes panning the screen, implementing skeletal animation, a scene graph, and a physics engine.

But I'd also like to get my game done. Which is my concern.

I am wondering, maybe I should just do my game in Unity and write something else in Objective-C and OpenGL thats smaller and simpler, and I would actually be farther ahead. Or just make my game native entirely.

Has anyone done this? Is going the route of doing the whole thing native, even for a simple 2.5d side scroller really an obscene task in comparison to doing it in Unity?

 

I think the first consideration would be whether or not you want to release on multiple platforms to maximise your game's exposure?

 

No, this doesn't bother me.

Also the other half-reason is my game I intend to be heavily physics based and I am thinking being able to use the latest bullet physics library would actually save a lot of hassle. But I don't know if it's as much hassle compared to have to handle the engine code myself.

 

Honestly, if you want to make a game from scratch, I say go for it!
The amount you will learn from doing so will make you a much better programmer in the end.
It isn't an easy task though. There is a lot of maths involved.

 

My last game was native, (Marvel Avengers Alliance). At the time we started it, Unity wasn't a great solution for our needs. It was a lot more work than it needed to be and the android version was port. It was a mix of ios libs (mostly for UI and such), some third party libs and tons of custom code and tools. If we were doing something super crazy unique it would have been a lot more worth it, but the actual mechanics of the game were pretty straight forward. We reinvented the wheel many time during that project. It was my first native iOS app, and probably my last. Proud of the product, a great experience and team, but just not something I want to repeat.

This is so very true. When you explore it can often lead to better solutions based on different approaches. More knowledge and experience is never a bad thing.

 

I'm on engine iteration number 4 now , I just can't help play with tech and I enjoy doing it.

Easiest thing to do so you don't get bogged down, get LWJGL http://lwjgl.org/ and eclipse..

I got as far as 3D renderer / textures / shader compiler and .OBJ loader before I swapped over to C++ to do the more advanced components.. It's fun and you'll learn a hell of a lot, it's going to be far more difficult than using a prebuilt engine for the first couple of months. But luckily enough most of the matrix calculations / quaternion calculations and math libraries are freely available for to use as you wish.

LWJGL is a great way to code with OpenGL and learn exactly what it does, without the headache of C++ and memory management. In terms of performance it was hardly worth mentioning.

 

I think you'll find a ginormous productivity advantage in using a well-established, thoroughly documented engine compared to rolling your own. As an example, you're saying that your game is a 2.5d scroller, which probably means you'll need to import 3D assets from some other application. Coding up a content pipeline like that is, at best, a sizable undertaking that doesn't add anything directly related to your game.

It's a great learning experience, but it's probably best left to small weekend projects rather than a full game that is intended for eventual release.

 

Unity exports native C++ code too actually.
If you mean "native" by "without using an already available game engine", it doesn't hurt to experiment with creating your own.
It would take a longer time before you start writing your game, but the feeling is much more rewarding.

I have recently made a small 3D platform engine for my upcoming 3DS game in C++.
It can only be used for that particular game, it can only export to the Nintendo 3DS, but seeing it working makes me feel so much more delighted.
The only concern I have with it is the collision detection, which involves mathematics for as long as the game is in development.

 

Yeah I did think about this when I head of this fighting game built with C++ that runs like soul caliber. But I don't know any C++ so I figured that it would take like 12 years to build my game. Native to me looks like trying to climb mt. Everest.

 

If you're already familiar to programming, the programming part of that game in C++ would take you 2 years at the least actually.
Programming in a different language really isn't as different as you might expect.
It's all thanks to the fact that games are all built the same way and C# doesn't differ much from C++.

The real concern is that Unity does all the 'boring' stuff for you, so you can focus on scripting the game.
In C++ at the other hand, you should find and use the right libraries, create the framework, set up rendering and memory stuff, etc.
And this all comes before you can start scripting your game.

As for the libraries, I recommend you to stick with OpenGL and OpenAL.
They're cross-platform, widely used (which means a lot of support is available) and it comes with almost every OS pre-installed (probably except for those hobbyist operating systems out these, which nobody uses anyway).

 

I was working with XNA for about 4 years in my sparetime to get a 2D platformer for the Xbox 360 done, see Face-Plant Adventures.

I enjoyed writing the tech and gamplay "from scratch". I mean XNA already has a decent API and you don't really need to go low-level, but it's also not a game editor like Unity.

On the other hand, when I look back, I think I would use Unity now. Because I didn't only write the game, I also wrote all the tools and a level editor. These tools have to be rock-solid because other people use these tools and "rock-solid" is where it gets boring Personally I also knew how everything works and should be implemented upfront, since it was not my first game of this genre, so it was not that interesting to write "the tech", it was just work that has to be done.

Long story short, if you like to write tech and want to know how things are done in a game engine, don't use Unity. If you just want to write a game, you're faster using Unity.

Hope it makes sense.

 

I did make a native 3D game with OpenGL once. But all you end up doing is writing things like 3D model importers and physics engines. So you might as well use Unity which has that all done for you.

Why stop at native code? Why not write your game in machine code? Or just 1's and 0's 101010100101010010101

 

PC:
I enjoy writing native code. You need not follow anyone's workflow nor are you bound to restrictions someone has put in place. (Looking at threading in Unity 4) However you quickly run into some tedious task such as writing an asset pipeline like yoonitee mentioned.

About Android.. I've never written "native" code for android but if we count Java as pseudo-native then the only reason I would choose Unity over writing Java is because you can develop most without even having an android device nearby, just debug with PC and when you get it done toss it to Android. + Java sucks balls.

Edit: Also the documentation about Unity shaders is so bad it hurts more than helps. So if you need a lot of control in shaders Unity is a pain in the rear to work with.

 

Well maybe not a game, but I always make my PHP code in nano (command line text editor for Linux).
The big advantage is that I immediately apply all the changes on the server without the need to re-upload it at every little change.

I mean, what's easier?
Method 1:
1. Log in on SSH.
2. "screen -r"
3. Open the file in nano.
4. Make changes to the code.
5. CTRL + O to save it.
6. Check it out in the web browser of your PC.

Method 2:
1. Login on FileZilla.
2. Click through many folders until you reach your file.
3. Right-click.
4. Click "Open/Edit" (or something like that).
5. Download the code to your temporary files.
6. This will open a text editor you defined before. (If it happens to be Visual Studio or DreamWeaver, imagine there is another step: wait until the splash screen finally disappears.)
7. Make changes to the code.
8. CTRL + S to save it.
9. Go back to FileZilla.
10. Confirm the fact you want to upload the updated code to the server.
11. Check it out in the web browser of your PC.

 

Do you want to make a game, or make a game engine?

That should be the answer to your question

 

I've thought about it. I've written a fair few things with C++ and existing 3rd party libraries rather than engines, and I've written a bunch of... I guess "technical prototypes" is as good a term as anything, where I write a piece of an engine and a related game for learning purposes.

When it comes to making a full game these days, though, none of those approaches strikes me as the best tool for the job. When it comes to getting things done, making full use of what's already available is just too huge a productivity boost to ignore (especially, as mentioned, when it comes to cross-platform support!). Also, while I'm confident I could make decent enough stuff of my own, I'm not confident it'd be better than something I could license that's (presumably) had expert attention for years before I even thought about maybe using it.

 

I'll agree with this, not sure what some people are talking about.. To make a basic game in OpenGL it isn't that difficult nor is it that much more time consuming bar the initial month outlay if you know how to make games properly. There's plenty of tutorials and resources you can run through and have the basic outlay set up in a couple of weeks or so (If you really go at it)..

It's when you want to polish the crap out of it to meet targets like A, AA or AAA development, improve the lighting make it cross platform etc. it becomes a nightmare.. Doing a PC only renderer with some tools to make your own game isn't exactly the all consuming year upon year time drain some are making it out to be. In fact as you know exactly how it all runs and works, it can make life easier in some respects. You can spend a year just learning another API properly..

Making a commercial engine? I wouldn't even bother, it's far too much for a team of 10 never mind a single person.