Saving time - how to develop games more efficiently

News & General Discussion
1

I’m learning that my tme is important. Let’s talk about it as Return on Investment (ROI). Certain types of game content lend themselves to getting a lot more ‘game’ out of a given amount of input. Indeed certain types of games may be more suited to a higher ROI than others. Especially if you are a solo developer, perhaps part time, this is a major concern, and I think a big reason why many of us fail to finish projects.

So for example, if my game entails needing a lot of pixel art, and each piece of pixel art can only be used once or to represent one object, then this has quite a high development cost. I have to hand-draw each individual pixel as well which isn’t very cost-effective, because it’s linear. More pixels, more time. Ie it doesn’t scale well. I can’t easily get a lot more bang-for-buck by drawing everything by hand. I could instead draw fewer frames and maybe use some tweening or maybe automated bone animation to save time. Saving time increases my ROI.

Another example might be a menu. If the game has only one menu then this menu can’t be re-used, and time spent developing it does not scale well. It has limited re-use and become a time-sink. Working on one-off resources that only have one use is not efficient development. And it’s also these areas of development that make me, and many people, bored out of our minds. We’re not getting enough return on our investment of time and effort, so it becomes not worth it.

Parts of development which do not scale well, have a low ROI and consume a lot of time with very little potential for multiplying its uses, leads to boredom and turns development into a chore. Unscalable development can come in the form of one-off or few-off resources that just chew up a lot of time without being versatile. It can also come in the form of something that is repetitive, like developing levels or drawing sprite frames, which, without automation, consumes huge amounts of time. One of the most significantly off-putting things about development is how much time it is going to take and how little the results are in comparison. Without optimizing development on purpose, it still takes a heck of a lot of time and effort for small, unsatisfying results. And thus the project becomes a chore and probably dies.

Case in point, I started on a cool platform puzzle game and built a small first level, was happy with it, and it seemed complete/polished. But then I realized I was going to have to build a lot more levels, and now the difficult time-consuming parts of making the first one was not going to scale well to the rest. I couldn’t get past the fact that, from a development standpoint, developing all those other levels was not going to be more enjoyable - it was essentially more of the same in spite of it seeming to present new challenges in the end-user experience. To me as the developer, it was a repetitive chore, and put me off. Without automating the level generation, it was game over.

So I guess what I’m suggesting/investigating here is, the importance (especially if you are indie or a solo developer) of choosing a game project that lends itself to a LOT of automation, and where the content and development that it needs can also itself be highly automated. And the automation definitely must take less time to implement than the time it saves. This would of course lend itself to procedural content. But it’s more than procedural content development. It’s about treating the whole development process as something that itself needs to be compressed and optimized.

And this also impacts the game design - if I’ve chosen a game that needs a lot of low-ROI development, it’s not a good fit. If I have to create lots of linear experiences with assets that are only used once, that’s not a good use of my time. If it will require writing a lot of custom scripts which only perform one function, is that really a good use of time? If it requires me sitting there for ages plodding through setting things up for each level and doing the same thing over and over, is that a good use of time? If you’re going to have to hand-tweak thousands of triangles to build special models and churn out only one a week, is that a good use of time? If your time is valued as much more important then you should be only working on projects, and only in a manner, which lends itself to getting a lot more output for your input.

Perhaps the ultimate goal here is a kind of ‘game generator’? Or maybe this is too close to that elusive ‘make the game for me’ button? Do we REALLY want to be in ‘game development’ or should we be aiming to be in more of a ‘let the game be developed’ mode? Perhaps this means outsourcing as well, or using off-the-shelf parts. But it also means not doing everything yourself, over and over and over again like some machine.

4 Likes
2

I think this may be a big reason why there are so many endless runner variants & randomly generated levels around. Define the rules then let the system generate your levels for you. The time spent defining & testing the rules would be big but once done you have almost unlimited game variations.

2 Likes
3

That’s a good example. Then what about the graphics that do appear in the level, individual tiles or sprites, how much time and effort do they take to create? How can that also be optimized?

I think optimum game development is kind of like a compression algorithm. You are trying to represent more stuff using less. A tilemap is a classic example. It re-uses blocks of pixels (tiles) with simple index maps to create the illusion of a large and varied environment without having to hand-draw every single pixel. Obviously at times with not enough tiles etc that can lead to the level looking very ‘blocky’ and repetitive… but at some point it becomes less noticeable that it is tile based. Or at least, less important or noticeable, especially if the individual tiles are well drawn and there is enough visual variety. Also different structures and higher-level shapes in the environment can give the illusion of originality rather than just more of the same. This is compression.

So to be an optional developer, you need to think in terms of hacking away at the encoded data, designing on a level of condensed compression, knowing that your efforts will decompress/expand to a representation that is far larger based on the amount of input.

1 Like
4

A lot of them are reused for the backgrounds/sides where the player never goes. They seem to be almost split into scenes/chunks that are randomly selected & stitched in with other random elements then placed around the scene depending on the rules for placement within those scenes. They may apply different shaders to give a different appearance, I’m not up on how to do it but apparently it can be done at runtime when the object is spawned.

5

Yup. This isn’t just a discussion of procedural content though. What I’m suggesting is that we need to choose to design games for maximum re-use of assets, minimal unscalable resources, not just developing everything but taking ourselves out of the equation as much as possible through automation of the development process. Yes, procedurally generating object placement etc is a good start. But what about the remaining graphics/sprites/objects? What about the music? What about level design? What about the AI logic? We really have to ask ourselves if we want to be THE developer, or the person who oversees the development.

1 Like
6

This is exactly the way I view it. My view is to focus on less completely new graphics content and rely more on programming and color to create the uniqueness. I had slipped away from that perspective for a while though.

There was a time when I focused on projects that were minimalistic not in terms of the quality / style of the graphics but instead to focus on the best quality I could get but minimalize the amount of completely unique content. And when thinking of things like RPGs that would require probably the largest amount of unique content my view was in that case to minimize the style and even overall quality of the graphics. Simple because there has to be some balance to it to get anything done. However, after getting Unity and coming to these forums I kind of shifted towards doing what I see so many other people doing thinking I need tons of content. And it really kind of burnt me out. It has only been in the past 2 to 3 months I have returned to my previous views.

I don’t think a ton of unique content is necessary. Trade-offs can be made. There is no reason why a person cannot make 1 sprite monster or 1 3d model monster and have it represent 2 to 4 different breeds of monster through simple color change and behavioral programming. Instead of making 12-frame animation sequences cut them down to 4-frames. There are many little things like this that can be done to help out I think. Like I used to just scale the images to different dimensions to get different characters, enemies and such. Combined with color change it is an easy solution. For example, an enemy can be made wider to be a “heavier” version. It can be made a bit taller and thinner for another version. It can be scaled equally to create a giant or a baby/dwarf. And that is what I am back to focusing on now so hopefully I can start getting things done again.

I agree with you completely that many solo devs are really making things far harder on themselves than they need to by seemingly trying to compete with AAA on overall graphics quality, animation complexity, diversity of unique content and so forth. It really is a silly way to do it.

And another thing I have in mind to do is to just to create series of games using the same main character that will allow me to reuse existing content. So the first game will kind of set the foundation. The next game can make use of a lot of the graphics content and add in more as well as increasing the overall scale of the game world or at least offer a somewhat different game world. This way the game can get to the point of being some grand thing on all accounts over time but I do not have to spend months and years just to finish the first one.

2 Likes
7

A phrase I heard recently that I liked is ‘work on your business, not in your business’. i.e. if you’re always in the ‘i am a worker’ mindset (which carries over from being an employee), you are not stepping back enough to work on the business itself, or on optimizing your time, or automating things, or seeing the bigger picture.

3 Likes
8

A good read. I find myself having done many of the listed and expected mistakes of developers. At one point I had more time to put in the level of detail or other forms of input, but that was when I could accept minimal output coming back. I can’t really do that now since my job has me working 50-60 hours a week min not including the driving to and from the plant.

So now I do simple fast tweaks with less detail. But the biggest thing I have done is developed small kits for myself and quick model outlines so if I want to create a game I already have stuff to jump me further into the project and all I have to do is tweak things.

1 Like
9

Procedural content doesn’t necessarily make for a high ROI though. Generation is still highly laborious, and the main value is in keeping a baseline of player engagement just above rote.

It really depends what kind of experience you are trying to deliver. Sometimes PCG may be ideal, but sometimes what may be the best fit is modular level objects that are hand placed or tools that make creation quick. Constant vigilance for tools that make work easier and faster is probably the only real solution, but this is almost always means you are compromising your degree of control and having to accept what you have as good enough.

10

Then perhaps control is an issue in getting projects done in a reasonable time. Maximum control would mean spending a lot of time doing everything yourself by hand, one thing at a time, treating each individual object separately etc. That will give you lots of control, but it is also extremely time consuming. Time can be saved by surrendering control.

1 Like
11

I think one of the hardest parts is generating gameplay without having to go in and set up every single puzzle or challenge manually. Especially if the game is more puzzle oriented or something, how to have the computer generate countless puzzle that are not only fun and interesting but also have a proper progression of learning curve. That’s not easy.

One of the things that’s clearly evident is that some games especially AAA where they spend much more time and money on ‘customized’ content, e.g. artists spending weeks on a single model or months on a single environment, costs a heck of a lot of money but you do end up with some pretty fantastic results. But doing that as a single indie is totally unfeasible, so you have to think about being more optimized and efficient and forgoing all that super-fine-detailed control and attention.

But I do know that coming up with ‘quality’ generated content is not easy, and can be somewhat sub-par in terms of design or playability, so getting it to generate something really useful and interesting is the challenge.

3 Likes
12

I think pretty much along the same lines when working on my own game: Getting the most bang out of my time investment and putting focus on the things that matter the most.
One thing I haven’t yet decided on is whether I want to have fully procedural content or if I want to generate procedural content that I then go and select specific content from. My thoughts were I’ll need to spend time testing levels either way and if I curate which levels end up in the game I can give the procedural generation a bit more freedom and don’t need to make 100% sure that no unplayable or bad levels are generated.

13

Sometimes certainly. Often control can be costly, where corners could be cut to produce equal quality, but other times it can be a lifesaver that enabled. Imagine having to rebuild what could have been a finished level to increase performance or ease player movement or something.

14

This really makes me wonder how long it will be before we’re able to just kind of talk to our computer and have it generate a really sophisticated unique game in seconds. Bye bye developers.

15

Well generally you’ll have custom built foreground meshes, then have everything else procedurally built in big games. Maybe it’s terrain that’s procedurally generated etc. dependant on what you’re building.

In smaller games, it’s generally not worth the effort trying to get an algorithm together that suits your need. One of the biggest things that helps speed up development as a whole is solid design documents and tools…

Reason why is you don’t want to re-invent the wheel, if you have a solid plan together and researched tools effectively to speed up transitional stages then you’re on a winner. Making tools takes a lot of time, with competition rising it’s time you need to spend on your game.

With tools at my disposal I can make large game frameworks in weeks, what I always find a massive slog is artwork. There is of course ways to be smart about it, firstly back on the game design… You don’t specifically need to go through high poly model workflows if it’s not going to be of any real benefit. That’s why I believe medieval era games work well, houses are quite blocky / lot’s of wood and rectangular surfaces… Rock’s etc. you can just buy as a rock is a rock.

So in that instance, textures with decent NM’s / displacement maps / smoothing groups (in some instances) will be more than enough. You can’t avoid high poly workflow through many applications in all instances, but again you can be smart with it… Especially if budgets allow…

There are SO many ways to speed up production, you just got to find what works for you.

1 Like
16

Yeah, I generally try to turn as much as possible into processes, or reduce work wherever possible. Whenever designing something a key consideration is “how long does this approach require for each unit?” followed by “how can we cut that down?”

When something is considered as a process it’s much easier to then automate all or part of that process. Some things require human/artistic/subjective input and thus can’t be automated, but you at least then have a clear picture of where those things are and what can/can’t be automated around them. You can also use that “bigger picture” point of view to figure out your time/resource budget for the hand-crafted bits, which can in turn be used to determine constraints.

2 Likes
17

Absolutely. You don’t want each level designer repeating every single design step. You want the common stuff and the design rules to be laid out in advance. People should only be doing things that are a) not cost effective to automate or b) intentionally unique.

Procedural generation isn’t the only approach, though. For one of my games I decided that levels would be a) tile based and b) 16x16 tiles, for no reason other than to make level implementation faster. (People weren’t making decisions about size, they only had a limited selection of tiles to work with, and the system in general did away with the idea of fine tuning which would otherwise eat time.)

1 Like
18

I also stay away from RPGs and others titles which require manual work. As an hobbyist I know my game won’t be played by many and that I am not developing this game for my living, so I don’t like to spend unnecessary time in development especially when it gets kinda boring when doing repetitive work as you mentioned above in your post. I like to stay with Procedurally-Generated Games, because you have to code just the rules, test them, optimize them, and let the game itself generate a playground for the player. But what really interests me in randomly generated games is that they never get boring, after programming rules when you hit the play button it’s a surprise for yourself also to see how the game has generated a virtual world for the player to jump in. This world is as unknown to you as to a player. I sometimes just roam around in my game just to see how I have created this with some lines of code. It tells me how interesting is game development.

So, in conclusion, randomly-generated games appear more interesting and less time consuming to me than manually handcrafted games.

Yet another thing that takes a lot of time in development process is the Optimization Process. We want our games to be highly optimized. We very often search for “What’s the best way to do this and that?”, like for a very basic example, there’s have been talks in forums about gameObject.Sendmessage(). People say sendmessage is slow when compared to direct function calling through script. Yes, it’s true but it only holds true when you are continuously sending messages like in a loop. Using sendmessage in your scripts sometimes doesn’t hurts as it is fast and simple in terms of ‘coding’. Unnecessarily, optimizing the parts of game which do not need optimization often leads to complex and time-consuming code.

1 Like
19

You see that a lot here and on other boards. People hear or read something somewhere and take it for gospel (or out of context) without ever researching or testing. Most things can be done a ton of ways, for the simple reason of context. Or the read some example and assume that is the only way.

“Never” or “always” should be treated as red flags when in feedback. (At least when talking engineering, or dev in general. ) sendmessage is a great example, as is ‘never use find()’ or the assumption that dumping stuff in a resource folder an effective general way to load stuff into a game. A lot of suggestions and answers here should be taken with a healthy dose of skepticism, or at least serve as a starting point for further investigation.

3 Likes