I’ve been working with the unity system/learning for about almost a year now. When I first started I was told “make small games and complete them.” I have done a few basic “dumb” games for practice (stuff with no originally but helps understand programming).
I really want to work on my next project which is much larger 3-d game, but don’t know how to divide out the work. It’s larger but I just am thinking can I really do this by myself? I shouldn’t go into a project thinking like that but that’s what been going through my head.
So my question is ,for the some of you that went from making simple games into your first “bigger project,” something like is a full adventure start to end game (not a “quick” game that the game can be played in a few minutes but repeats with different levels over, not that there’s anything wrong with it), what were your first steps and did you do it by yourself?
I’ve been trying to learn maya now as well as unity, animation, and level design…I’m getting about a C- at best.
I’m signing as I’m writing this because I know I sound like I’m looking for the easy answer/way out but I just feel kind of lost and feel I can’t jungle all of the balls(positions) needed. I’m basically airing out my thoughts.
Thanks for reading and sorry if I sound like a fool,
Patrick
Modular design is important. Just because you are the only developer on the project doesn’t mean you should take shortcuts here. Pretend other people are going to be using your classes. (By the time you go spend a couple of weeks on artwork your code might as well have been written by a stranger.) Keep as much private as possible. Don’t change your public API. Make your classes complete.
Ideally you should not need to think about any of the details of any classes you are not working on. The public API should make it obvious what you can call, why you can call it, and what it does. Trying to understand the entire code base at once is a recipe for insanity.
I think you’re still skipping a step. You’re jumping from small to large, and skilling small-ish, medium, and medium-large.
You’ve found that making a game with 1 level is easy. Now make a game with 2 levels. You can even use the same game, probably! Just make a scene change.
Then make a game with 5 levels. Again, can probably be the same game.
Then add in menus, and level selection, and other things, 1 piece at a time.
At any point, you can start on a new game and start from scratch or work on the old game, as befits the situation.
Once you’ve figured out how to do each individual step, fitting it all into a huge project is a lot easier to understand. In fact, I’d say that until you’ve done each small step, it’s practically impossible to understand how it all fits together.
Here’s a different perspective: Start your large game. (Large, not huge. You’re not going to make Assassins Creed by yourself.) Do your best to make it modular, for example by making separate test scenes for each key piece of technology (moving around, interacting with objects, switching levels, etc.) Use stand-in assets; don’t create content (models, text, etc.) until your tech is mostly done. Keep notes.
At some point, you’ll realize it’s a disaster. That’s okay! Drop the project. It may sound counterproductive, but there are some insights you can only gain after tackling a big project. Hold onto your notes, code, and content. You’ll be able to salvage pieces for later projects. If you need a breather at this point, finish a tiny game. Then take your large game from the top again with all your new insights!
@TonyLi speaks the truth. The only reason I’m able to be working on my Eastern RPG now, is because of a prototype RPG that laid most of the groundwork that I realized was a terrible idea. That said, I’d put effort into designing cohesive, uncoupled code, and I kept my code! That’s saved me months of time on framework development - or, $100 towards buying, and subsequently weeks of time on customizing ORK.
And you’re missing an answer to your poll: “No.” It’s never foolish to have a bad idea/bad concept/bad game so long as you learn from it. Fools fail to learn.
if you’re trying larger / more complex for the first time, it’s probably a good idea to pop out to the asset store and pick up a framework or a complete project to build off of. Project complexity scales exponentially, not linearly. A good framework or even a complete(ish) project will get you started on a whole bunch of fronts.
@juicebox_boy_1 - Good that you have taken time to practice and get comfortable with code thumbs up
To split a project into tasks and order them based on their dependencies is always a hassle… it gets easier with time… why not look at it as many small / medium projects that build on top of each other? Get one thing working, test and have fun with it until you get satisfied… then make a backup of the project and start working on adding another puzzle piece. You can always fall back to your backup if you make big mistakes.
Have you done 3D characters in Unity before? If not, maybe start with picking up a free character model from the asset store. get it hooked up with some free animations and get familiar with that… I would personally just throw in a big surface with collision in the scene to have something to move the character on. You will at least know that the character and animations are working if something goes wrong which mean that it is your code or mecanim etc… that isn’t.
Then tweak controls and related values until you are satisfied…
A next step could maybe be to just switch the free model for one of your own and see to that you get this working… You now got a reliable character setup so that should be working… so if things go wrong… then it is probably your character that is messed up.
Then maybe continue after that with switching out the animations with your own (if you have too) and make sure that they work. You could also make some missing animations if you can keep the existing ones and just try to add them…
Maybe adding a basic test level after that… followed by some basic game logic… basic enemies or obstacles…
Take it one piece at the time… if you aren’t familar with something… use google and YouTube to check some tutorials for how they did it first and then make your own attempt.
1. Have a plan
Don’t just open up Unity and create your game. Don’t ‘create by coincidence’. Plan your game, then plan some more. Furthermore, plans do not exist in your mind. They’re available as document or they don’t exist.
The ultimate goal would be that you write a document that explains all features so good, that someone else could implement them.
Of course you don’t need to put that much effort into your documents, if you’re working alone. However, the message is still the same: Write shit down.
2. Split the workload in a good way
If you’re tackling the development of your game as one huge task, it’s easy to loose the drive that you need in order to complete it. The thing is that the only thing you’ll see, is what you haven’t done yet. You’re just asking yourself to get burned out in the long run.
If you’re able to divide your games in individual parts, you also have some confirmation that your programming style isn’t completely shit. Orthogonality or modularity is an important factor by which you measure the quality of software systems.
3. Don’t overestimate yourself
Starting each project with: “I’m gonna make an MMO! This time it’ll work for sure!”
Be realistic about what you can expect yourself to accomplish.
4. Don’t underestimate yourself
Starting each project with: “The cool stuff is too hard for me, I’ll just stick to small mobile games despite not being really interested in them at all.”
Eventually you’ll need to take the risk, for as we all know “Life begins at the end of your comfort zone.”
5. Ask yourself whether you really want it
5. Understand that there’s no silver bullet
I tell you that game development is hard, no matter what some want you to believe; No matter how much our tools have advanced. There is no secret tip to being a game developer. The only tip is that it needs hard work, determination, patience and a good amount of endurance. But that’s hardly a secret.
To me, game development doesn’t mean creating ‘a game’. I refuse to call all those people who flood Steam and the app stores with cheap-ass Unity games ‘developers’.
If you feel like gamedev is too hard for you, either man up or stop wasting your time. If you don’t want to put in the work, you’re wrong here.
The kind of questions I often see people post (especially on the scripting forum)…Jesus Christ. I still find myself answering those threads, as I do right now - I mean, what were you expecting? Someone to tell you a secret that magically made everything go your way? - and I don’t necessarily do it for the ones asking the question. The amount of people reading threads is far, far, faaaaar larger than the amount of people who participate.
If someone asks a very basic programming question and I answer, I do so for two reasons:
The person gets an answer
People who are actually willing to learn, may find it while doing the research the OP clearly couldn’t be asked to do
Thanks again guys, I’m saving this page for later use.
At the end of the day I have my 30+ pages of project, but going to try and “one at a time” build things that can not only be used for the game but future games as well to save time.
BUT before even that I feel I’m going to practice on a one level medium game, 5 level medium game, and so on until I feel the coding skills, as well as others are there. As well as figuring out the best way to handle a menu screen, or a certain enemy animation, or certain character actions, or anything.
I will try to take this as a 1000 piece puzzle and instead of slamming all the pieces together at once, try to look at them one at a time.
Sure I’ll probably throw out 90% of the idea if not all of it by the time I re-read it
It really is a breath of fresh air for me to hear this, I want you guys to know it means alot and that I want.
I know this forum gets alot of this and even more people searching for the “golden answer” but eventually, EVENTUALLY, I’ll get to the point where this game will be made, even if I have to pass a thousand tiny goals before I can even start on it.
I’ll update eventually on what I came up with,
Patrick Bowers
This is how I got started. In my opinion, the old ‘Start with pong’ is counter productive, it takes away alot of the energy you have to start off, Instead, I say just try making your big idea. Try, and then fail. Because with all the tutorials you’d have to watch and skills you’ll have to learn, you need to have the energy,
First - you don’t sound like a fool, you sound like someone who wants to learn. That’s different from, “I W4NT 2 MAEK SORD ARTZ ONLINE B4 POKEMON COMES ON!”
So, you’ve created some smaller games, and proven you can make something. You know by now how to write code, make art, and make or find sounds. You know how to get something out for people to play.
I was in the same boat as you when I created The Hero’s Journey. It was a “cut-down” adventure game based on Zelda 2 for the NES, that took me 10 months. I had created a basic starfighter sim (SHMUP: Orbital Combat) and a cut-down RTS (Zombies vs. Knights). ZvK had given me insight into a then-nice UI system that I was able to abuse with wild abandon. First point: what useful bits of code have your previous projects given you?
I had a concept of what I wanted to make. I watched LPs of it (H.C. Bailly and Dario8676 were great resources.) Someone linked me a dissection of the game, specifically everything wrong with it. In short, I looked at what I wanted to make, and did my darnedest to understand what made it work and what made it break.
Next, the construction. I started with a prototype level that had the basics of everything in the game - almost a vertical thin-slice of the game, if you will. That’s where you should start construction. Create a test scene for as many features as you can. Don’t worry about content. Don’t worry about graphics; you can polish later. Create a test scene and first prove to yourself that you can make the core components of the game. Second point: Playground scene to build the basics of your game.
From there, expand outward, and create a little content. For my current project, my public thin-slice consisted of a town with a single “side-quest”, a world map, and a dungeon with random battles, because pretty much that’s what an Eastern RPG is made up of. Since then, I’ve expanded outward a little bit (I lost time revising my UI to Unity UI over the past two weeks, and stomping bugs). I shared it on the Game Design Weekly WIP thread to get some useful feedback I’m acting on. Third point: make a little content for a publicly available thin-slice. Show it off and get critique on it.
A larger project like an action game or JRPG is going to require an iterative approach. Don’t think of it as, “I’m going to tackle the whole game before pokemon comes on this evening!” Think of it as, “In the next two weeks, I am going to _______”. Every so often, show your work and invite critiques.
TL;DR - You’ve learned to make something by making small dumb games. To make a larger project, you will now need to add discipline and planning to the list of skills you’ve picked up. It’s not as bad as it seems, though, because you can already make something. It won’t be easy - it will suck, trust me - but it’s doable. People - like me, among many, many others - do it daily.
Where are your games posted? I suspect you already know the “hard hatting honest advice.” Perhaps, your brain is having an argument.
The impatient brain wants to skip over the next 10 steps - it posted this thread looking to confirm that’s okay.
The wise part of your mind suspects you’re not ready - it posted this thread looking for guidance.
Everyone’s path is different, so there is no ‘right’ answer. I propose the next logical step is for you to FINISH a small game and publish it on a real platform (Android, iOS, web, steam, kongregate). As an example, consider Block 64 (see sig) - that’s 16 days of work, in my spare time.
I’m new to the game development scene, but designing levels for LittleBigPlanet back in my days as a young lad taught me a few lessons that I still need to remind myself of:
As TheSniperFan noted, you need to do work. 2 hours every other month isn’t doing work. This is where I fail the most.
Your most beloved finished project, might not have been one you ever intended to make. My most successful, and largest, level in LBP2
[Played here by a helpful, screen capture equipped forum goer: https://www.youtube.com/watch?v=miMYSxxUT-E
Kind of just… Took shape. I essentially put the clay on the table, messed with it until it started to look like something, then took that first shape I saw and solidified it into that. It was a mess. I moved on to make other things. Then, when the tools got better and my skills were more refined, I revisited the level. I broke it apart and reworked it until it was something new and improved (though, still not great) but still within the restraints of that previous image, giving me a limit to work within.
Tools are hard to use. The first few weeks with something, the first few projects, will be painful as you try and wrap your head around the correct way to use the tools you have. You will be driving screws with hammers and cutting boards with a pocket knife. It’s frustrating, but you need to pull through that phase. Once you can use the correct tools subconsciously, all that work will go much more smoothly and will be more satisfying.
It’s still work though. So join me, as I also attempt to break out of my own lack of drive, into the realm of infinite impossibility. I did it once, and I wish to go back.
Here’s a bit of a different take. Try aiming to write a ‘starter kit’ for the game you are making, with the aim of organising, labelling and clarifying things in such a way that new users of Unity would be able to take the project and make something of it. Make one core scene, comment all of your coding, public tweaking variables, everything as flexible as possible, and most importantly of all, use programmer art until you have a functioning product.
You can model for fun in the meantime, just get lots of practice making lots of random stuff you feel like making. And when you game is functioning, if you are good enough/are still interested, you can work on the art yourself, or hire artists to get it done for you. If you lose interest, you’re likely a much better game developer than when you started, and you have something you can probably make some money from on the asset store.
The worst thing I ever did was open Blender when I had a great game idea. Avoid this at all costs. I started coding a space combat starter kit a few weeks ago and now that so much functionality is present, I might end up just throwing in my own assets to make a game of it and the best thing is that it isn’t a mess like all my other projects.
I think you can’t truly understand why you shouldn’t make a AAA game until you try and make one, is AAA artwork that difficult? No not really, is general coding and shaders that difficult? Mmm nah not really.
The biggest two challenges are time and balance, because have you got a month to spend tweaking rock placement? Have you got months to meticulously go through cut scenes and make sure every animation matches exactly, all lighting and post effects match at the correct angles at the correct seconds? Can you make something look pretty, yet still make it performant?
You may have a scene with 100’s of meshes in it, that takes 10 seconds to walk through. So point being, we all have access to the same texture libraries / tech and engines as the mammoth games makers do. But as time is a constraint we’ll have to balance quantity, not quality.
Realistically speaking,
There is a few questions you should ask yourself after having a grand idea,
the most important one is,
How many years you are willing to put into it.
The technical difficulties, being if you are able to actually do it,
is not that important, because as most things, you can pick it up as you go along.
What is important however,
is the what personal bar you set for the quality.
And this is really hard to do, because once you get better at things, your own standard are also increasing exponentially.
And what once took an evening of work, now takes weeks or months to reach your own lowest standard.
So, in my opinion,
you have three options to pick from.
Set a timeframe for completion, be strict about it, and throw your personal standards out of the window.
Keep your standard, and accept depression and tedious task as your everyday life for a few years.
Strip down the project to the a minimum requirement to have a working program and put everything else on a wishlist. (And by minimum, I mean absolutely minimum, which means no story to speak of, one level, one enemy, one npc etc etc).
At least if you are able to complete that, you have a proof of concept, and are able to make educated guesses on how much time you should expect to spend on the “wishlist”.
Totally agree! One of my (many) problems is I will get caught up in the specific story of a game I am working on and then a quarter of the way through I’ll decide, you know what I don’t want this to be scifi I want it to be fantasy, etc. and spend a lot of time rethinking assets as opposed to working on the game framework which really doesn’t care whether you use a space marine or elf.
I totally agree and think this is the best reason to design the development process such that at any stage, if it simply becomes too difficult, you can simply dial back the ‘wow’ quality of your work easily. For this reason I think that the order of progress should be:
Game mechanics (one test scene) with programmer art;
Design story/scenes/levels still with programmer art (your story will have to be good to survive this! :))
Asset creation and iteration.
The great thing is that after step 2, most of your grunt work might be finished if you are hiring for the art, and you can fully test assets inside the game as soon as they are available to see if they mesh well. And regarding what @tiggus mentioned, you can probably make pretty drastic changes to your background/story after step 2 without losing a whole lot of work.
Coding your mechanics before creating assets is probably the more logical way to do things but I have always done them together. In fact I usually have a few art assets created before I write a single line of code. For me this process helps to keep me excited and motivated. I like to be able to see my game coming together and for me that means having it look nice. That is just my personal preference and definitely not the conventional wisdom.
and the best thing is that it isn’t a mess like all my other projects.