Hardest Position In Game Designing

You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.

I don't know the first thing about game development, but when I see animation like that in SFV I can't help but think of all the pain-staking hours it took to draw that stuff. Am I wrong? Are there other areas more difficult than Animation? Enlighten me... or just tell me I'm right! Haha

Cokie Bear

Attempted to circumvent ban with alt account

It depends on how skilled the animator is I would think. Something being time consuming doesn't mean it's difficult.

"Hardest" or "most budget consuming"?

I think programming the game is harder, but I am a developer so I am biased

Hardest? Depends. But it's the most time-consuming.

Of course this is nonsense. You get get what you pay for. In any specialization.

Animation takes a LONG time, I do programming and my wife animates, I now never want to animate lol

I guess. I know "jank" is one of the first things a lot of people notice when they play a game. It's definitely important.

I still think good-to-great AI is still rarer and harder to find, let alone create.

Simulations and programming are harder.

Animation is just very time consuming. It's not hard. And that's coming from someone who's worked in both 2D and 3D animation for film and TV.

Initial impressions of Mass Effect: Andromeda certainly shows how important it is.

Should I get the popcorn out for this ANIMATORS vs PROGRAMMERS deathmatch this thread will inevitably become

WHOS WORK IS MORE IMPORTANT/HARDER YALL?

I don't know the first thing about game development, but when I see animation like that in SFV I can't help but think of all the pain-staking hours it took to draw that stuff. Am I wrong? Are there other areas more difficult than Animation? Enlighten me... or just tell me I'm right! Haha

Depending on the day, every job is the hardest, most painstaking, most time-consuming job in game development. Yes, even that job.

Like most things, it's easy in the sense that anyone can do it, but it's hard to be great at.

Programming, easily. For the most part animation is applying known techniques and styles. Programming is often entirely new, uncharted territory that needs to be carefully documented or you lose months of work.

I don't know the first thing about game development, but when I see animation like that in SFV I can't help but think of all the pain-staking hours it took to draw that stuff. Am I wrong? Are there other areas more difficult than Animation? Enlighten me... or just tell me I'm right! Haha

If you're talking about Street Fighter 5...all of its animations were motion captured and then touched up by hand in a 3D modeling/animation program, not drawn.

Also...

What's harder, bench pressing 200kgs or doing a 9.0+ floor routine?

I think programming the game is harder, but I am a developer so I am biased

Depends on the scale of the work (Basic 2D platformer, vs something with complex AI behavior, components/algorithms, extensive physics interactions etc). But having done both animation/modeling/art and CS(Switched majors later). Programming is definitely harder. But art is way more intensive, and takes a loooot more time. It's by far the biggest component of a good game.

I think it's relative. I wouldn't touch animation with a 1000ft stick again but I also know many people who feel the same way about any respective other job whether that be programming, designer or producer for example. Each job has huge importance and has the potential to go horribly wrong because of the difficulty especially at the top level of development. I saw a tweet the other day I absolutely agreed with about design, everyone thinks they could be a perfect game designer because the difficulty isn't immediately visible but especially in lead positions that job is high pressure and again if the design falls flat artists and programmers can only salvage so much. Each job is extremely important to create an accomplished product and each job is extremely specialised and difficult.

If you're talking about Street Fighter 5...all of its animations were motion captured and then touched up by hand in a 3D modeling/animation program, not drawn.

Well not all of them, there's obviously a lot of stuff in that game that can't have been motion captured.

Animation = Longer/time consuming
Programming = Difficult

Well not all of them, there's obviously a lot of stuff in that game that can't have been motion captured.

Of course, and all of the facial animations were done by hand too.

But they sure weren't drawn.

Programming, easily. For the most part animation is applying known techniques and styles. Programming is often entirely new, uncharted territory that needs to be carefully documented or you lose months of work.

I think both can be extremely difficult at a high level. It's just that animation is at least a bit easier at low levels than programming. Look no further than stiff character animations like MK, which most people think are perfectly fine.

Difficulty is in the eye of the beholder. Some things are easier for some people than others. I write music and it comes very naturally to me, while others would be incredibly frustrated by what I do. That's why it's good to follow your strengths and talents.

Labour is not a competition and everyone needs to get paid more

I think low level engine programming has to be the hardest

there is no easy job in game development.

Nome

Designer / Self-requested ban

The hardest job by far is a product manager for a live services game. This role handles a project's profit and loss, user acquisition, business dealings, resource allocation, and also functions as a feature designer.

A good product manager will rake in millions in revenue. A poor product manager will cost you millions in potential at best, or tank your company at worst. Unlike other jobs that don't have education or certification requirements, an MBA or knowledge equivalent is effectively required to perform. It's no joke.

Having done every step myself, I'd say animation certainly ranks up there.

Maybe not hard, but like any other form of animation, it's a largely time-consuming endeavor, especially if your trying to do it well. As someone trying to learn the ins and outs of effective animation, you REALLY need to have a love for it to stick with it.

most staff credits have fewer animators than other positions

Bug fixing is the correct answer.

as someone who can't art very well but who can program pretty complex shit, I'd give it up to musicians. I completely lack any sort of musical talent and thus musicians are magical to me. I feel like you either have the gift or you don't. To me, what makes music good or not is entirely creative. You could be technically terrible at actually playing the music but still a brilliant composer.

All kinds of respect to musicians. Especially good ones.

I think low level engine programming has to be the hardest

If we're not talking about game programming, I think demoscene projects are pretty much by definition the most difficult projects around, which typically thrive in the realm of low level programming. I'll quote a post I made a while back on the work that went into perfecting the Blast Processing sega genesis demoscene effect:

Blast processing is amazing. I mean the actual, real deal Blast Processing, the technique described to the Sega marketing guy that he didn't understand at all. It is an extremely technical bug, that people knew about for decades, but was considered flawed until 2012 when primarily 3 coders - Oerg88, Nemesis, and ChillyWilly, developed a method to perfect the technique. I've been trying to write a blast processing demo myself without looking at their source codes for several weeks now and I still can't replicate their steps without cheating. But the process is so insane it's worth talking about.
So, firstly, what is blast processing? Most people assume the term refers to the general speed of the Sega Genesis CPU and how that speed allows the Genesis to do more runtime (read: CPU bound) special effects than the Super NES, thinking "blast" as a term for quickness. Blasting, in fact, is a demoscene term that means sending data to a piece of hardware without an interface. In this specific case, "blast processing" referred to a way the programmers at Sega could "blast" data at the Video Display Processor, the chip that outputs the final image to the television, ignoring hardware data structures and interfaces the chip has built in intended to let people control it, using a method called "Direct Memory Access" to produce strange, even fantastic results way, way beyond what the Sega Genesis hardware could supposedly do.

There is a very good gamehut (head and lead programmer from Traveler's Tales) episode where he discusses stumbling upon the technique back in the 90's and why he, and sega, abandoned it:

That video gives a pretty good broad overview of the concept, but skips a lot of the technical nitty gritty that makes the entire process a lot more amazing. And, more importantly, it skips the recent (relatively) discoveries which now makes the effect viable. In short, to recap what the video above talks about, and go into a bit more detail, the Sega Genesis VDP exposes a few hardware ports to the Sega Genesis CPU and DMA controller which allows software to modify the video hardware. This is intended, for example, to let the CPU change palette colors in the VDP's Color RAM. The problem is that these exposed ports are singular working in parallel, rather than dual ports. Meaning there is only one port, for example, to both read and write to Color Ram in the VDP. When you write to the Color Ram, you are simultaneously using the same ports the VDP uses to display color on the screen. This causes an error known as CRAM dots when you change a color -- the current position where the VDP is drawing to the screen will display a pure RBG value that equates to the 15-bit value being written to CRAM

Now, the Genesis displayable screen is actually much larger than the normal television display, extending far to the left and right (and up and down). As such, most programmers can hide palette changes so they occur when the VDP is drawing offscreen pixels, hiding the artifiact. But some games can't get the timing down and CRAM dots are visible on a real TV screen. What Sega, and Traveler's Tales, and modern demoscene coders realized is that, if every time they changed a palette color, they could produce a 15-bit color pixel on the screen, then they could write loops that would do this over and over again and cover the entire screen in 15-bit color pixels, producing direct color images with a color palette of over 4,000! Way, way, WAY beyond the master palette of 512 the Genesis can produce, and the 61 it normally is only able to display. More importantly, these images can be treated as direct color framebuffers -- where each pixel can be directly accessed and drawn. Old video games systems prior to around the time things like the 32X and 3DO and Jaguar started appearing, used Tiles and cel structures to quantize screen space and data, making it possible to full entire screens with images with only a little bit of memory, at the expense of losing fine pixel granularity. Which is a long way of saying that the Sega Genesis was never designed to let you select and draw single pixels on screen. Instead, the smallest element you are supposed to be able to draw with is an 8x8 tile, which either has to be aligned to a grid (and thus can only move left, right, up, and down in 8 pixel steps), or as one of 20 hardware sprites that can be drawn in any location, but don't provide nearly enough to fill an entire screen. Being able to directly plot pixels is what allows systems to do 3D plotting, forr example.

So this blast processing ability was super, super useful. It gave the Genesis a drawing palette that was 63 times bigger than normal, and let it manipulate the screen directly in enviable ways that wouldn't become the norm for an entire console generation later. Sega knew about it, and knew it was actually a potentially killer technique, but it was never used in a single commercial game. Why? Because the entire method requires extremely strict timing, and the Genesis provides no method of syncing the CPU to the VDP. You have to understand that the CPU is a microprocessor, and the VDP is also a microprocessor, and they run entirely independent of each other. It's almost like they are two separate computers, sitting on a single motherboard, each with it's own RAM and timing. The ports I described earlier are areas of shared ram between the CPU and VDP that let them communicate, but they are asynchronous. The CPU sends data through the port, and then when the VDP is ready, it reads it, and vice versa. It's normally up to the programmer to make sure the read and writes don't collide, and that is done by scheduling these commands liberally, with expectations of large gaps between when one CPU writes and one reads. As such, any methods of synchronization between the two chips is vague. This is compounded because there are very slight timing variations between different models of Sega Genesis. And, unlike other retro systems, the Genesis didn't provide any syncing commands for video horizontal video signals. By contrast, consoles like the C64 and Atari 8-bit computers could provide commands that would make a CPU wait until it got a signal from the television to begin drawing a horizontal line.

These variations in timing means that Traveler's Tales, for example, began experimenting with manual calibration -- letting users use the controller d-pad to set values that slightly altered timing until the picture came in correctly. But they decided that was too cumbersome, and it was essentially impossible to write an application that could discern for itself where to start drawing, to be able to sync up the DMA routines. If your timing is off, what happens is that the image jitters left and right per scanline, and these jitters can be huge depending on how off the timing is. Sometimes like 20 pixels off. That ruins the picture.

Well, in 2012, as mentioned earlier, 3 long time demoscene developers finally figured out a method to sync CPU instructions to VDP instructions based off of VBlank. The entire process of figuring out the precise steps to sync any Megadrive this way is fascinating. Firstly, understand how the Megadrive itself keeps timing of its chips. There is a master clock that cycles at 53.693175 MHz on every megadrive. This value was chosen because it times with the other chips in whole values:

53.693175 / 15 = 3.57 MHz, the speed of the Z80

53.693175 / 7 = 7.67 MHz, the speed of the 68000 cpu

53.693175/10 = 5.36 MHz

This last figure is the speed of a clock inside the VDP called the Pixel Clock. This Pixel Clock controls the master timing for the entire VDP chip. Every tick of the Pixel Clock, a second counter called the Serial Counter is ticked twice. Thus, for every pixel that is processed by the VDP, the serial clock ticks twice. This was discovered by Nemesis using a logic sniffer and lots and lots of notes:

These are his timing notes from sniffing the bus to the VDP over a full frame, noting every VDP operation takes 4 serial clock ticks. The actual logic is very complex, because VDP operations are nested, and actually take 7 serial clock ticks to execute, but for the purposes of timing, only the start of each operation is important, and the first tick of a new operation always happens on the 4th tick of the last operation, making 2 operations work in succession for the final 3 ticks of each cycle. This was discovered by Nemesis mapping the timing access patterns like so:

With a hard reference of how long operations took in the VDP relative to the master clock, a formula of specific commands done in a precise order was discovered that could narrow down execution to precise synchronization. The first step in the process is to give the command to the Genesis CPU to wait for vblank from the television. Despite not having fine sync controls, the Genesis CPU can tell when Vblank occurs on the television. However, it does so vaguely, and gives an error range of 12 or so pixels. Meaning the Genesis can think VBlank begins on any pixel clock count from 0-12. That's a large range that can induce jitter.

The next step in the process is to fill up a number of First-In, First-Out memory queue slots the VDP has. To speed up operations and make scheduling more easy, the VDP doesn't just let you write one command to it at a time, but rather you can buffer 13 commands in a field of memory that is FIFO, and the VDP will execute them in order sequentially, popping them off the queue. The timing of this operation, with the timing of the VDP vs the timing of the master clock just so happens to evoke an effect similar to the Collatz Conjecture. The Collatz Conjecture is an algorithm with a special ratio that, when repeated over any integer N, will eventually devolve into a finite pattern of 4, 2, 1. The exact ratio of the VDP timing does not produce a finite pattern, but it does eventually devolve into a 2, 1, 2, 1, 2, 1, 2, 1 alignment pattern over several operations (and the ratio eventually desyncs after too many iterations). Thus, if you fill the FIFO memory with enough commands, it'll devolve into that alignment pattern, and the amount of memory the FIFO can hold is too low to desync. So after these two steps, we are now within a 2 pixel clock cycle alignment of our goal.

The final step of the puzzle relates to refresh cycle slots. If you refer to this image:

You see that on Serial clock count 156, it performs once a "refresh cycle." This is because the Sega Genesis uses dynamic ram for its color ram rather than static ram. Dynamic Ram is cheaper than static ram, but it requires a jolt of electricity every few moments to keep the data inside of it alive, vs static ram which keeps the data alive until power is cut entirely. These "refresh cycle" slots are moments when the genesis sends some electricity to the DRAM. This is an extremely high priority process, taking priority over every other command. If you perform a DMA within this Refresh Cycle, it'll wait until a 2 serial clock boundry is hit to perform it because it needs to refresh DRAM, which will eliminate the potential erroneous 2 pixel clock cycle offset (if it exists) that is caused by filling the FIFO method. This is because the math works out to the DMA command is able to be either 1 or 2 serial clock tick bound given our error, meaning those ticks can happen over any 2 serial clock tick moment. But the Refresh Cycle takes a full pixel clock tick, which itself works out to 2 serial clock ticks. Regardless of what our DMA command's alignment is - 1 serial clock tick or 2 - it won't execute until definitely 2 serial clock ticks go by because the Refresh Cycle needs to occur. You have to carefully time your DMA command from your CPU after you fill the FIFO queue to wait specific amount of time to hit this reset cycle reliably, however, and it's been worked out that a specific number of NOP commands (no operation) called by the CPU will align perfectly to the reset cycle. This is currently where I'm stuck, I've been trying to decypher the math to figure out how many NOP commands align to the reset cycle. Chilly Willy, Nemesis, and Oerg88 know the number, of course, but part of the fun is working out the math from the timing on your own. I know the number of NOP commands is circular , occuring again X number of ticks again and again. So if the number of NOP commands is, say, 5, and the cycle is 20, then it'd occur at 5, 25, 45, 65, etc. But again, I haven't worked out the cycle.

All this works out, however, to perfectly timing the VDP to the CPU to the Television screen, without any external input from the player. Once that's done, the effect is unlocked. The Megadrive doing blast processing is really awesome, but sort of useless because it halts the 68000 CPU, you can't do anything while it's drawing to the screen because the CPU is being used to blast the pixels to the VDP. So it's mainly good for static images on the Genesis.

BUT with a Sega CD attached, the proposition becomes entirely different. Since the Sega CD has it's own 68000 CPU that operates independently, it can use the Genesis 68000 CPU as a blast processor to draw a direct color 4096 color image to the screen, while it's own CPU handles the game logic, music, and everything else. This is how things like the Sega CD port of Wolfenstein 3D is done.

There are drawbacks, however. Because there is a refresh cycle of DRAM every several "cels", this manifests on screen by a vertical row of pixels being twice as fat. These vertical rows happen 5 times per frame, so there are 5 rows of "stretched" pixels across the screen. This can be hidden by carefully managing your image output, or by use of noise generation to hide the artifact. Another draw back is that blast processing halves the horizontal resolution, so you're working at a 160x200 resolution. Actually, the effect draws off screen and if you have an HDTV which does not hide overscan, you can actually output a widescreen image from the genesis this way at 180x200. Despite these draw backs, Blast Processing is a super useful video mode, especially when it can be enabled and disabled at will. It's especially great for large, screen filling colorful images.

Blast processing is absolutely amazing stuff. It's a weird instance where Sega knew about it, advertised the hell out of the feature, but totally didn't get it and never once used it. But it WASN'T marketing fluff, and it really could let the Genesis (and especially Sega CD) do some honest to god amazing stuff for the hardware.

This effect was thought impossible to achieve with sync by Nemesis originally. It was Oreg88 who stumbled upon the repeated pattern the VDP timing of the FIFO queue would devolve into after repeated operations, and Chilly Willy with Oreg who figured out the exact number of NOPs needed to sync everything. Really, really great cooperative teamwork there.

You can see this trick all over Overdrive 2 by Titan:

And a quick pic for those who don't want to watch a video:

Being technically proficient enough to abuse hardware, while still being artistic enough to take advantage of this abuse is something really to behold.

Cokie Bear

Attempted to circumvent ban with alt account

I think it's easier to draw a stick man and a walking/jumping animation than it is to program that stick man to walk and jump over obstacles by itself. I think that based on my childhood where Inwould make my own flick book animations and my lack of programming AI.

That's not me saying animation is easier, but just an example of what a weird question this is to ask. Anything can be hard at different levels. The answer depends entirely on specific context and thus will change depending on the context.

You may as well be asking "what's harder about school: Maths or Geography". The answer is going to be different depending on the person answering.

Last edited: Jul 19, 2018

No. But animation even at a beginner level can be a difficult affair for some people.

What a strange thing to say

High budget and very public games prioritise graphics and animation, so I guess it's extra competitive? But aside from that..

there is no easy job in game development.

And there you have it.

As I programmer I'd say game design by far is the hardest. At least if you are trying to do anything more than copy already existing, successful gameplay. Take the witness for example, there's crazy amounts of design in there that had to be invented to make the game.

99% of games coming out today feature woefully illiterate animations but are still playable from programming standpoint. This is a proof that animating maybe is not harder but that proper animator is harder to find.

Most of the developers are failing as early as literally the first second of gameplay where you just push the stick forward because they can't even do the walking animations right, let alone things several levels beyond that.

If the question you're asking is "is it the most time consuming?" then:

For hand drawn 2D games, definitely. You're essentially redrawing each asset frame by frame (which is why Cuphead was so ambitious, and why so many film studios abandoned that style in the late-90's.)

For 3D I would say asset creation is probably the most time consuming element, but whether animation is even more so depends largely on the type of animation - hand animated 3D is really only somewhat faster then hand drawn when it comes down to it, mocap can be faster still but usually requires a lot of clean-up time. Games that rely largely on walkcycles and generic animations are less time consuming then games with tons of unique animations for each character alongside hand animated cut-scenes. You can pretty much gauge how time consuming each element is for each game by looking at the composition of the team.

As for "difficulty" - that's impossible to say. Each person will say that their responsibility was the most difficult, in different ways.

Ascenion

Prophet of Truth - One Winged Slayer

Uhhhhhh knowing what I do about media production....I'd say the music is the most difficult. It requires the most raw talent with art/concept being the 2nd most difficult. Music for video games is particularly difficult according to some friends due to the complexity of gameplay involved.

Biased as fuck but art is. Art all the way.

I'm an animator, I work in television so not games, but I have done freelance mocap work for games. I wouldn't say any one practice of 3D art is more challenging than an other. Different peoples minds will wrap around different things easier.

.ini file maintenance probably.

Yes. Yes it is.

Not an Animator for games at all.... *cough*

But seriously, games are hard in general. Every part of it takes a person with a very specific skill set. Animation is certainly one of the most nebulous things in game development, in that people have very different opinions on what is good and what works, and its often hard striking a balance between gameplay and how it looks in general, but every field has its own challenges.

They are both very challenging for different reasons. I think comparing like this is incredibly silly.

It's all relative. Different people have expertise in different areas. Some have skills in programming, others have skills in animation.