I know this must be one of those “beating a dead horse” topics that has been done to death and then some. Nonetheless, I decided to make another one of these threads.
How do you go about finishing a project? I feel that actually getting there is the hardest part. Do you make game design documents or a schedule? What is the secret sauce of making it to the end?
Are bargains with forces of evil perhaps required to accomplish this?
1 Like
Every year of work divides the remaining time left to finish in half 
6 Likes
I think one of the most common mistakes people make is that they don’t actually decide what ‘finished’ looks like - they don’t have a definition of done. It’s always possible to keep tweaking and improving and polishing, but if you are not careful that will just keep going on forever. You have to decide when to stop.
It might be that you build up a checklist of criteria that you need to meet before you ship - “must have at least 10 levels, load times must be below 3 seconds,” etc. Maybe you timebox it: you say to yourself, “I’m going to release in 1 month, what improvements can I get done in that time?” Maybe you combine the two approaches: set yourself a 2-day limit to ‘review’ what you’ve got and build up a list of things that could use improvement - no changes, only review (and maybe get playtesters involved too?) - and then see how many of those things you can get fixed up in two weeks, etc.
If your problem is motivation, then do not underestimate how much these techniques can still help. A lot of the time the motivation problem comes from not having a clear goal - you end up being like “wtf am I even trying to accomplish here” and nothing feels like progress because you never actually decided a direction.
Also, remember that these days, ‘shipping’ is not the same thing as ‘finished.’ You can release the game and start to get players, get feedback, maybe get some money, etc - then put out patches, or even just do a whole new game as a sequel. In that world, you ship, but you aren’t necessarily ‘finished’ ever, if your game is doing well and you still want to keep building new things for the players.
9 Likes
“Art is never finished, only abandoned.”
Leonardo da Vinci
2 Likes
I find that the best way to finish something with a deadline (i.e. you need to get it done fast) is to break it down into small steps. Do what superpig said and first decide all of what your finished project will include. All of the levels, all of the menus, all of the options - everything. Break everything down into the smallest-possible steps. Put them in logical order so if any step requires another step to complete then you do that step earlier. Try to break each feature down as small as possible- things that can be done in just a few hours.
Then you don’t really need to think about what to do. You have a list. You can go down one at a time and knock them all out.
This!
Once you know what “done” is, then a few things pop to mind.
-
Make sure your vision is within your resources. If you need stuff that you don’t have and can’t afford then you will never be “done”, so be ruthless in evaluating your plan for finishability.
-
Be disciplined and form good habits. There was a while when I dedicated myself to working on my game for 1 hour every day. Having stuff like task lists is important here, because sometimes you’re brain dead after a day at work or whatever. But that’s ok. There are mindless tasks which also need doing, and you can do them when you’re brain dead.
-
“Perfect is the enemy of good.” Not sure where that comes from (aha, apparently it’s Voltaire’s take on an Italian proverb), but the important point is to recognise when things are “good enough” and move on, rather than spending the extra time it takes to make them “perfect”. Big, successful games released by experienced devs with much higher budgets than you get released with imperfections all the time. You don’t have to iron all of yours out, either.
3 Likes
Very good point here.
I used to think things like early access had no real merit (just because of the negatives), but after seeing the way games like Subnautica were developed, it made me realize that the traditional way of releasing games is fundamentally disfunctional. The idea that you can spend years in isolation working on something and then somehow turn up on Steam with a game that meets gamer’s wants is completely illogical. It doesn’t work that way in any business ever, regardless of whether the metric is financial success or player satisfaction.
In fact, if your highest priority is giving the most amount of fun to your players, it’s kind of weird not to involve them in development as early on as possible. After all, presumably they know better than you what they want!
That’s just one of possible points of view, based on assumption that your only goal is making money and thus doing whatever random stuff your customers may request on a whim. An alternative view is treating video games as art - and then author’s satisfaction and vision of his final goal are equally (or more) important metrics.
I’m not aware of Van Gogh changing his style to sell more paintings, or asking his prospective customers what details he should add to his works finished while in isolation from outside world. Maybe because he was an artist, and not a businessman.
1 Like
Your reading of my comment is completely mistaken. You seem to think that trying to make a game for someone else and having only a profit motive are the same thing. That’s obviously not true.
I feel compelled to say whenever I see these kinds of comments that there’s nothing wrong with wanting to make money with games. Sometimes when I look at what steam has to offer it occurs to me that a bit of cold-blooded business sense would probably sort out a lot of the problems.
But for me personally, I don’t want to be primarily motivated by money when I work on my games. I want money to be simply the reward for doing a good job at whatever I do in my life. That’s why I practice good business sense at every opportunity. But it isn’t what motivates me or I would be trying to make it in a far more lucrative field (which I am).
But making a game for other people is part of what motivates me. Seeing other people having fun with something I’ve made is very rewarding for me. Taking into account the player’s motivations, intentions, interests and emotions is as compelling for me as writing my own story.
Also, I think you have the wrong idea about what art is. Art is not an exercise in the artist’s self satisfaction. It’s an exercise in expressing something that you feel an overwhelming desire to express, something that you need to be perceived in some way. Art is created for the observer, whoever or whatever that is. For some artists, the observer is imagined, but I can’t remember ever seeing an artist who couldn’t get enough of seeing their own work.
3 Likes
That’d be a quick way to making a conflicted and/or broken mess. Giving your customers what they want is typically a good idea from a commercial perspective, yes, but that doesn’t mean acting on “random stuff” that comes up “on a whim”.
Perhaps if he had then he wouldn’t have died poor? And doing so wouldn’t necessarily have made him any less of an artist, either, considering that many iconic pieces of art by renowned artists were made on commission.
Well of course, because that seems backwards to me. In my mind, it makes a lot of sense to find out from your prospective audience a broad sense of what they want, and then figure out the details of how to do it well. This gives us a better chance of making a thing which will generate income while still giving ourselves room for creative expression, and to make something our own.
And, going back to my earlier point, it’s probably a part of making the thing work, too. Plenty of my players have asked for things which would have broken or spoiled the thing I was making. And that’s fine, because I don’t expect them to understand the impact of the thing they’re requesting - they’re not game designers, I am.
Plus, if your audience reaches any kind of scale then you’re going to get a variety of suggestions, many of which conflict with one another. Between that and the above, even if we did just stick to reacting to what our customers tell us, there’s still plenty of room for us to be choosy.
For sure, commercial success isn’t the only kind of success. It does seem to be one which many people aim for by default and without really understanding it, though, which really is a shame.
To riff off of “art is expression/communication,” a worthwhile part of that is ensuring that you’re communicating what you think you are, especially with as complex of an experience as a video game. Feedback can help that.
2 Likes
I start to developing a project until I get boring from project when I bored from project in most cases if it is a personal project I abondon it.If it is a business project proably I would find a fastest and cheapest way to finish it
The scope has a lot to do with it. I started plenty of stuff but was just to overwhelmed by everything there was to do and how long it was taking. Only the very very smallest of projects ever got finished. And that usually means something that can be done in a matter of weeks. Which does not bode well at all for anything more exciting that you might dream of doing. My “dream projects” are unfortunately somewhat larger and more involved and probably will take a long time, which makes them not only daunting and very elaborately complicated, but also off-putting by the sheer amount of stuff they require. And unfortunately dreaming and having ideas is far easier than all the tiny little nitty gritty “things” you have to actually DO to turn that into a piece of software. It’s easy to get out of touch with all the actual real-life activities that are involved in ACTUALLY and REALISTICALLY implementing/executing what you’re trying to create, versus how effortless it is to picture it in your mind. Computers and the rift between their language and yours makes that whole translation process harder and longer.
2 Likes
I’ve been thinking a bit about how I “scope” and “define” a game before I make it.
I say I want it to have at least these features, then I can start adding other stuff if it makes sense.
That sounds great when you single out each feature or maybe even how features tie together,
however, sometimes when you get all those things done your game still doesn’t feel “complete” and the game doesn’t seem to flow together as you imagined it.
I think a great exercise for designing a game would be to describe what a user experience would sound like and write it down.
for example if you were designing Sonic, instead of saying.
-you can spin on the spot and launch forward at high speed
-when rolling you kill enemies
-when hitting spikes you lose your rings
-if you get hurt without rings you die
You could write an “expected experience”:
“I ran into an enemy and it hurt me and I dropped all my rings.
I ran into the enemy again and I died (because I had no rings) and lost a life.
I respawned at the start of the level.
I rolled into the enemy and I killed it.
I rolled into some spikes and I lost my rings”
When you spell out a scenario in a practical order of events, you pick up on all (or most of) the things you’ll need to make decisions on for what happens in different scenarios.
Keeping it high level makes you think more about the user experience rather than the “available features”.
Hopefully, that helps someone. I’m going to try it out on my game and see what issues come up!
Yup. There is a version of Agile development that incorporates this. They’re called “User Stories”. They’re user-centric descriptions of exactly what you describe. The user experience. Engineers tend to dislike it because it doesn’t describe much of how to build that experience, so typically engineers have to go above and beyond just the technical requirements to achieve the goals in the user stories. Producers, designers, and marketers tend to like this, because it provides an understanding of what the end product is. This puts a lot more weight on the engineers’ shoulders, and they need the full support of producers, designers and artists and management to narrow in on how to build that experience.
Things that helped me:
Someone to be accountable to.
Not feeling discouraged or embarrassed every time a friend or family member was amazed I was “still working on that game?!” (they still say this, but now it’s “But I thought you’d already finished that game?!”).
Remembering that despite game dev being very hard work, incredibly time consuming, all encompassing, I really love it. Sometimes it feels like you’ve reached the peak, but you zoom out and realise you’ve got a whole mountain to climb. I guess you’ve got to love the climb and all the challenges it presents. (even when you reach the top - you’ve still got the climb down. It’s all climbing).
Picking battles. I wanted everything to be perfect, but some things have to give. This one was very difficult and a constant struggle - working out where to spend your time effectively isn’t always clear until you’ve already invested a bunch of it. But reminding yourself to at least try to prioritise helps.
Clear targets and daily goals. Project management tools help, there’s just a risk that (in a small team / solo) you end up spending more time in project management than making the game. We found Notion to be a useful tool to collaborate on lists and stay on top of our to do list.
1 Like
Keep working and resist scope creep.
You will have lots of great ideas to add to your game as you develop it. Be extremely selective about which ones you actually include, and think about how much development time they will add. Anything you like but doesn’t make the cut, note it down for a potential post release update or DLC content. If you keep adding all your great ideas to your game, you will never finish.
This is actually a fairly classic game design technique - the “5 minutes of gameplay” description. It’s usually been used as more of a pitch strategy (to help people understand what the game will be like, if they fund it) but there’s a lot of overlap between pitching to investors and communicating a clear design vision within a team (or just to yourself).
Dwarf Fortress has famously used an approach where they write short stories about dwarves, and then kinda analyze them to ask themselves, “what would we need to add to the game for this to be a story that could actually happen in the game?” Of course, this is more of a technique for adding more things to the game, not for finishing it - if finishing is your problem then you may not want to model yourself too much on a game that has been in development for 18 years
4 Likes
I like asking people to describe an experience, and then to describe a game which provides that experience with the minimum amount of work. What is the smallest possible set of functionality and content you could use to provide that experience?
Because at the end of the day the experience is what matters in a game, not the features. The features are just the tools we make to provide the experience.
On a very similar note, for features themselves I suggest taking a look at the idea of “use cases”, often used in agile software development. They’re a way of defining a feature based on the user experience of that feature rather than on how it works.
For example, in an RPG a lot of people would by default think “I need an inventory system” and them immediately jump to “there will be a grid, and each item takes up a width and height in that grid and also has a weight.” That’s a common way to implement the ability to carry stuff, but it’s not the only way, and it might not be the best way to support the rest of your game. If we instead look at it as a use case: “As a player, while I am out on an adventure I want to be able to pick up loot, and then sell it when I return to town” we can now start thinking about different ways to achieve that experience. Depending on the rest of your game’s design you may come up with something very different to the standard inventory grid, and it’s quite possible that it’ll both fit your game better and be less complicated* to implement.
- For example, a grid with sizes and weights is pretty simple to build in and of itself, but now every item needs two graphical representations and a bunch of extra player-exposed data. A heck of a lot of work goes into making that stuff and it might not make your game better. Stuff like this is a killer for many projects.
2 Likes
For every original finished games, there are 1000s of abandoned projects… that’s the reality…