For someone with ZERO programming experience, the generally accepted "best" way to learn programming is using a language with a very tight feedback loop. That is, write some code, see it run, repeat and rinse. Often this is referred to as REPL (read-eval-print-loop), which is a glorified way of saying a programming language that you can write code and see it execute right away. Python is a great example of this kind of language, as can be LUA.

The ideal when learning ANYTHING is to focus and cut down on noise. When you were learning English, you focused on the basics like the alphabet first before even considering what a preposition was. You started with small and easily identified words and built up from there. Programming is no different really.

I actually wrote a guide aimed at helping parents start their kids on game programming but the same basic advice is just as applicable to anyone of any age. You want to focus on a language/library/tool that rewards you constantly. A beginner shouldn't start with a language that requires a few hundreds lines of code to draw a dot on screen for example. Nor should they be dealing with complex linker or build settings from the 70s. As a result I tend to think C++ or even Java ( im looking at you Eclipse/Maven/Gradle!!! ) are pretty poor choices. C# is better, probably the best of those three, due to the great tooling and more polished nature of the language, but even it is lower level than I would recommend.

I personally think you should start with something like Lua/LOVE2D or Python/PyGame if you are focused on learning code first. Or a higher level tool like Stencyl, RPG Maker or their ilk, if you are interested in game development first and programming second.

In all honesty, I think that you are setting yourself up for a failure. But if you still do believe in yourself, you definitely should chop your project into smaller pieces, and work on one piece at a time.

-For example you could create one type of a game, where you can just put trees or structures down on a map, and later on evolve that to a world editor.

-Secondly you could do a small game like pong that works as a 2 player game over a network. Eventually you could learn about how to create a multiplayer game and apply these things into your online game.

Surely these should be split even in smaller tasks, but the idea is that like jigsaw puzzle you start putting it together from edges piece by a piece and maybe create some islands of area then merge some islands together and eventually you'll have your whole picture finished.

Also when it comes to engines, you could just toss the coin to determine if you should use Unity or Unreal, other wise you might end up spending next 1 to 2 years pondering if Unity is better or if Unreal would the best choice. Just choose one and stick with it. Although I do personally think that Unity is more suited for low poly things, since Unreal doesn't seem to be optimized into low polygon things.

You are talking about the free unity version right?

What's your eventual goal or goals? Do you want a job in the industry? Do you want to make your own games for money? What kind of games? From what I know which might be out of date now is that high performance networking code is in C++. In your other thread you mentioned an MMO right? If so you're interested in high performance networking code. If your eventual goal is an MMO and you are goal oriented then it would make sense to go the C++ route, unless you want to learn two languages.

I did mention an mmo. But it will turn out to be just an ORPG since I don't have the finances to supply a 20000 player server I will have about 400-500 online AT THE MOST. The game isn't too complicated but it will have some complicated assets these include:

• low poly (but stylish) 3D Graphics. Examples (I did not create these) Example 1, Example 2
• First Person capabilities
• PvP system
• the ability to create a factions with base/city building (not complex, just being able to place walls, doors etc.)
• Steampunkish/industial revolution theme with muskets, rudimintary pistols, steam power, flying and regular ships (will only be able to pilot) while also being able to create medieval weapons like swords, maces, mauls, battleaxes, waraxes, etc.
• some guis for the stuff I have listed but some will use commands as well.
• Limited creatures (I.E No taming, riding etc.) just used for small resourses
• Only crafting will be that for metallic items you will have to be close to a forge and the same for other items in the same manner.

So thats what I have so far and thats what I want to create.

Oh, I remember that second example... The guy taught me how to make birch trees

Still, try pong for a change. Use C# and Monogame, or C++ and SDL (Since you want an mmorpg)

Not to be nit-picky Im not going for a massively online game since that would be troubling to finance but Im going to code pong and simple games first for practice then maybe after I learn c++, code a couple of simple games, in a couple months I will start my ORPG ;).

It'll be more like a year before starting an ORPG. I've been coding for about a year, and haven't fully made a game (I've made pong and whatnot, but haven't finished something I actually want to make).

What's your eventual goal or goals? Do you want a job in the industry? Do you want to make your own games for money? What kind of games? From what I know which might be out of date now is that high performance networking code is in C++. In your other thread you mentioned an MMO right? If so you're interested in high performance networking code. If your eventual goal is an MMO and you are goal oriented then it would make sense to go the C++ route, unless you want to learn two languages.

I did mention an mmo. But it will turn out to be just an ORPG since I don't have the finances to supply a 20000 player server I will have about 400-500 online AT THE MOST. The game isn't too complicated but it will have some complicated assets these include:

• low poly (but stylish) 3D Graphics. Examples (I did not create these) Example 1, Example 2
• First Person capabilities
• PvP system
• the ability to create a factions with base/city building (not complex, just being able to place walls, doors etc.)
• Steampunkish/industial revolution theme with muskets, rudimintary pistols, steam power, flying and regular ships (will only be able to pilot) while also being able to create medieval weapons like swords, maces, mauls, battleaxes, waraxes, etc.
• some guis for the stuff I have listed but some will use commands as well.
• Limited creatures (I.E No taming, riding etc.) just used for small resourses
• Only crafting will be that for metallic items you will have to be close to a forge and the same for other items in the same manner.

So thats what I have so far and thats what I want to create.

Oh, I remember that second example... The guy taught me how to make birch trees

Still, try pong for a change. Use C# and Monogame, or C++ and SDL (Since you want an mmorpg)

Not to be nit-picky Im not going for a massively online game since that would be troubling to finance but Im going to code pong and simple games first for practice then maybe after I learn c++, code a couple of simple games, in a couple months I will start my ORPG ;).

It'll be more like a year before starting an ORPG. I've been coding for about a year, and haven't fully made a game (I've made pong and whatnot, but haven't finished something I actually want to make).

Well a couple of months was an estimate. I may have more time on my hands than you have. Ive been getting to know Unity and I am going to order a book on c# coding as well as find online tutorials and miniprojects to make. I want to fully know blender, unity and c# (or what I need to know) before I start my ORPG, if it takes less than a year great!, if it takes a year or more so be it.

If you are going C# I have posted some resources in this http://www.gamedev.net/topic/672076-want-to-learn-c/ thread. Two of them are full fledged books, one of which is a pdf file for download.

If you are going C# I have posted some resources in this http://www.gamedev.net/topic/672076-want-to-learn-c/ thread. Two of them are full fledged books, one of which is a pdf file for download.

Nice man Ill check them out. I will also be ordering a book off of amazon http://www.amazon.com/gp/product/1518800270?psc=1&redirect=true&ref_=ox_sc_act_title_1&smid=ATVPDKIKX0DER

I don't know about that book it says volume 3 as in you would need the other two volumes as well. And I'd be weary of anything that claims to learn programming in a day.

Check out the two I mentioned they might be good for you... in fact the one I mentioned is a pdf is used for a university course. Besides its not just learning a programming language its learning to program... there's a difference.

edit - in other words take your time, learn it properly, and go step by step.

this one's contents agree with how I think it should be taught. http://www.introprogramming.info/english-intro-csharp-book/read-online/

Hello I have almost no coding/programming experience or game developement experience for that matter. I want to start making some small games to get started but I don't know which engine to use. So I ask which game engine I should use to create a 3D low poly, Online, PvP game (or work my way up to that). Or which engine should I use for any games period given my level of experience.

Just to add my 5 cents as a longtime Unity User (4 years total) and newbie Unreal Engine 4 user.

Ue4 is a fantastic engine, I am really excited about learning the ins and outs of it... but the more I learn, the clearer the picture gets.

IMO, Unity 5 is easier to grasp for a newbie, and lets you still work more efficient even if you have more expierience. It is clearly made from the ground up for Indies and Small Teams needing all the efficiency they can get, and Unity has the better Tutorials and API documentation.

Many things are neatly integrated into the Editor in Unity. And many things are simple that are not in Unreal.

Need to transfer something from one scene to another? Drag and Drop it from the Scene Object list to the Asset Browser, Unity will automatically create a prefab out of it. Intuitive. In Unreal, you need to make a blueprint out of it, and there are limits to what you can convert to blueprint. Only then can it be saved and used in another scene.

Need to create a cubemap out of 6 images to create your skybox from? Just create an empty cubemap in Unity, drag and drop your 6 images into the right slots, and Unity handles the rest. Unreal will ask you to use outside tools to create a DDS format image out of your 6 source image. Only that can be used as cubemap source.

There is Blueprint, but for me as a programmer this is just another Programming language to learn. I am sure once you master it you can drag and drop scripts together much faster than with writing code, but then you cannot look at an image of a blueprint script and reproduce that 1 to 1 because the node names differ from the name in the list you pick the nodes from.

If I had to start over... I most probably would start with Unity again.

Now, where there is light, there is also shadow. Unreal clearly has the edge when it comes to rendering quality, at least out-of-the-box. It is much more forgiving in making the best of the 3D models you feed it (Unity by contrast can be rather fickle, if some normal is not aligned correct or there is some pixel error in the normalmap, Unity will show it, while Unreal will often not). There are so many options to completly confuse the beginner, but giving the more expierienced a lot of control over many aspects of the renderer and engine.

So much stuff that need to be bought from the Asset Store in Unity comes out of the box with Unreal.

And then there is the engine source code... if you are an able programmer, and really need something that is not supported out of the box, you can make it happen.

More often than not, that means ugly workarounds in Unity because their engine core is still closed source. And you never know if your ugly workaround is still supported in a new engine version (happened to me, though that was a PhysX physics engine feature that got cut).

IMO, Unreal Engine 4 is written by professional game devs for TEAMS of professional game devs... you know, the teams where everyone is a specialist and knows his thing.

Unity 5 by contrast is made for the small Indie lone dev and small mobile teams.

Unreal Engine 4 can be clearly used for creating mobile games and by Indies and hobbyists... you just will need more time to get into it, and more tools to suplement engine editor features. Unity might just make you a little bit more efficient, if you are not fussed about the visual scripting and get able to learn C# (the C# API of Unity is really good).

Unity 5 clearly can be used by larger teams and for big fat PC games... you just need to massage the renderer more to get good graphics quality out of it for modern 3D PC games, you might need 3rd party assets to add missing engine features, and a 3D artist that knows how to make his models look good in the engine.

AFAIK Unity has never been rewritten from scratch... seems like the Unity team is just adding features with every new version, sometimes replacing systems, but often just adding to them (hence the bloat of different renderers for Unity, forward, legacy deferred, deferred). And they have started as an Indie and mobile friendly engine.

Unreal by contrast gets rewritten from scratch for every major release and started life as the engine for epics own games... thus it is clearly PC centric, and has less bloat. You can be sure no part of the engine is older than 2012 (Or whenever they started developing the version 4)... in Unity there might be still part in the engine from 2006, from Unity 1 days.

2 radically different approaches producing 2 similarly powerful and well supported engines capable of producing any kind of game. I personally would say Unity is just that little bit more approachable for a beginner, save the blueprint system (which might be more approachable for a non-programmer). Unreal is the right engine for everyone who "hits the roof" with Unity when trying to develop powerful PC class 3D games.

Now, in your case, you might want to start with something simpler than any of these engines before moving to them. Else you will face a quite steep learning curve with both of them.

If you want to bang your head against that learning curve from the beginning, or feel you have dabbled enough in creating small 2D games from scratch, I personally would give Unity 5 a go.

For small games with simple graphics, Unity 5 is more than enough, and you will find it less confusing (thanks to less options for many things) and the documentation more approachable (don't get me wrong, there is plenty of documentation on Unreal Engine 4, its just often hard to find the right page).

Better yet, take a month or two, download both engines and dabble in both. See which one you like more. Maybe you are the visual scripting guy, and you like many options in your engine editor. Maybe you find the unity editor more confusing, or your models just look terrible in Unity, and good out of the box in Unreal.

The differences are sometimes subtle, so by testing both, you can make a more educated choice.

And let me tell you that one last thing: don't try to haste your game development. spending 2 or 6 months in selecting an engine is not wasted time. Compared to the time you will spend developing each of your games even if you are expierienced, it is nothing (multiple years often for 3D games, at least when you are alone and without much of a budget). Compared to the time it will take you to learn everything about 3D game development, it is even less (maybe 3 years... maybe more. I have spent 6 years learning, 20 hours per week and more, and I still feel like a beginner often).

Spend some months with both engines, these months are well spent and meaningless in light of the total time you will spend with the rest of your journey.

Unreal by contrast gets rewritten from scratch for every major release

You can be sure no part of the engine is older than 2012 (Or whenever they started developing the version 4)

Epic may claim this but it is not true. I still have a snapshot from 2009 which has the GOW source and the engine still has a Glide render path in it for Voodoo cards. I also have the current version and there is a lot of shared code between the two.

Epic may claim this but it is not true. I still have a snapshot from 2009 which has the GOW source and the engine still has a Glide render path in it for Voodoo cards. I also have the current version and there is a lot of shared code between the two.

interesting... well, of course I went with Epics words, can't say if they are true or not (Unity will also not promote their engine with "newer rewritten, we keep our code alive for 8+ years!", so very well possible that Epic does the same).

But: you can at least tell that Epic TRIES to clean up old junk when moving to a new version. Which of course will break backwards compatibility (making it even harder to move a project from Unreal 3 to Unreal 4 for example), but seeing how bad the upgrade path for existing projects is in Unity (one of the reasons I took a break from Unity), and how much JUNK is left in the engine in Unitys case (If the deferred renderer would get as much attention by Unity like it does by Unreal, there would be less people still asking for the forward rendering path (yes I know there are still platforms and use cases that ask for a forward renderer)), I have to say I like Epics way of handling new engine versions better even if their claims are not 100% true.

Then there is the thing that Unity sometimes tries to implement something halfbaked, and relies way to much on 3rd party devs... the whole legacy deferred (Deferred lighting) renderer was a pretty lame duck... Unity users got stuck with this broken implementation for 3 years, while other engines already implemented a true deferred renderer. To this day FXAA is pretty much your only choice for Antialiasing if not using forward rendering in Unity... while better solutions have been around for years and are implemented by Unreal 4.

Not saying that it is okay to lie about a total rewrite of the engine, or that everything is all peachy in UE4 land (even now, after 2 years, people seem to still wait on important features that should have been in UE4 from the start)... just saying that in general, UE4 IS using less outdated junk.