Tips for making projects more manageable

Hey everyone,

Does anyone have some tips to make large project more manageable?

I've been working on pushing out a small Andoid/Apple game just so I can finally say I've at least published something and I noticed that despite using lots of notes and organizing it, it's still very hard to go straight to the code I want on my character controller.

I can only imagine this must be times a thousand on a proper game.

It seems like even simple things like placing enemies down would start to require lots of digging through your assets.

Also, do you find it easier to write multiple scripts to work on one object or to write one long script?

Any tips are welcome.

 

Well, multiple scripts are generally better than monolithic scripts. Each component should do just one thing, and should do it as simply as reasonably possible. You can stick as many components on something as you want, and you can reuse components on many different types of object... so why bung everything in together when you don't have to? Look up "component based architecture".

 

We work with a kind of template system here at work, where we've set up a project that has all the base pieces we'd need, then just add assets and project specific code for each new project. Any new 'base' code that gets developed over the course of a project gets merged back into the template via SVN. Our business would be impossible without it, but alongside these, we have many editor window scripts that automate the finicky processes of setting up specific content. We also have a lot of things set up automatically when imported by identifying model naming conventions.

As for organising it all, we have an internal wiki that documents all our processes and components (growing into a bit of a beast as we speak). Programs like MantisBT, TargetProcess, Trello etc are all great for managing a project, too.
We also have automated code documentation through Doxygen.

If just a one-man team, some of those may be overkill, but at the very least I recommend Version Control and Bug Tracking (we use SVN and MantisBT for those respectively). They will help you no end, I can't stress that enough.

 

I think search boxes are what you're looking for. They're small and easy to forget, but Unity has little search fields at the top of the hierarchy and project windows.

 

I've recently started delving into the NetworkView stuff and it became woefully apparent that I needed to 'bottleneck' my inputs and variables so I can easily sync stuff. As opposed to splashing variable changes all over the place making it easier to miss tossing into an RPC.

But with each project you learn so I guess that's just the nature of things.

 

I had to head off last night before I finished my post.

In addition to what I wrote, it sounds like you need to work on your up-front planning and design. It sounds like you must just plonk stuff down wherever in your project view if you have to spend significant time looking for it.

For starters, you should be able to organise your project hierarchy so that you know where stuff is intuitively. Want the 'Drone' enemy prefab? That'll be in Prefabs/Enemies/Drone. Need its source FBX? That'll be in Sources/Enemies/Drone. Main menu graphics? That might be in GUI/MainMenu/blah. So on and so forth. There are plenty of ways to skin this cat, the important thing is consistency - both in naming conventions for individual files and for the paths for them.

Next, plan up front how you'll approach your functional implementation. You don't necessarily need to work out concrete details, but at least working out idiomatic approaches, styles, etc. is key. Use consistent approaches to solving similar problems wherever possible. Also, work out as much of your architecture up front as you can. This doesn't mean work out the details of every class, but you can break up your game into its different functional areas and broadly plan how you're going to approach each. As for how to do this stuff, check out software engineering / architecture resources. I've heard plenty of game programmers scoff at such things under the guise of game programming needing to use more flexible approaches... the thing is that planning does not need to rule out flexibility. To the contrary, if flexibility is important then you should plan systems that explicitly support the flexibility you need.

 

Wow, this is a lot of great suggestions!
Thanks everyone.

I will try this in the future. I think 300+ lines of code for an extremely simple character controller is excessive. It seems like there needs to be a balance between segmenting functions of the script and having all the information needed on one script to make changes that are needed. But yeah, mine is a mess because I didn’t break it down at all.

This is very helpful. I know very little about version control and project managers. I think that you’ve given me a very good springboard to look into third party software.

I really meant this as a general and broad question. It seems to me (and correct me if I’m wrong) that projects tend to grow more complicated compounded, and what seems like an inch turns into a foot, and what seems like a foot turns into a mile.

I'm guilty of doing that.

Sadly, no. I actually spend a lot of my free time thinking about how to do a project and what order to do things in. I think that this is a matter of lack of sxperience finishing full projects, rather than messing around with whatever peaks my interest that week.

This is something that I wish I knew months ago. I was totally labeling files “scripts” and “models” and “textures” rather than grouping them with the actual object using it. Live and learn.

Like finite machines and game states?

This is helpful to get thinking about. I definitely need to get myself geared up for the next level if I’m ever going to get to where everything “clicks”.
Thank you so much everyone!

 

Do you " think about it" or write it down?

Draw it out, or write the tasks on sticky notes and put arrows between them. Same deal with your functional implementation, by the way. It's way easier to scribble in paper to change things than it is to change swathes of code after you've written them.

I go through reams of paper doing that kind of thing. You should be able to draw out the whole process of whatever you're making, and as you go you'll not only easily spot issues, but you'll even figure out solutions to them as you go.

While it's not a necessity, there's a formal visual language for doing this stuff called UML. I poke fun of it sometimes, but if you're going to do a lot of this (which you should!) then you may as well adopt an existing standard that others will understand rather than invent your own. Plus, in learning the various versions of UML you might be prompted to think about things you may otherwise not have thought of.

 

Some things I found of great help:

- Use a good directory layout. One that organizes your assets without creating annoyingly deep or big folders. There is been a thread about this: Best Practices - Folder Structure.

- Use a version control system and treat its contents as sacred: you can mess around in your local working copy as much as you want, but what gets committed to the VCS works, is tidy and usable. Also include master files in the VCS - eg. if you have a cool terrain, don't just commit the height map to VCS, also commit the World Machine project in case you want decide tweak it a few months later or need a second terrain.

- Do not depend on any initialization or scene load order in your scripts. Use a dependency injector and make sure you can hit the start button from any scene. The more difficult it is to test things, the less testing will happen - even if it's a one-man-show.

- Use a lightweight task + bug tracker. Creating a task shouldn't feel like filing a tax report. If it's any harder than clicking a TODO.txt and adding a line, go for the TODO.txt file - tools that fit the bill for me are Trello, Pivotal Tracker, Fulcrum (Pivotal Tracker clone that allows self-hosting) or Grindstone.

 

Tips? As a professional, I've managed dozens of projects, and as an Indie dev, I've released seven solo apps, that have earned 1500 reviews, and 200,000 downloads. Here's a few ideas to consider:

• Think Small - 4-12 weeks is all you need. If that's not enough time, then your project is too big. Cut 90%, and try again. The Gallup authors call this 'Bullets, then Canonballs'. The Lean authors call it 'MVP - Minimally Viable Product'. For Tap Happy (see sig), I allowed 4 weeks for core gameplay, and 8 weeks for polish. In the end, it took 13 weeks, from idea to submission to Apple.
• No Systems - 'Systems' are teh debil! OCD will drive you to 'build a better mousetrap', and your brain will tempt you, 'Oh, I could re-use this, if I just ...' and Jonathan Blow would argue that the most important thing to maximize is 'number of developer years to build a product'. Slap yourself in the face and drop the SYSTEMS.
• Functioning Software - Once you've eliminated Systems - your game now has the opportunity to get a LITTLE better each day. A new feature, a new graphic, the start of a menu, a new particle effect. It's functioning every day, and slowly, it becomes a real product.
• No Excuses - Posting to Unity. Talking to your friends. Blogging about your progress. These are ways to procrastinate. Go in your room, close the door, and BUILD.
• Try-Fail-Improve - I've saved the most important tip for last. Even though I've got 22 years professional development, 11 in games, and 3.5 as an Indie, not a single one of my products has performed as I expected. I try, I fail, and I improve. And that is how I succeed.

Lastly, I leave you with this quote from Joel Spolsky, "Finishing is a feature. A really important feature. Your product must have it."

Gigi

 

I'm assuming this means Component/Entity based design, if not then I apologise, the rest of this post is irrelevant.

This is a nice bit of advice for simple projects and mobile apps etc, but it comes into it's own in large scale games and turns into a fundamental design decision that can produce much more emergent experiences for a user, but more importantly, a more modular and simpler view of a code-base.

It can certainly cause headaches if not implemented well, don't get me wrong, but it's a design decision rather than an absolute 'don't do this'.
There are many things that can be done only with a component-orientated design. There are many examples of it being used in very successful games too.

Deus Ex(2000) - This is probably what I'd call the definition of excellent emergent design. The systems built to control the world via your different abilities combined with those that control the AI and mission objectives is something that is near impossible with scripted event based design. (don't have a specific source for this one, you can probably search and find some info fairly easily though, I'm certain it has been talked about).

Dungeon Siege(2002) - Some excellent info from one of the devs Scott Bilas here - http://scottbilas.com/games/dungeon-siege/
The component based stuff is under the section "A Data-Driven Game Object System".
I'll let the link speak for itself.

I could go on and list a load more, but really all you need to do is google component based design

In short, it's an extremely useful design method that allows more modular programming and is of particular use to Unity developers as Unity is notoriously troublesome when it comes to team-based development, breaking up games into systems makes team development much easier.
Not to mention the fact that Unity itself is a System based design!

Again, if that wasn't what you meant, Gigi, I'm sorry
I agree with everything else though, of course!

 

I recommend you study Refactoring. Like most things this is something a lot of us just did naturally for years and then someone coined an official name for it. Martin Fowler actually wrote a great book on the subject.

You should always be refactoring your code to make it easier to understand, maintain and extend. Your 300 line character controller sounds like a perfect sandbox. Just break it down and split it out. Read up on refactoring.

Of course, the more experienced you become and the more design time you spend before writing any code the less you should need to refactor.

 

I've been doing something similar, in pursuit of the same goal.

In my projects, my setup is organized into two primary groups: 'Framework', which has most of my general-purpose code, and 'Game-Specific', which has stuff focused on the game in question. For instance, my sidescrolling physics, sprite animation setup, Control Manager are in Framework. My character controller, individual game objects like Spikes, NPC dialogue files, etc. are Game-Specific.

My current project, Sara the Shieldmage is the second time I'm applying such a setup to my games. I'll let you know either through it not going anywhere, or through the post-mortem, what happens with it.

 

By system, I'm referring to when you're making progress on your game, and you have an idea like that leads to thoughts like, "I need a system for reading in data files and mapping that onto my character properties", or ... "Now that I have the basic mechanics, I just need to build a generic AI combat system..." or, "I've spent the last week laying the foundation for a data management layer for my nested character classes ..."

'System' does not refer to component-based (aka aggregate) design, which is a strength of Unity. Instead, system is a way to remember that sometimes, it's better to just write the 100 lines of code for a single one-off case and try to avoid turning a small part of your project into a generic 'system'. Systems can turn a 12 week project into a 12 month project.

Gigi

 

So true. Classic over engineering.

 

Yes and no. If it is indeed a "one off" then I agree, don't make it more complex than it has to be. But when it's done right - which includes picking the right times to do it - designing for flexibility and/or reuse will increase your productivity.

Making a simple change to your one-off 100 line kludge might mean writing a completely new 100 line kludge. Doing that once or twice is probably no big deal in the grand scheme of things (though it will make that emergent design harder to come by when experimenting with simple changes means writing 100 lines of code!). But letting that creep throughout your whole project is a completely different story...

 

I currently have a folder at work with ~100 files, several of which are GDD's, from working on my stuff during my breaks over the last several years.

I just think that I don't have the experience to make a meaningful GDD.

@Cygon4 - Thank you for the link, this is definately useful!

@Gigiwoo - Thank you, this is all very true. I am still grinding at my game and am planing on having it ready in two weeks. Also, I think I get what you mean about systems. I consider that (in my mind at least) the "Nintendo approach"; design the game around individual experiences, not a experiences around a design. Also, also, by "room" do you mean "pub"?

@GarBenjamin and Superpig- I have looked into refractoring in the past and I'm still kind of torn because I'm not always sure that less lines makes code more readable. But then again, 300+ lines isn't easy to read either.

This thread has really been an abundance of information. Thank you everyone.

 

A GDD is different to a tech spec and/or an architectural design. One is about what the game does, the other is about how you build it. A project plan is different again.

 

Everyone should remember that a GDD should only be as long as is required, all this talk of hundreds of pages makes people think they should make it that long, when really is should just be focused on making development as easy as possible, and really does anyone want to read hundreds of pages?

 

I have no idea what you have been reading, but the answer is both and neither. The point of refactoring is to reorganize code in a way that is easier to reuse and read. Incidentally, the length of the code may change as a result.

 

Seriously though, that's only one possible outcome. And, breaking things out into functions does not directly imply more code; you could take some code, break it out to its own function, reduce some of the terms of the function, and alter how its called to be more efficient. This would result in less code. Extracting functions/extracting classes/extracting code to a superclass can only be ensured to change the length of the code as a whole; they can't definitively be proven except on a case-by-case basis to extend or shorten code.

It is a subtle point, but worth making.

 

One mans successful is another ones failure, depends on how you set the bar.

Disagree with this methodology completely, think BIG and scale back when needed. Never restrict your potential until it becomes problematic, rinse and repeat mantras never encourage growth. Never compromise on quality, even if you must scale back to a small high quality project as opposed to a large poorly built one but always push forward, never side step.

Agree on everything but Try-Fail-Improve, at some point you need to stop failing or it's time to start re-evaluating where you are and what you're doing. Again one mans failure is another mans success, if games are a viable financial career then great if not there has to be a time when you use some common sense.

 

We just need to include that often the outcome is a smaller code base. Because one of the key reasons to refactor is when you find yourself writing basically the same code again (or and again and again) and you then break that code out into a little method of its own and replace all of the other instances of that code with a call to the new method. Then test like crazy to make sure you didn't break anything in the process.

 

I am not disagreeing. lol Just saying we should be sure to include that while some refactoring makes your code base bigger, other refactoring makes your code base smaller. The point of refactoring has nothing to do with making your code bigger or smaller. It is all about making it cleaner, easier to maintain & debug, easier to enhance and just "better" structured all around. Basically, I am just saying he should study refactoring because it will serve any programmer well.

 

We all concur.

On the subject of concurrency, mutexes. Thoughts?

 

I'm with Gigi on this. If I was "thinking BIG" on my current hobby project the straight up fact is that it wouldn't ever get finished, despite my skill and experience. As a full time professional I end up with the equivalent of 1 work day per week to put into my hobby stuff. So a project that would be equivalent to one man month of professional work will take close to 6 months to do as a hobby project.

Thinking big is great if you have a dedicated team of a significant size and all of the necessities that come with that - like a budget. Aside from that, I honestly believe it's best to focus rather than to expand. Of course, having said that, I'm very much a minimalist when it comes to design, so of course I think that. Being pragmatic, though, I'd rather make a thing that does one or two things really well than a sprawling mess that does many things half-baked.

 

Locks (which will mark the section as Critical) for applications running in a single process. Mutex is a tiny bit slower but you need it if the code will be accessed by applications running in multiple processes. At least that has been my view and seems to hold up in practice.

But Lordy, you are getting way beyond making projects more manageable now.

And now to get to the Works In Progress section which is the reason I logged in!

 

Hence why I say: "if you must scale back to a small high quality project".. Unless your messing around for kicks, you need to release quality projects, it takes time dedication / skill and something to cut across the rest. Thinking small all the time doesn't flex your skills neither does it encourage higher quality products.

Simple as this, want money for your work? Don't skimp!. If it takes you six months, so be it!.

Seems the point was missed, thinking BIG doesn't mean a massive MMORPG.. Look at the likes of @dogzerx2, a side scrolling platformer you could be proud of and makes an impact. He spent the time to improve, the project is taking many months more than expected. But it's worth doing!.

I don't get why common sense seems to be a miss here!. You get single developers caught up in massive openworld MMORPG's and they are still deving it seven years later, that's not ideal either and we all know that. But it doesn't mean you shouldn't try to push the envelope or spend the needed time.

 

Since when does keeping scope manageable mean skimping or failing to stretch skills? The 7 year unfinished 1 man MMO is exactly what people think of when you say things like "think BIG". The several months or a year or two project that does get finished is exactly what I'm talking about. Yes, absolutely spend the needed time. But if you're pragmatic, don't embark on something where "the needed time" is a roadblock in and of itself.

 

It was GIGI that said 4-12 weeks not me, why is an MMO the only example of think BIG and scale back here? You know there is much more to it.

The GIGI mantra is nothing to do with keeping a scope manageable, it's 4-12 week blasts followed by rinse and repeat failures until you "get it right".. Just try to do it right the first time, sure failures shouldn't put you off and you should keep learning. But there is a limit here... Take all the time your project deserves, if it does take years so be it.

On top of that we can call symantics until end of time but you know what I'm talking about whether you agree or not!.

 

Sure, but how do you know that your first time is "right"? How do you know how long anything is going to take or what the results will be if you've not no prior knowledge or experience upon which to base it? More effort does not necessarily mean a better outcome. It just means more time between opportunities to test it. It's easy for someone with experience to decide to spend years of their life on a project because you know what you're getting into. Suggesting that to someone new? Crazy!

I don't fully agree with the Gigi approaches details either, but I do agree with the principle, which is to finish things, learn from them, then apply the learning in the next thing. Keeping the individual projects short is just a strategy to maximise the number of complete projects you can achieve in a given amount of time. It's not about making trivial things. It's about making finished things so you can learn about the process as a whole.

Advising someone who literally doesn't know what they're getting into to spend years on their first project is folly. They can make a mistake in the opening phases of that project and spend literally years paying for it before they find out that they've made it. On the other hand you could spend those same years doing 10 smaller projects. Or do 3 smaller project and then start your magnum opus, and the experience that you gained is likely to save you more time than you spent and get you a better outcome.

And no, I did not know what you're talking about. All you said was "think BIG", with special emphasis on the "big" part with a capital B, I and G. To me that implies picking the biggest thing you can. Don't miscommunicate something and then tell others they're picking on semantics. An MMO is not the only example, but it's by far the most common one that comes up, and when it comes to BIG in capital letters I think it's a pretty natural starting point.

 

Because there are succesful formulas already in place, it's obvious trying an out there wackadoodle approach might have limited custom. There is a huge difference between learning and releasing.. By the point of release you should have at least a half baked clue as to what's right and wrong.

If you are charging money for a product, you'd better damn well know how long it's going to take you and know what's involved. If you're doing free games for a laugh as I said previously it doesn't really matter.

Why? It might take that long to learn! I recommend digging as deep as you possibly can then decide how "long" a project will take you. Learn first, create products later.

If you can't do basic games, you shouldn't even be thinking of putting together a complete project and releasing it. You should be hitting the UE / Unity tutorials and examples and working through how to put every piece of the puzzle together.

I'm not miscommunicating anything and the fact your now telling people what they can and can't do doesn't add anything to the communication chain. Big is dependant on many factors, a BIG project for one person isn't a BIG project for 15, now I'm playing semantics.

But I agree and have said all along, it's better to get something smaller finished than it is to dwindle away on a large project that won't give you the breadth of skill needed. Small quality projects, I KEEP SAYING if it's too much scale back.

I'm struggling to see what part of it's hard to wrap around? Just because I don't agree with GIGI, doesn't mean others don't you can debate this with me as long as you like. But it's for people to make up their own minds, these are just opinions nothing more.

 

I think we're talking about people at different experience levels, because this bit nails it, assuming that you're using the word "product" to mean the same stuff you're saying people should "think BIG" about.

(Though to follow up on that, I think there's a mile wide gap between doing tutes and starting a potentially multi-year project.)

 

I agree, it's hard to really fit any of this into a cast mould and it can only be a general opinion because it depends on project, experience, staff amount / one man band / practice / commercial / etc.

I was mainly aiming at GIGI's remarks.

"4-12 weeks is all you need. If that's not enough time, then your project is too big." That's such a wrong statement I don't even know where to begin.

With the rate of fierce competition commercially, I also don't see how restricting to short term rinse and repeat projects are going to help sales. You need to stand out and that takes time, even with it being a small project with tweaks etc. it could take a year or maybe more.

Now as a learner / beginner then everything changes, but I'm still unsure why timescales matter as long as you're learning the right things. In fact it took me around 5 years to really start getting the swing of things, sure I doubt a lot of people will get deep into API's like OpenGL but still it takes a long time.

The OP is talking about large projects, which should go through the standard project management documentation. List of tasks, assigned hours, practical approach documentation all the visio crap I have to do that gets boring.

 

Which advice is best for a newbie? If you're a professional, with a budget, and a team, then you aren't looking for newbie advice - you're researching team building, distributed development, and monetization, while trying to find publishers. If, on the other hand, you're the OP, then you asked this:

In which case, he's already massively stretched, just trying to figure out how to build ANYTHING. He needs tips that will help him finish and release, as there is so much that will teach him.

ShadowK - your advice is powerful, for senior people and organizations. And, it's also dangerous to young devs who have no idea how hard this is, how many thousands of tiny details are involved. They hear words to 'Go Big' and instead of building up a nice resume of finished products, they head into a death spiral that leads nowhere - the forums are littered with their carcasses. For young devs, these small products is a great way to gain confidence, build a wealth of experience, and walk away with a resume of past-performance to help advance their career.

Gigi

 

Hear of 'Game A Month'? Or 'Game A Week'? Or Game Jams? These are ideas, like the 12 week challenge, that aim to help young devs produce products faster, so they can grow their skills. I share my wisdom and experiences in a humble pie, to help young devs. Though, you could just as easily read the international best seller, "Great By Choice" to see that the most successful companies on the planet do the same thing. They call it, 'Bullets then Canonballs'. I call it Try;Fail;Improve, Michael Jordan states is "I've failed over and over and over again and that is why I succeed."

Or, you can watch this:

Gigi

 

I agree and it's difficult to phrase without opening a myriad of possibilities, in todays market if you're an aspiring beginner looking into commercial development or a commercial outfit. Knowing how to put a project together in 4 or 12 weeks isn't going to prepare or help in the future "UNLESS" you are initially starting out which as you say it's a dumb move to try and take on too much.

You need endurance more than anything, we all know it's very difficult and engines mask initially the learning curve. Which goes from 10 to a 100 in seconds when you start looking at coding shaders and tools.

There is no right way of doing it, all I can say with todays market for jobs etc. you need to understand the complexities of larger or very intricate projects to really stand a cat in hells chance of going anywhere.

 

Agreed, but I also have to agree with Gigi that finished projects, and multiples thereof, are the starting point for this. Nobody's saying that they're all there is, or that those alone will teach you all you need to know. But you don't learn to run without being able to walk first. Similarly, you learn to make completed software (games), and then you grow the size and complexity of the software (games).

Also, sticking with the GIgi numbers... A newbie comes along and picks what they think is a 12 week project. Instead of 12 weeks it takes 8 months, because they had no experience on which to base estimates. No big deal, they still got there. It still took endurance, skill, persistence, passion and a hell of a learning curve, but they got there. Now they can go for their second attempt and after 8 months already have a whole game under their belt. Rockin'!

Lets flip it to a "BIG" project. They think it'll take 18 months. Two years later, assuming they last that long, they realise they aren't half done yet. Plus, they're struggling with all of the newbie mistakes they made over the last two years because that's what happens when you're learning the fundamentals as you go. And there's still entire phases of the project that they still know nothing about, because they haven't got to them yet.

As someone looking to hire I don't give the slightest toss about the size of a (non-trivial) project, what I want to see is ability to deliver completed things. If I get someone on my team who can finish things and is willing to learn then I'm highly confident that I can shape them into an effective member of a larger team on large, complex projects.

 

I feel I should clarify that my interests are strictly as a hobbyist. While I wouldn't shun a second income, that's not my objective. I'm just having fun with Unity and making things. And no matter how lucrative my hobby got (which it most likely won't at all) I would never leave my current career.

Granted, advice on how to get a career started may apply to others reading though.