What do you do to cut development time?

General Discussions
#1

Originally, I was asking if there are ways to cut development time by striking a good balance between prefection and efficiency. For example, I wanted to create assets by scratch, and I want to get it done quick, but I need to take time drawing the art assets to make it look nice, and engineer sounds to make it lively.

Of course, the answer is to delegate the tasks to third-party producers, or increase the budget/extend the planned deadline further.

Now, I want to ask what else do you do to cut down development time, even if it’s not completely related to development? I might get some valuable tips as an hobbyist/indie guy.

#2

We cut features, ruthlessly.

Cas :slight_smile:

#3

I cut corners with a corner-cutting machine!

Just leave out unimportant features (graphical gimmicks and the like), then implement them later.

  • Longor1996
#4

Do not reinvent wheels.

#5

You’d be surprised about what constitutes an “important” feature. In the end you can reduce games down hugely and still have the same game just by cutting out things that don’t really affect the gameplay at all.

Cas :slight_smile:

#6

Aside from things like “Be a better programmer/artist who can produce the same quality work faster” really the only logical answers are “Work more every day”, “hire help”, or “cut features”.

Personally I disagree with cutting features unless you’re on a strict deadline and have no other option. Those little things you cut are the difference between a hit game and another B-title. There’s a lot to be said about the “charm” of some of those oddball features that would normally end up cut from a game due to deadlines.

#7

I would agree about cutting features. Planning ahead will save you a lot of trouble. If you make an outline of your major ‘have-to-have’ features and functionality it’s easier to detect when something is not contributing to the end goal.
Plus, if you have some type of plan, it’s easier identify and stop yourself from adding those weird features you start thinking up at 12:00 am when your brain starts wandering :wink:

The catch here is to keep your initial plan small. I’ve found that when I estimate how long something will take, I almost always have to double my estimate because I’m so poor at predicting how the feature will integrate into the rest of the project and what refactoring will have to occur :clue:

#8

I have to resist the pull of the internet. :smiley:

#9

Key word… Focus.

In order to cut down development time, there is no better way than to cut features. When I say cut, I mean…

  • Don’t work on those features in the first place
  • Leave the feature in the unfinished state it’s in
  • Separate it from the rest of the project by removal
  • Outsource the feature to someone else.

This goes for all aspects of development (art, sound, programming, and marketing).

In pinch time, you only have time for the core features. Being able to visualize the fluff is so important during this time so you can get a working project out with features that is needed. My way of figuring that out is just asking if I can make a “bullet point” in my update list about it. If the feature can’t be put in a bullet point, then there probably isn’t any point having that feature. :point:

Other than that, it is just battling the toils of procrastination and project fatigue.

#10

Cut features
Cut maps/levels/assets/content
Cut polish
reuse code/libraries that exist
Break up with girlfriends
disregard social life
work 7 days a week
quit day job
don’t cook food, just order in or whatever

get more programmers who do all of the above
keep an eye on them and whip them

Note: I recently read Masters of Doom, so my suggestions might seem extreme :smiley:

#11

Creating any new product is usually about iterations. You can effectively cut your development time by reducing time spent on one build cycle and increasing the number of cycles -this will help you to recognize problems and fix them earlier and cheaper.

Here is a trick I use for game programming:

  1. Create a Java interface which represents some perfect game engine that has all possible features of all possible game engines, and that is an absolute perfection of all game engines ever. This step is quite cheap because you don’t really write any code except method definitions.
  2. Write your game using this so-called-game-engine. Here you should write some good code because it is going to be reused a lot in the future. Any line of the code you write here should bring you closer to the release. It is all about finishing, right?
  3. Then you write some real-crappy-mock-but-still-working code implementing the promised functionality of the so-called-game-engine. BUT you don’t really implement everything, you just implement what the game actually requires and nothing else. Cheap and fast code.

Summarizing what you have in the end:
A)“Fail fast” - You just wrote some working code giving you the prototype/build-version of your game. (Now you can test it and trash it realizing how wrong was the original game concept ;D)
B)“Design by contract” - The resulting code architecture is good for maintenance: whatever crap you wrote for the “perfect-game-engine” it is not affecting your game. The crap is hidden behind “the perfect interface”. Now you are free to fix it, you are allowed to spend years in philosophical meditations about perfect code solutions, or you can just ignore it for any reason you have in your mind.

#12

About everything has been already said, but here’s my input regardless:

#13

+1 to the feature cutting!

Actually what I generally tend to to is to grow development time exponentially. Some days I just tend to be full of energy and cool new ideas. Those are bad days. On those days a nice simple game turns into some unfinishable monster of a game.

Luckily more recently I have come to recognize my bouts of featuritis (had one yesterday), and I get better at ignoring them, for example by writing them in a list of “ideas” that may or may not (most likely) be implemented.

#14

Interesting point of view. Basically being too creative is bad for finishing stuff.

I guess that’s where team work comes in. If you’re in a creative mood you should be in the role of creative director and apply your energy to a design for a future game, if you’re in a less creative mood you’re the developer for the day to work on the game in progress :slight_smile:

#15

Its also a matter of where to apply your creativity, and not so much a matter of more or less creativity. If I’m creative in implementing an essential feature I had in mind things are going great. However, there’s also something thats more like “lazy” creativity: freewheeling dreaming up things that would be so awesome, regardless of whether its possible or not. Thats useful at times (e.g, brainstorming new game), but I find that creativity is most useful when constrained and steered a bit, for example when also considering time and complexity limitations. Thats a harder kind of creativity, but very useful for solving complex problems.