Just looking for some small advice.

So, i am pretty new to unity but i know the basics and all that but i dont know Csharp very well (only like 40% of it). I started many projects but i never finished any of them. I want to start a new project, i want o make a DayZ styled survival game. But i dont have the skills to make everything from scratch so i was thinking about buying some asset package and adding my own stuff to that. But im not sure which one i should choose:
1. UnitZ (https://www.assetstore.unity3d.com/en/#!/content/26912
2. Realistic FPS Prefab (https://www.assetstore.unity3d.com/en/#!/content/7739)
3. UFPS: Ultimate FPS (https://www.assetstore.unity3d.com/en/#!/content/2943)

I was thinking mostly about that Realistic FPS Prefab but then i would need to do all that inventory and multiplayer stuff which already is included in UnitZ. But on the other side, the UnitZ costs more, doesnt have such good animations and movement and doesnt seem that smooth at all (maybe its only me). Any advice is appreciated. Thanks.

 

Hi,

You should really see this first,
http://unity3d.com/learn/tutorials/modules/beginner/your-first-game

It really helps

 

If you want to finish anything, start with a simpler project. Buying assets will give you a small boost, but it won't make the game for you.

 

If you want to know why you cannot decide between packages, your answer is right there. Until you have completed some smaller projects and have some experience under your belt, you're not going to be able to make an informed decision because you simply do not know what questions to ask or what you need.

I know that sounds harsh, but I am trying to save you from wasting money by buying package A and then realizing you needed package B instead.

At least work through all of the tutorials in Unity's Learn section first. You will end up creating several small projects there, which will help you understand better what questions to ask when looking at an Asset Store package to buy.

Then, I'd recommend doing a few smaller games with timelines of a month or two. In each one, try to work on a small piece of the bigger picture you are working on. It can help you learn without getting overwhelmed.

For example, create a simple third person game where the player runs around with a gun shooting zombies. This will teach you about player movement, enemy navigation, and game state management. Forget inventory or fancy powers or hunger and fishing add-ons. Just do the minimum viable project. Release it into the wild and move on to your next game, which might be heavily GUI based so you can learn more about that. Rinse and repeat.

 

Yeah, a Day Z style game is a pretty big project. I always recommend small projects to start out with, for a variety of reasons I shan't repeat for the bazillionth time.

 

If you've got the skills and team and budget to try do day z just buy all the assets and figure out which one you like best.

 

My opinion and subsequent advice to new comers is don't buy code assets for your game right out of the gates. Try to write the stuff yourself. You'll learn soooo much more along the way.

Some of the assets are amazing, and for sure worth it if you are rapidly trying to build a game. It's just that if you don't have the proper understanding of C# or Unity you'll still have a hard time customizing and integrating the assets in your own projects so it ends up still frustrating you while slowing your learning process.

There are many FPS tutorials out there that you could start with. There are GUI tutorials that will help with an inventory system. Might even be an inventory tutorial somewhere out there. Use each feature as a rabbit hole to learning development and Unity.

good luck

 

The answer is here.

Gigi

 

Well, i watched totally like 20 tutorial videos and made 2 games that are like 80% finished, but then i just lost interest in them. :/

 

No offense but what makes this time different?
80% then walk away.

 

It's a cliche for a reason: that remaining 20% takes 80% of the work. It's easy to dismiss until you've spent the hard work to push through it a few times. You might consider FINISHING a few trivial projects (examples in my sig).

Gigi

 

Even though I, too, haven't finished a project yet, I agree with all the posts here. If you lose interest in a small game before completing it, you'll definitely lose interest when you're on hour 4000 of debugging one system after updating another totally broke it, which is the kind of thing you run into on larger games.

There's no substitute for real experience.

 

This is so true it bares repeating.

I starting with an open-world multi-user game and spent $100s on terrain assets and 3rd party programs in the hope that they could make up for my lack of knowledge.

In reality I had no clue what I needed and my lack of experience meant that I couldn't really even use the tools that I bought. My guess is that when I go back to my original idea I'll find that most of what I bought was wasted money.

My advice is the same that you read all over the forums from the experienced users. Pick a simple idea and deliver a game 100%. The 1st 80% of a game is always the easy part and the finishing 20% can be very tough.

 

I never really thought about it, but I bet this is why AAA games can be bad, too. During the first 80% of development, you can forgive a game's shortcomings and tell yourself it's because that feature isn't complete yet, or you'll be able to sort it out later. But then the deadline is approaching, and you still haven't thought through those features or made them fun yet, and now you're releasing a bad game.

 

Yeah, this. One of my mentors once told me that tasks shouldn't be considered to have progress. They're finished or they're not. An 80% done project isn't finished. And, as gigi points out, that last so-called 20% will probably take longer than the so-called 80% you've already done. We tend to measure progress by how done something looks, not by how much work is remaining... which is really hard to gague anyway.

For what it's worth, my approach to the hard so-called 20% at the end is to do it spread out over my whole project where I reasonably can. I don't move on from one thing to the next when it becomes functional, I stick around until it's polished. Getting started on the next thing, where I'll get a big jump in apparent functionality, becomes the reward for slogging through getting all of the loose ends of the current thing tied up.

And, I think it overall speeds me up, because there's less back-tracking (and resultant re-factoring) later on, and the workflow suits my personal motivation flow better - small bits of grunt work followed by chunks of quick-gratification work, as opposed to this growing dreadful slog of delayed polish that you're otherwise preparing for yourself.

Plus, at every stage whatever you've got already looks solid, which is motivational in and of itself. If you don't polish as you go you spend most of your time looking at a dodgy/shaky/boring/rough looking thing and thinking "ugh, will this ever shape up?" Where if you polish as you go, everything that's "done" already looks rad (even if it isn't final) and feels solid to work with.

 

I try to take a different approach. As soon as I loose interest in something it ships. 80% done or 110% done. Has lead to some substandard products. But it has meant things getting out the door rather then languishing on my hard drive for ever.

 

Ahh, that's a subtly but importantly distinct issue, though - deciding what constitutes "done". If I'm struggling to stay motivated enough to finish something I'll definitely re-define what I think my end-point is with the intent of making it as quick to achieve as possible.

 

@angrypenguin I think adapting agile principles helps make the method @BoredMormon described plausible. If the game is playable at every state, with the last "20%" being polish, extra features, or tweaking those things you don't feel perfectly happy with, you can still ship a complete game. Big difference between that and deciding to ship your third person shooter game without an aiming system because you got bored and didn't want to finish it.

 

Sure, but it was already both plausible and compatible with what I said.

 

Yeah, I was agreeing with you. Stupid Internet... Not conveying intent properly...

 

Haha, don't worry, my post which BoredMormon replied to wasn't as clear as it could have been either. We can't all be perfect all the time.

 

To follow up on this with specific personal experience: I know for a fact that I have spent money on things I ultimately did not need and things I will never use. Early on, I bought stuff before I had the experience with Unity to really understand what I needed or what I was buying, and so I basically wasted my money.

I can accept it because I am a hobbyist when it comes to game design and the money I am spending isn't out of my business budget, it's out of my "fun money" fund. It's frustrating, but no worse really than buying a video game that turned out to be no fun and which gets shelved quickly.

But @stasikgri is looking to develop a full game. If you are looking to be serious about things, you have to treat it seriously. This is why I recommend completing a number of small projects before trying for a big project.

Even if you only do something like making six small games in six months, you will learn a lot of lessons about games, programming, and Unity. Those lessons will save you far more than six months off of the possible completion date of a massive project like a DayZ clone.