My idea was to make an RPG using Unity, which I am basically almost out of the beginner level of skill in it's use. But I feel as though it's going to be too big to start with.

And in that case, what would be the best course of action?

This IS way too big to begin.

You would better start with games like Pong, Tic Tac Toe, Tetris, Snake Game.

Also you would better not get started by using Unity for that matter.

Since, you will not understand concepts like implementing the game loop, the texture/resource manager, physics, particle system, etc.

Game engines probably assume that you already know these things and now don't want to waste your time doing these things again and again.

For example: If you want to create a third person shooter with Unreal Engine, you can just click that option while creating a new project and you are already supplied with a ready made third person shooter. The player can walk around, jump, etc. already. Isn't this magic? What did you learn? How will it benefit you further? Similarly for Unity, you can just add a third person controller and the magic begins!

I recommend you to start with something like:

• C++ and SDL/Allegro/SFML
• Java and Java2d/Slick/lwjgl
• C# and OpenTk/SlimDX
• Python and pyGame

You might find these resources useful:

• http://www.gamedev.net/page/resources/_/technical/game-programming/your-first-step-to-game-development-starts-here-r2976
• http://www.gamefromscratch.com/post/2011/08/04/I-want-to-be-a-game-developer.aspx
• http://www.gamasutra.com/blogs/TommyRefenes/20130107/184432/How_do_I_get_started_programming_games.php

They might convince you not to start too big, also you'll get a good conceptual start.

It depends on the scope of your game idea. I dont think there's anything inherent in RPGs that make them unrealistic for beginners to make. But, you have to understand that if you're a beginner your scope should be as small as you can possibly imagine. Any game, whether RPG or whatever, is much more involved and takes more work than anyone who has never made a game realizes.

I actually learnt Unity pretty quickly, without prior knowledge of programming, I feel like it's my go to for right now, I've tried making my own engine before, and having an already made engine just makes things a bit easier to me, but thank you so much for the information, guys.

My problem is that I think way too big with any of my projects, then I just abandon them, is there ever a sure fire way of avoiding this at all?

I actually learnt Unity pretty quickly, without prior knowledge of programming, I feel like it's my go to for right now, I've tried making my own engine before, and having an already made engine just makes things a bit easier to me, but thank you so much for the information, guys.

My problem is that I think way too big with any of my projects, then I just abandon them, is there ever a sure fire way of avoiding this at all?

This is one of the major problems that face most independent developers, and many professional ones.

Your goal should be just one thing, finish a project. As such, the project needs to be of a scope that... well, that you can finish. The thing you need to consider is what exactly that scope should be. I'm sure you realize that it should not be too big, and everyone pretty much realizes that. But, what you learn from hard experience is that what you usually think is a realistic scope, is actually still way too much for you to handle in any reasonable amount of time... which normally leads to people abandoning a project.

What I'd advice is to think of it as a learning project, not as a real game that you expect anyone other than yourself to play. You're just making it to 1) learn how to make a game, 2) prove that you can finish a project, and 3) to have a codebase to use on your next, more ambitious one. Then, take all your ideas and strip them to the bare essentials. If you have like 10 character classes, drop it to 2. If you have dozens of enemy types, make just 2 types. 20 different levels? No, make 1 level. 15 unique weapon types? Make just 2. You're not trying to build a mansion, or even a house. Your're just trying to prove that you can build 4 walls and a roof, with a door in one of the walls. Only the basics should be there and you can add features later for version 2.0 if you want, after you finish this one.

Once you have your bare bones design, break it down into tasks and start working. I wouldnt even bother with a schedule because unless you have a lot of experience making games... you dont know enough to properly schedule anything. You'll learn how long it takes to get things done once you've done them. All I can say is that it will always pretty much take you much longer than you initially thought.

Good luck.

I actually learnt Unity pretty quickly, without prior knowledge of programming, I feel like it's my go to for right now, I've tried making my own engine before, and having an already made engine just makes things a bit easier to me, but thank you so much for the information, guys.

My problem is that I think way too big with any of my projects, then I just abandon them, is there ever a sure fire way of avoiding this at all?

This is one of the major problems that face most independent developers, and many professional ones.

Your goal should be just one thing, finish a project. As such, the project needs to be of a scope that... well, that you can finish. The thing you need to consider is what exactly that scope should be. I'm sure you realize that it should not be too big, and everyone pretty much realizes that. But, what you learn from hard experience is that what you usually think is a realistic scope, is actually still way too much for you to handle in any reasonable amount of time... which normally leads to people abandoning a project.

What I'd advice is to think of it as a learning project, not as a real game that you expect anyone other than yourself to play. You're just making it to 1) learn how to make a game, 2) prove that you can finish a project, and 3) to have a codebase to use on your next, more ambitious one. Then, take all your ideas and strip them to the bare essentials. If you have like 10 character classes, drop it to 2. If you have dozens of enemy types, make just 2 types. 20 different levels? No, make 1 level. 15 unique weapon types? Make just 2. You're not trying to build a mansion, or even a house. Your're just trying to prove that you can build 4 walls and a roof, with a door on one of the walls. Only the basics should be there and you can add features later for version 2.0 if you want, after you finish this one.

Once you have your bare bones design, break it down into tasks and start working. I wouldnt even bother with a schedule because unless you have a lot of experience making games... you dont know enough to properly schedule anything. You'll learn how long it takes to get things done once you've done them. All I can say is that it will always pretty much take you much longer than you initially thought.

Good luck.

More is not always better.

It's like making a large table filled with food, and you're the master chef. For simplicity, let's say you made 5 dishes. Your guests arrive, they eat and drink and have a great time, but what do you see? The 2nd dish is hardly used, and the 5th not at all!

Why? Was the food not good? Was the room too dark or too light?

When you sit down with the list of ingredients, you suddenly see. The 2nd dish could be done with the 1st and a bit of the 3rd, and the 4th and 5th are very similar, but the latter is much harder to eat.

In your game, you want all game elements to be used. Also, the elements must make sense.

The more elements you add, the harder this gets. People will try to use all elements at all places, and it must be logical that wizarding a door open cannot always be done, if your game also has keys.

In reverse, the fewer elements you have, the easier this design problem becomes. If I only have keys, I won't try magic to open the door.

Also in this game play design perspective, it makes a lot of sense to start small, and only extend when you really can't do without (which you'd play test).

More is not always better.

It's like making a large table filled with food, and you're the master chef. For simplicity, let's say you made 5 dishes. Your guests arrive, they eat and drink and have a great time, but what do you see? The 2nd dish is hardly used, and the 5th not at all!
Why? Was the food not good? Was the room too dark or too light?

When you sit down with the list of ingredients, you suddenly see. The 2nd dish could be done with the 1st and a bit of the 3rd, and the 4th and 5th are very similar, but the latter is much harder to eat.

In your game, you want all game elements to be used. Also, the elements must make sense.
The more elements you add, the harder this gets. People will try to use all elements at all places, and it must be logical that wizarding a door open cannot always be done, if your game also has keys.

In reverse, the fewer elements you have, the easier this design problem becomes. If I only have keys, I won't try magic to open the door.


Also in this game play design perspective, it makes a lot of sense to start small, and only extend when you really can't do without (which you'd play test).

This IS way too big to begin.

You would better start with games like Pong, Tic Tac Toe, Tetris, Snake Game.

Also you would better not get started by using Unity for that matter.

Since, you will not understand concepts like implementing the game loop, the texture/resource manager, physics, particle system, etc.

Game engines probably assume that you already know these things and now don't want to waste your time doing these things again and again.

For example: If you want to create a third person shooter with Unreal Engine, you can just click that option while creating a new project and you are already supplied with a ready made third person shooter. The player can walk around, jump, etc. already. Isn't this magic? What did you learn? How will it benefit you further? Similarly for Unity, you can just add a third person controller and the magic begins!

I don't really understand what is wrong with using stuff that other people made, that is basically how real world works... waste 3 weeks making it yourself, or find something that works and probably works better than coding it yourself although it might cost a buck or two and use that? Like if you use the 3rd person controller and it works then boom. Spending 2-3 weeks to get something like moving cube to work, while fighting against null pointers is more likely going to burn people and prevent them from doing anything.

And even if you use ready made scripts, you can try and test how to adjust things to figure out how stuff works. I just cannot really see why someone would rather advice beginner game developer to go use SFML over Unity.