Big time newbie needs advice.

I have zero experience.

Hi I really want to learn how to make a game before I die someday.

I was going to use Gameguru but its not able to make the kind of game I want at the moment.

I was wondering if Unity can make a game like Elite Dangerous,3030 Deathwar and EV Nova. Not sure if Unity could make something like Star Citizen.

The kind of game I would like to make is a space game with Trading,Exploring,Building,Mining,Research and combat. I would love to have a galaxy as large as Elite Dangerous or Similar.

Don't want to do MMO like Elite Dangerous or EvE just single player with maybe multi later on.

So what would I need to learn,what tools would I need for galaxy creation something like procedural.

Just so ya know I want to make something I can sell to earn some cash.

Thank you in advance for the help.

 

Everything is possible but it all depends on your skills. You can see the showcase section on what kind of stuff there has been done.

 

Curious are there any tutorials on how to create a playable universe etc?

I have been looking over the tutorials about other stuff and most of them are for lower versions of Unity. Any tutorials for Unity 5 yet?

 

Playable universe is a massive thing and usually you don't find game specific tutorial unless they are very common and popular. You need to learn basics and other than which you can then adapt to your game. Old tutorials work mainly too but there are small differences.

 

Learn to code first. Start small and grow big. Make a game which only has one mechanic, polish it a bit and publish it for a feedback. Then make a bigger game, then bigger then repeat.
Takes a lot of time but the outcome is usually positive.

 

Start small. Make a really simple game or two so you can get to know how coding and scripting work inside unity. Once you get the hang of it, make small parts of your game, such as a prototype for the trading system you would have. Then make a prototype of the combat system and exploration. In the end combine them all into the game you want to make.

 

I agree with what others have said about starting small. Build a few very simple games, like a pong clone. Then build a few games that are slightly more complicated. Don't try to build a game like Star Citizen until you have some experience building games. Get extremely comfortable with programming before trying to make a massive, complex game.

As to the question about whether Unity could be used to build something like Star Citizen, I do think Unity 5 could do it. It would require experienced developers with significant resources, though.

 

I personally don't like the "start small" advice everyone gives. I think its the right advice, but wrongly applied. People want to work on their great game idea, not recreate pong or download a tutorial and build it. "You don't have the ability to create your idea, start by making pong!" is terrible advice.

My advice is to break your project down into its simplest form. You want to make a universe game, so this might look like (greatly simplified):

1) Generating placement of procedural planets
2) Spaceship flight/combat control
3) Factions
4) Inventory
5) Character skill trees

Now, pick one of these and tackle it. The procedural placement would probably be very hard with little payoff so you might want to wait on that. 3, 4, and 5 make little sense without #2 so you should start with #2. Download a free spaceship model and start learning how to make it fly around (plenty of tutorials on that). This will get you one step towards finishing your game, and you'll learn most of the basics of unity/c# while coding it and reading tutorials. Then you can start researching procedural generation and start working on that.

I think making a spaceship fly around is way more fulfilling than stinking pong, and it will demonstrate most of the same concepts, while advancing the actual game that the OP wants to create. Once you have a spaceship flying around, you can learn to add lasers. Once you have lasers, you can work on enemy ai. By the time you have enemy ai down you can basically release a game that allows a user to fly a spaceship against enemy spaceships. Then you can work on advanced concepts like different types of weapons/damage/shields/components etc, but its critically important to work on one thing at a time. Just worry about getting the ship to fly.

Now, understand that the previous paragraph probably represents several months of learning and work. If you're lucky, in 6 months you'll have a ship flying around shooting lasers at another ship. If you're really lucky then the ship you're shooting at will shoot back. In a year you'll probably be at the end of that paragraph. People often say to start by making pong because you'll actually finish something (maybe), but I disagree. Its like telling someone with no home improvement experience to go out back and dig a hole before they try to change their faucet because digging holes is easy and you'll actually finish digging the hole. You don't need a hole, you need a new faucet so go figure out which retainer nut to take off first and pull out the sawzall if you need it.

ALL programming boils down to simplifying your ideas, breaking them into pieces, and working on them in their most simple form. If you try to "write an mmo" then you'll probably get overwhelmed by everything, but if you know all the pieces you need and work on them one at a time then things get a lot more simple.

 

Those are nice, ambitious goals. And, if you have zero experience, you might start by reading this, and this, and this.
Gigi

 

It's a fair criticism. There's strength in the approach of working toward an ambitious project by breaking it into small chunks, learning as you go. And that approach requires a lot of discipline, which statistically speaking, few of the newbies have when they start. The Dunning-Kruger prevents newbies from realizing how hard their idea is (often hundreds of man-years!). It also prevents them from realizing that their idea is probably not that great. The end result is that most of them burn out shortly thereafter, and we never hear from them again.

The start-small advice is an attempt to guide the largest number of newbies toward a path of success. It's based on the research of Deliberate Practice, which is deliberating practicing tasks that are ALMOST beyond your ability. It's how novices became experts, and experts become masters.

Gigi

 

In some ways I agree and I'm an advocate of think big, but even then it's relative. You're never going to be able to make the next RPG mega epic unless you have pockets deeper than 50 merchant bankers. Plus there's a fine line between "big" and you'll be sat there 10 years later with nothing more than a prototype.

But it doesn't mean you can't make something just as good as a AAA game on a much smaller scale. It's about effectively using your time, setting deadlines and keeping within the confines of the tools you have.

When you start making bolt on systems, trying to push the boat out then it's nothing more than a recipe for disaster. This is coming from experience, you can sink years into things you really should of spent $50.00 on and bought or just left the hell alone.

If said asset store producer took six months to build a tool / system, that's six months you don't have. Games are hard and quantity over quality never does any good..

P.S this is assuming you've had the years of trial by fire to understand what you're doing in the first place.

 

If somebody has no experience building a large game, then they need to start small and build a bunch of small games to quickly get experience. Nobody is advocating doing a Pong clone instead of your dream game, but it is smart to build a Pong clone (and several other small games) before doing your dream game.

The problem with working on your dream game first is that a person with zero experience does not have the skills yet to break down the huge, complex task into a bunch of small easy to manage tasks. That skill is literally required in order to build a massive dream game. By starting with several small games (like Pong clones), people with no experience can gain very useful experience. Then those people can apply that experience to larger projects.

 

@ShilohGames, @ShadowK, @Gigiwoo: I agree in principal, but leaning to break down tasks, how to budget time/money, and learning how hard it is is all part of the process. If the advice we gave noobs was to break down their game idea into its smallest parts, then they'd realize up front how much work they have to actually do. Then, by working on a small chunk they'll learn exactly how long it takes to do even the smallest part of their game.

My other point is that people only really want to do what they want to do. If they don't want to make pong, then they're probably not going to sit there and make pong, or they're going to get bored with it and lose their way, and eventually give up. I never programmed pong. I programmed a breakout clone in VB back in like 1996, but that is because I had to for a school project.

I personally would rather work for 10 years (and never finish) the game I want to build, than spend 10 minutes working on a stinking pong (or flappy bird, or tetris, or canadian bacon) clone. Wanting to do it makes you try a just a little harder, and look forward to it just a little more.

 

@delinx3
I know where you're coming from, I've aimed too high countless times. Never listened to the start small advice. Even now I have a lot in my plate with just a platformer, but I don't plan to start doing small games any time soon, not learning my lesson here... I'm too stubborn, or maybe I'm just not the sharpest tool in the shed, lol.

But regardless of that, I'm eventually starting to prefer the idea of finishing things over being a perfectionist. Maybe it's a growing process.
The ideal of working on a game for 10 years, a true mark of a perfectionist, to make the best game you can make, and make it now before anything... does it give you enough sense of achievement to fuel you from one goal to another?

You may break it down in tasks, but is accomplishing 3% after working for 3 months, enough thrill to keep you motivated? Where's the sense of accomplishment to fuel you when you feel you "never finish" as you've said yourself... AND without any previous accomplishment on your mental portfolio to keep your morale high.

It all comes down to how you feel, motivation is a tricky business, and sometimes it's about picking your battles.

 

Fair point. I've actually shifted my focus to trying to break down pieces of my project into parts that I feel that I can sell in the asset store. So I have a bunch of code that I've written over the last year or so and now I'm refactoring a few pieces to make them more standalone. I'm hoping that finishing pieces and publishing them on the asset store will give me the sense of accomplishment that you refer to, and maybe make some money too. I lost interest in ever finishing my game because the market is so stinking flooded, and I don't think that I as a one man team can put out a product that can compete with some of the indie stuff that's out there. I do believe that I can write some damn good tools along the way though.

 

My advice to start would be to just do it, you'll fail, but you'll learn a lot in the process.
'But how do I make ...'
Google it
'I cant find anything'
Break down what you want to do, google them

 

I can relate to that. I was thinking about it this past weekend. Wondering why do I not have the desire to put time in on this like I used to? I could put in an extra 10 hours per week if I had the same passion I had up til a year or two ago.

The answer is because it has definitely lost some appeal now that "everybody" is making games. It used to be cool and different and now it is just commonplace and basically being just another of the drones. LOL Also I am tired of all of the obsession with money now. Where it (not here just in general) was a community of people who just wanted to make cool games and sometimes we just shared them among our developer community or released for free (completely no ads... nothing).

Now it seems like the masses brought with them an obsession with making money. Always asking which ad networks to use, how to do IAP and on and on. I think another factor is I have been reasonably successful in my life by not only working hard and smart but also because I nearly always do the opposite of what the masses are doing. These days the masses are making games which I think in the back of my mind tells me there is little purpose to this anymore. On the other hand I have been doing this stuff for a long time now and I still see niche holes that are not being filled. And I still find enjoyment in it. Maybe I just need to spend less time reading the forums kind of putting blinders on. LOL

 

For new guys that have zero experience, there is really 2 options. Start small and build on your success or start the game you want to make, and learn what you need to make it. The smart small approach is usually best, as most people have no idea how frustrating and time consuming game making really is. There will be times where you spend 2 days on making a wall look "just right" or a week on programing an AI that you have to scrap. Thus most everyone who picks up unity never finishes a game.

The real question i have to ask is the game you want to make before you die a specific game, or do you just want to be able to make one game? If you have a flushed out idea (and i mean you can visualize most of the game, how it looks, how it plays) then i would say go ahead and build it. Realize that your looking at a year of just learning how things work. Thats not to say that while your learning tutorials and playing around in the editor, you will not make stuff for your game. It just means that your not going to build a useable level in a week, or make an AI in a month.

That being said, what i did, and have had a lot of success with, was a suggestion from extra credit (a youtube show about game making). Find the absolute bare min you need to play your game. If it's a mario, then mario, the ability to jump, a few blocks, a simple enemy and perhaps a pit. I am working on a fantasy fps. I have a projectile weapon, a spell, a sword, and enemy on a platform with a block in the middle. This has allowed me to now have multiple weapons and spells, a flushed out castle level, and am about to start work on the enemy AI.

Also is this a personal project, or is this a career path? If your just looking to make a finished game, their are a ton of assets on the asset store that will help you, and if you are smart about it, you can shortcut some big time consuming area's. I would look for something that has great reviews, is currently being supported, and is either the main gameplay factor (FPS engine like UFPS, RTS engine for RTS, etc), and AI (rain is good if you want to program it yourself, shooter AI is good for FPS's from what i have heard) and Probuilder 2 bundle. The probuilder 2 thing i would say is almost essential. However if your going to build a real game, not a clone of everyone else's highschool unity project, then you will need to learn some modeling, coding, graphics, etc.

Another word of advice: Try EVERYTHING your self. Your not suppose to mix textures and normal maps made from other textures, do it. Understand why people say your not suppose to, so you can do it anyways when the situation is right. At the end of the day, you just want the game to work, with as few bugs as possibile, on as many pc's as possibile.

Hope this helps

 

@GarBenjamin - I responded over here.

Gigi

 

There's a difference between "terrible advice" and "advice people don't want to hear". There's also a difference between telling someone not to do something and telling them a better way to go about doing it.

Telling someone "do some small stuff first" isn't saying "don't do big stuff". It's saying they should work their way up to it, and telling them how to get started at that.

You don't learn guitar by walking into a band's practice session and asking to join in on the small parts. You learn it by picking up a guitar and learning the most fundamental basics, and working up slowly from there. Same deal with game development.

Plus, I think it's alright for people to decide that they're not actually interested in game dev after trying it out. People aren't obligated to follow through with an initial game development desire just because they asked a bunch of questions and dipped their toes in the water. I've had a go at plenty of things I never carried on with. People can do that here, too - it's cool.

Also, an inconvenient truth here, if their interests are more to do with a specific game than with game development in general I think likelihood is that they're going to decide it's not the hobby they're after sooner or later anyway. Game development is about design and technical skill and problem solving, it's really not about "I thought Halo was rad and wanted to make my own" (though that could certainly grow into a passion for game dev in its own right... in which case I think the advice leading down that path is still the right advice).

 

My advice to start would be to just do it. Failing is progressing. Each failure is a brilliant discovery in how not to approach what you do in that way again.

 

You don't start by painting the Mona Lisa or Sistine Ceiling. You start by learning much easier things, on much easier media. Nobody *wants* to start with stick figures, it's just the best you can do at the time. As you practice, you get better and can do more complex things with more complex tools.

It's all well and good to say "do you project, but break it down" but with no experience with *any* projects, it's just not something they can do. One of the biggest questions I see is, "Where do I start?" When your project is so big and your experience so small that you can't see that, it means the project is too big for you.

Yes, I know it sucks to start with things you don't have a passion for. Learners need to channel that passion into doing whatever is necessary to learn what they need to work on their real project.

I've recently just gone through this myself, actually. I'm a senior-level non-game software developer. I'm used to just whipping out code and getting things done, but in a game engine I'm rather lost. I spent time and learned Unity by just doing my projects (for Ludum Dare, etc) and fighting through the pain of learning it on my "big" projects. (Which weren't even that big, really, since they were 2-day things.)

But then I tried to switch to UE4. It's just different enough that it was painful to get started again, and I put it off a lot. Finally, I decided on a small clone project, Simon. Instead of starting from scratch, though, I opened up their 'puzzle' starter code and modified it. It went very well. It's the fastest I've learned anything IT-wise. I now feel pretty confident in making 2.5D puzzle games in UE4, after just a few days of playing around with it.

I'll be taking this approach in the future. Take an existing, simple project, and make a slightly less simple project... At least for my first project while learning a new system.

tl;dr - Starting small is much, much better than starting big and struggling through.

 

May I suggest getting and reading Jason Gregory's Game Engine Architecture, cover to cover?

 

Thanks for the recommendation. I'll consider it.

However, I was referring more to being lost in the interface of each particular engine, and how they do things in their own interface. I understand most of the underlying concepts, but how to go about them in each engine can be quite different. (Consequently, I fully understand the desire of many programmers to write their own engine instead. It fits them like a glove, and there's no question about how things are meant to be done.)

 

Thing is, if people work directly on their dream game before they know how to develop a game, they'll hate it when it turns out crap. That's the real point of starting with pong/tetris/breakout: so that you can get your learning out of the way on throwaway projects. If you're just starting out, your first several projects will be crap, so you don't want to ruin your dream game that way.

ADDITION:
I just wanted to emphasize this point from angrypenguin's post

Early in my career I was advised that you need to like making games more than you like playing them. I didn't believe it at the time, but looking back I see it's more or less true.

 

Yeah, I swing back and forth. I'll go through periods of playing lots where I don't really feel like making stuff, then I'll make loads of stuff without playing much.