Planning Larger Games

How do you go about planning out larger scale games? Either when working on one solo or in a team? I recently had an idea for a game I'd like to make in the future, but it's far out of the league of anything I can make right now. I'm hoping that if I plan it out right while also learning and practicing game dev then by the time I DO have the knowledge to make the game, I'll have had most of it planned out. Problem is I don't know where to begin planning. How do you smart folk plan your larger games? From the story to the art and such, do you sketch it out in a physical notepad? or make notes on your computer?

 

1. Get trello
2. divide columns into done, bugs, pre alpha, alpha, beta and In Progress
3. for each entry go inside the element and add checklists etc
4. tick entries off, drag boxes around etc, use trello to it's fullest

Trello saved me. It took a few goes at using it until I was satisfied but if you place all of your trust in trello including notes, you'll have a pretty good project management system for free. I use the online version.

Trello only works if you want it to. If you don't keep it healthy, that's your call. Really I like to see it as a way to view everything about my project, what I have done, and where I need to go.

 

looking at it, it seems to be a glorified to do list seems helpful for sure but seems more like the thing id go to once i started development, no so much when im working on writing out the story and thinking of the visuals

 

You can add your special graphs if you want. There's a lot of powerups, addons and integrations.

But if you are just planning a game out, I think the best thing for that is a prototype. Even the best laid plans won't really work out.

 

thing is i cant prototype. im still just learning. I wanted to plan this game out as much as possible so that when i CAN make it, it have most of the details

 

Focus on the learning now. By the time you learned enough, you will be able to come back and answer this question yourself.

 

What even are "larger scale games" ? I should've asked that. For everyone it might be different. Perhaps naming an existing game is a good way to describe it.

 

Jot down your design ideas (not implementation ideas) in Evernote or some similar, always-accessible, reorderable note-taking system that can also hold images such as sketches that you snap with your phone's camera. I enjoy writing on real paper, but I inevitably end up with a stack of disorganized papers several inches thick. The 1% of good content gets hidden in the 99% fluff that I've jotted down but ends up having no value. The nice thing about apps like Evernote is that you can jot down ideas anywhere as soon as they hit you.

Don't worry about planning how you'll make the game. You want to capture your design vision first, although it will probably change during development.

Don't get too fixated on exactly how the game will play. This will almost invariably change as you start to block out the basics and prototype gameplay. Halo, for example, started out as a third person action adventure (maybe more like Uncharted) before it became the first person shooter we know.

 

I'll take a look at evernote, thanks

yeah I'm not planning out how I'll make the game,not yet anyway. Just simply what I want the game to be, story and such, certain items and how they'll work, that kind of thing. I know for sure it will change as I work on it, hell once I start actually developing it I'm sure 90% of it will be completely different, but I want to have as much of it noted down as I can so I don't forget, and also so once I'm capable of making it I have it all ready for me.

 

Sounds like a good approach!

BTW, I use Google Drive to capture notes. Some people use OneNote. I threw out Evernote as a suggestion because it's popular. Whatever apps works for you.

 

If this is a project you're doing on your own, the various team tools like trello can still be useful but aren't quite as necessary, and can add an extra level of overhead that isn't needed when you're the one that will be assigned pretty much all of the work.

I like to start by setting up an internal wiki, Microsoft's Visual Studio Team Services is free for small teams and includes a free one.

The most important part of the beginning on the project is scope. Take your idea, and try to run through everything you would like in it from a high level, all the major features. You could do this as a bullet point list, or in outline form, whatever suits your needs. After that then start prioritizing them based on required features, really good to have features, nice to have but optional, etc. You can use colors, numbers, or whatever you like.

After that, dig into all the required features and scope them out in a similar fashion. Required components for that feature, good to have, nice to have, etc. Optionally do the same then for the really good to have major features as well.

Then take a step back and now that you have really dived deep into what will go into this game, again go from the beginning and you'll notice your opinions may have changed about certain things, you realize there are new features you need in the list now that you've thought about it more, there may be different priorities than what you first thought, etc. Ask yourself, if you only complete all the required components of all the required features, will this be a fun game and will it live up to your vision for it?

At this point you should have a pretty clear list of what will be in this game. Now start estimating the amount of work (time involved primarily) that will go into each component. Also note down anywhere you will incur any outside costs, such as needing to purchase assets, needing to hire voice actors or modelers, etc. When you're done you should have both a development time estimate and a cost estimate for the entire game. If you only do all the required components, is the time estimate and the cost estimate reasonable for you to do on your own? If no, then you may need to go back to the beginning and reprioritize, consider bringing in additional help, or worst case walk away from the idea for now (this is hard, but stopping yourself from putting 4 months into a game you can't reasonably finish is actually a good thing).

Now assuming you can proceed, instead of doing the painful task of cutting features that most people consider scoping the project, you instead consider adding in various non-required features and components on top of the required ones until you are satisfied in the feature set and in the investment you'll be putting into it.

At this point I start making wiki pages for individual features and their components and start planning out in more detail how they should work. This isn't a bible, and can change, but later is used to remind you of what your original goal was, which can be forgotten as you spend months in code. After that then you can start coming up with individual tasks to work on, and can bring in a tool like trello (if this is a team project a task assignment tool is virtually required to keep things organized) or just write out a list of tasks to work on over the next few weeks.

Back in the original outline, start marking off things as they are complete. Don't be afraid to change the plan as you work on it, but always consider what those changes will mean to your ability to complete the project.

As far as organizing what you should work on first, you can consider coming up with a list of milestones and mapping features/components to those milestones. You don't have to entirely complete a feature all at once either. Sometimes it is better to get minimal functionality of a feature working early so as to get the game playable as quickly as possible, and then further develop those features down the line. For example, a required component for NPC creatures would obviously include AI, but in an early milestone you can just have the NPC run straight at you and attack, and at a later milestone add more complex behavior. This can help with motivation as having a playable game in itself is pretty exciting, it can help with play testing your game internally, and you can use it to start getting some 3rd party feedback on your game.

 

Speaking of scope, one of the best tips I've come across is to summarize your gameplay in three words. Wolfenstein = Run & Gun Nazis. Gone Home = Explore Home Changes. etc.

This forces you to cut away the non-essentials to identify and commit to a core concept. Extra bells & whistles rarely transform a game with a weak core concept into a good game.

 

This is absolutely beautiful. One thing, though...

For a beginner this will be extremely difficult. heck, I've been dabbling around for a couple years now and I don't think I could give any kind of legitimate estimate of time costs, or possibly of asset purchases.

I'm going to look into how to make an internal wiki though. That's a fantastic idea. As of now my main method is just a couple of cluttered text files...

 

I've worked on a few projects that used wikis. The problem is that after a few months no one maintains the wiki. If anyone has thoughts on this, I'd love to read them. The most successful variation on this that I've worked with is, surprisingly, a Trello list with cards for various technical procedures such as how to set up the player and camera in new scenes. Maybe it works because it relies on search terms instead of the deeply nested hyperlink structure of a traditional wiki.

 

Yeah I would have talked more on that, but my post was already pretty long

I think it is totally fine to simply label things as unknowns at that early stage, for further investigation later.

 

Well I'm thinking less about such technical details and more about the design, stuff like gameplay and systems and whatnot (as per the stated subject of this thread).

Whether that would be better for a wiki or Trello list, I know not.

 

Start designing these on paper. Because it is the fastest method in terms of re-evaluating and changing bits and pieces.

 

I've not tested this, but using a static content generator like gitbook to do design documentation is something I've been considering. When the project moves to development, the first commit to main repository could be adding the gitbook as a submodule.

It keeps the documentation handy during development and viewable in a simple text editor with all the benefits of version control. Properly formatted PDFs could be produced quickly for showing to investors etc, or if you add a lot of images for reference then a html version could be generated. It keeps things simple for a solo dev, but capable of scaling to a team.

 

I've been building my own large scale game for the last 5 years, it's gonna be different for everyone, but the thing I've found most useful is a pen and paper. As soon as I write stuff down I will generally remember it, it helps me organise my ideas and makes me think about stuff without wasting loads of time, it also reduces the hours you spend at the computer and you can easily do it any where and it's very quick. Usually by the time I start programming it I've got a clear idea of what I'm trying to do.

 

A bit late to the discussion, but basically what you need is a production framework - a collection of management assets (tools, files, documents) that allow you to drive your project efficiently.

A good production framework should give you, and your team, visibility on the long- mid- and short-terms objectives and priorities (with roadmaps, milestone definitions, iteration goals, etc.), visibility on the work and status of the game (feature lists, work breakdown structures, etc.), visibility on the team capacity (staffing plans, events, etc.), processes to track and measure progress (team velocity, burn down charts, etc.), processes to review deliveries and deal with issues, and processes to identify, capture and mitigate risks.

Everything one needs to calibrate, and re-calibrate, game projects according to time, quality, scope and budget - during all the different stages of the product, from concept to preprod&production, through release.

This might sound like lots of complicated words just to sound fancy, but there's quite a lot behind all these concepts ; nevertheless it does not have to be complex, especially for smaller games. A good production framework is designed to help you manage your project, not get in your way with overly convoluted processes.

Trello is definitely is a good start for small and medium projects ! I would recommend it myself. Though until you really know how to get the best out of your tools, it might seem like a glorified task-list. At least it's a way to get organised

I've seem similar questions about project management come up a few times, so I'm planning on starting a series of blog articles to "demystify" and explain game production, for small, medium and large games ; methodologies that work for both solo creators and AAA developers.
In the meantime, if there are specific questions about certain aspects, I would be happy to share my experience and offer my advice.

 

@Refeuh

Some idle thoughts:

I appreciate where you are coming from and agree, but I think the way indies get there is fundamentally wrong. It's really difficult to create those systems without prior experience, and even harder to understand the value of them for someone who hasn't done it before.

I think for this reason, it's probably better people learn the hard way to some degree. It's the same reason you learn to drive with practical experience, because you can read about driving for decades and still keep stalling it it on your first lessons.

Anyone doing a big project as their first project, definitely needs to fail and hard. This is a lesson that sets boundaries and makes them understand the value of a framework. Doing smaller projects and building up a framework along the way is I think, something you could teach them as well.

 

@hippocoder

Most definitely true ! Like other disciplines, production needs to be learnt and refined overtime. One does not become a programming expert or software architect just by reading a few books - same goes for production and project management : this does require first-hand experience and starting small reduces the risks immensely.

But, also like other disciplines, it's faster to progress with someone showing you the way. Artists, programmers, musicians, all benefit from peer review and collaboration with more experienced co-workers. That stays true for producers, and we usually learn the ropes and specificities of managing game projects by working with more senior producers.

That's one of the reasons I believe there would be some value in taking the time to present the fundamentals of game production ; understanding why some ways to organise things are better than others is quite essential to productivity overall (which in turns reflects on motivation, confidence, actual progress, etc.).

For example Agile approaches are quite popular these days, e.g. Scrum ; yet, not that many people properly understand "why" it stays away from "time estimates" in favor of abstract "story points". One might go through a management book or conference, and still be puzzled by some of the suggested methodologies. This is the kind of element that can be very counter-intuitive to developers learning production "on the job" without proper guidance or training.

 

:'(

 

I'll try to address the planning aspect specifically.

First, any large development project you can only plan so far ahead. The more complex it is the more you get wrong the further out you go. This is true for development generally. Studying up on agile development is probably as good a place as any to get some understanding for why this is. The point about not being able to plan ahead in any real detail is emphasized a lot in agile material.

Now for new game developers in the context of making games. You can't plan much, because you don't even know what the parts of a large complex game are. Even the things you have a basic idea of, you have no idea really of the cost to develop them or what order things should go in.

If you are coming in with experience in a hard skill, it's easier. If not, you really stand no chance, deer in the headlights really. I mean games are comprised of things we create with hard skills. If you don't have experience in that underlying skill, well you can see where I am going.

So if you know you don't have the skills yet, there is just no chance that planning will accomplish anything. If you have fun doing it, go ahead. There are worse things to waste your time on. But the reality is once you actually get those skills, you will look back and have a good laugh at whatever it is you planned.

 

If there is ONE thing to remember about managing a video game project, it is that, no matter how experienced you are, the plan WILL change (for a variety of reasons : replacing a gameplay mechanism with a better one, new ideas, external constraints, slippage, poor estimates, risks materialising as problems, and other various unknowns)

Therefore it is more important to plan "light" and track the differential (i.e. "how much" you drift from your initial plan) in order to re-calibrate the project regularly (i.e. balance time, quality, scope and budget), than trying to plan "thoroughly" and stick to a plan that will quickly become obsolete. That is, in its simplest form, the essence of iterative development.

 

Don't pull a face... you know I mean fail often as a method of learning... I'm sure you'll be mostly standing at the end of it!

 

This is such a major red flag. If you can't prototype your goal, there is absolutely no way that you can achieve it.

Writing documents or organizing lists is entirely pointless if your skill set is that far from where it needs to be.

Making anything that could be interpreted as "larger" when you can't build the prototype means you're looking at many, many years of work. Most of that work will be devoted to developing your base skillset and that will be a multi year process.

 

Doing a huge project without a prototype is raw stupidity, as simple as that. I won't mince words. I'm sure a prototype will be made though.