How were older games made, exactly? I'm thinking specifically games before the 6th gen.
I have a fair understanding of how modern games are made, but how did they do it back in the day? Like, let's say you had to create a level in Super Mario Bros, did they hand-code the location of every single tile / sprite, or did they have a GUI of some kind to make it easier?
I'd love to see a documentary of some kind that explains the process.
Here's a video that explains how graphics were done in the 8-bit era.
https://www.youtube.com/watch?v=Tfh0ytz8S0k
>>3284726
that does not answer the question OP asked
For things very game specific (like levels or some custom formats) one of the coders used to program tool software. Tools from previous projects could sometimes be used (if the expected output was more or less similar)
>>3284712
>Like, let's say you had to create a level in Super Mario Bros, did they hand-code the location of every single tile / sprite, or did they have a GUI of some kind to make it easier?
They would either do it by hand or roll their own software to generate computer readable data for them. Or use graph paper. IIRC Mario was done primarily on graph paper.
Basically they make some data structure to contain level data (or sprites or whatever) and then either punch in all the values by hand or do it automatically somehow. In the old days doing it by hand frequently meant you could use tricks to compress the data more than you could have otherwise. Now you have enough wiggle room that doing things by hand is typically going to be worse.
There is a little insight into game development for the 5th generation in the Conker's Bad Fury Directors Commentary video series on youtube. Check those out if you're interested. A lot of it is just drunk guys talking shit, but there's a few really good pieces of information and game history.
>>3284763
>Conker's Bad Fury
Holy shit that could not have been a worse typo. I meant Conker's Bad Fur Day.
>I have a fair understanding of how modern games are made
Then why are you asking you fucking retard? They were made the same way but with simpler tools.
>did they hand-code the location of every single tile
Well, you ARE literally retarded.
>>3284768
Well one thing I can tell you is that sometimes to make static 2d images, developers used fonts, and created characters to line up and make an image. It used less memory for some reason. I can't remember where I learned that.
>>3284775
That's how tiles work, games in old computers used to write its graphics into the computer's font then just "text" the graphics. The memory savings come from needing just a reference to an already loaded character/tile (instead of the full graphic) for each time you want it repeated.
>>3284792
is there any tile based image format out there? Whenever we share tiled maps here it's always fuck huge PNG files, which completely disguise the "real size" of these maps
>>3284803
It really depends on the format chosen by the developers and the hardware it's gonna run on. The PNGs you download are "recreations" of the graphics of the game put in a PNG file so you can open it with standard graphics programs. In order to know the size they use on the original hardware (at least the size of the stored data) you would have to hack the ROM I suppose (although a lot of games are well documented today).
Usually the size of the graphics depends mostly of the bits used per pixel and how many pixels there are.
All this applies to graphic data whichever is that used for:tiles, sprites, fonts...
Tiles may be grouped together in bundles to form a tilemap, and levels/images made of tiles usually involve some array with references to a tilemap.
>>3284824
Slight misunderstanding, I do not mean the graphics format used in games. That's often custom and of course tile based. I mean a common widely used "consumer" file format, like png, gif or jpg, but that's internally based on tiles, allowing to store large images the same way a tile map works, as a bunch of tiles and a grid of references to them. Stuff like PNG is painfully inefficient to represent maps of Zelda, Metroid and the likes for browsers and viewers. But it's apparently the "best" we have.
>>3284827
Some programs like tiled have their own format open and documented and many engines and game authoring tools import/export to/from it. I don't know if it's used for what you say but I suppose it could. That's all that comes to mind.
>>3284740
Butt... he wanted to shill......
>>3284712
Can't be bothered to look for it, but one of the Super Mario Maker trailers (I think the announcement trailer) had Shigeru Miyamoto mention that they drew the levels on grid paper
>>3285306
that's the first step. Then how is it digitized?
>>3285325
Using slaves and interns
>>3285331
and they do what?
>>3285335
Well, they have a computer, and there a program, and they use the program like you would use paint, but it uses tiles instead of a color pallete.
>>3285337
if it was that comfortable, why do the paper step?
It's a little difficult to explain without images, but I'll try.
First, the coders had a table that listed what bytes corresponded to what tiles. In a Super Mario Bros. level, for example:
A1 = "?" block
A2 = brown block (spent)
A3 = empty block
A4 = sphere
A5 = floor tile 1 (green)
A6 = floor tile 2 (brown)
A7 = sky/transparent tile
The stages were built either by hand, or by using a tool (which the programmers made themselves, there weren't any standards back then) that showed them the complete stage, and they could just swap the tiles around to build the whole thing. The program took care of the table I talked about.
So, in the compiled ROM, a stage would look like this:
A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7
A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7
A7 A7 A7 A1 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7 A7
A5 A5 A5 A5 A5 A6 A5 A5 A5 A5 A5 A5 A5 A5 A5 A6
If you can't picture it on your mind, it's two strips of "sky", with a "?" block in its midst, and a strip of floor tiles, mixing green and brown.
I could show you an image with the composition of a game over screen, if you liked. It will take some time, but the process is mostly the same.
>>3285338
Putting your ideas on paper is a staple of any work since forever. It may seem redundant nowadays when you have computers, but trust me, it works wonders. Try once, and you'll see your ideas flow more easily when you put them on paper.
>>3285338
Because they are not amateurs, everything must be (in theory) designed first hand. And once you have the documents, you would lend that information to the programmer.
Think that computers back in the day were slow and had low memory, and people were more used to work with papers. That trend has died slowly.
i know sega had a touchscreen system they used for graphics
>>3285340
>The stages were built either by hand, or by using a tool (which the programmers made themselves, there weren't any standards back then) that showed them the complete stage, and they could just swap the tiles around to build the whole thing. The program took care of the table I talked about.
This is the important step you and anons before you were handwaving away. What were the tools like? Are there screenshots or have old devs talked about them somewhere?
>>3285342
>It may seem redundant nowadays when you have computers, but trust me, it works wonders
Get that condescending tone outta here.
>>3285343
To both of you, the reason I asked for the paper step is >>3285337
>they use the program like you would use paint
That shit is high end comfort, where you can instantly brainstorm and move tiles much more efficient than you ever could on paper. And the output of these programs would naturally be an include file or two for the programmers. If they really had a tool this powerful, they wouldn't need the inefficient paper step, and they wouldn't need to tell the programmers anything in paper form.
In other words, I was questioning the claim that they had this miracle program, not the usage of paper (>>3285306 mentioned they used paper, after all)
>>3285347
They were tools made specifically for the game, because there were no standards back then. An analogy is that there was no program like Blender or Maya to model 3D stuff like we have today, every game needed a personalized tool.
I couldn't find any level editor for old games, but I've found a few music development kit. Like this one:
http://www.romhacking.net/utilities/733/
It was used in 186 Sega Genesis games and some 32X games (so, better than the stuff for the NES, which was per-game basis). It still works in Windows XP.
![6837935827_fd58e6d95e[1].jpg](https://i.imgur.com/K56G6sg.jpg "6837935827_fd58e6d95e[1].jpg")
>>3285347
As far as i cant tell, no. I suppose back in the day there was no interest in those subjects.
>>3285358
There are a lot of things going on in these design docs
>>3285361
>They were tools made specifically for the game
We covered that already. What did they look like? What interface did they have? What hoops did designers have to jump through? The question is not a general how, but a specific one. We know for games like Doom or Unreal what editors were in use, but that's likely not representative, and of course neither of them is for 3rd gen graphics.
>stuff for the NES, which was per-game basis
how would you know? The tile format and tilemap formats are defined by the hardware and hence consistent across all games. Would make a lot of sense to develop one tool to rule them all, instead of hacking together something half assed for each new game
>>3285365
thank you. Thank you. THANK YOU. Finally a response fit for this thread. You raise a good point about the level design document containing more than just the tile arrangement. Reminds me immediately of stuff like enemy placement/movement, or moving platforms/objects. You can't encode these things in the tile map, but you sure as hell need them in the final game.
>>3285368
They were made in whatever language the PC-98 used (for even older games), or just plain old DOS. You can search online for devkits for old consoles, and they'll have rather rudimentary tools for editing graphics and making a level.
About the per-game stuff, I don't mean the tile format, but how it was displayed on screen, and how a "stage map" was made. It was because programmers needed something that was tailored specific for their game, something a standard tool wouldn't have. You may not know, but side-scrollers like Mario weren't the norm back then, but single-screen games (when you changed screens, the whole thing changed, and so on). I don't have the document in this computer, but there was an explanation on how the side-scrolling effect on the NES was developed as sort of a hack, and they knew it had a few bugs (you can see this on emulators, on the edges of the screen).
I'll try another analogy: imagine we're programming a game today. I could just get Unity, Unreal Engine 4 or whatever else and program in that. However, my game doesn't need all that from those engine, and there are a few things I want to do that's not possible in those engines. One example is the Fox Engine for the new Metal Gear games. In this case, they wanted an engine where they could port a game to a bunch of platforms in a shorter time, something that, while possible in other engines, would need quite a lot of work. So instead of using a standard engine, they made their own.
Now, imagine we were doing a game back then, and we wanted to have an on-screen transparency effect that was not possible to do with the devkit's standard tools. We programmed our own tools for that.
>>3285347
Well by tools they basically mean a system of shortcuts to do things faster. Instead if hand-coding every single tile, they probably made it easier by writing some program where, if say you wanted a Sky-block positioned to the right of another Sky-block, you would only have to enter in the fact you wanted a Sky-block and that it had to be at position x and y. Then the program would automatically understand what a Sky-block is: what the texture is and located in the files, how to assign it to a position, if it has collision it not, sound effects, what order the graphic gets rendered. Instead of doing all that themselves every time, all they have to put in is Sky-block, x position, y position. If they wanted to do a row of blocks, they could even write a loop that would change the x value one at a time or y value one at a time, while keeping the kind of block and the other value the same, saving even more space and time. All this is what they mean by 'tools'.
Now some even took it further. In Super Mario World, they made a straight-up level creator. A little GUI, like you said. It would basically do everything I just said, but without even having to type any code on a keyboard to make levels.
>>3285358
>Tell me how something works.
>Get that condescending tone outta here.
What a douche. I worked on several games in the 80's. Glad I read the whole thread before sharing detail of how it was done with such a dingus.
Assembly
Ecco the Dolphin was made in C though
Nintendo and some of its second parties used some tool called "Paintbrush" iirc for some games. We don't know how it worked or what it looked like but some ROMs still have debug leftover text about it. Like some JPEGs still have Photoshop metadata
>>3285463
>>3285475
That probably wasn't it.unless you're memeing, if so, good job
>>3285497
not memeing. But it's old enough, and, unlike its successors, called Paintbrush. You never know.
>>3285463
as I recall Comix Zone or Vectorman was made in C as well, the compiler notes are still there in the ROM. Which is extremely impressive considering that they are the games that push the hardware the most.
>>3285524
>the games that push the hardware the most
how so?
>>3285534
How... so?
Did you play either one?
https://www.youtube.com/watch?v=wZZkv6vgiLw
>>3285534
https://www.youtube.com/watch?v=cHah1M6_6nc
>>3285539
I played Comix Zone. And yes, how in particular is this game doing more with the hardware than others?
>>3285542
What Makes The Game Special:Vectorman was obviously Sega’s answer to the Donkey Kong Country series and its pre-rendered, 3D-like graphics. Fortunately, for Sega fans, Vectorman not only looked beaufitul, but also provided some animations that were even more impressive than DKC.
Vectorman’s developers, Blue Sky Software, made use of an impressive new program called “Vector Piece Software”, which allowed the spheres making up Vectorman’s body to be individually animated. This software techinique allowed the Vectorman character to move smoothly and glide in and out of his various transformations.
According to Vectorman’s head developer, Richard Karpp, A large percentage of the levels implemented a creative use of the Genesis’ scrolling backgrounds For example, it was possible to specify a different scroll offset for each horizontal line, which could give a parallax effect. It was used vertically in a few levels as well, even though vertical scrolling was limited to 8 pixel chunks. Some examples for of its uses were for waterfalls and the conveyor belts.
The bosses were all designed around this scrolling technique as well. The first boss that you encounter in the game, which looks like a fighter plane, is actually implemented in the second scrolling playfield, and they used scroll offsets to make it look like it was rotating.
One of the more subtle effects we used was the highlight/shadow mode of the Genesis, which allowed the artists to use more on-screen colors than games typically used. To round out the rest of the graphical effects, you can see dust motes above light fixtures, shimmering arctic waterfalls and some impressive lightning effects. This late Genesis title kept Sega fans interested as Sega prepped the Saturn.
>>3285542
It's because of the comic book panel layout, where you could see into other panels when you were on the edge of one panel. The game needs an extreme amount of graphics to show the "off screen" backgrounds, on top of the active ones, and the comic panels (which can get torn during gameplay). But they also needed a ton of palette tricks to make the active panel stand out more than the inactive one - you can see how some panels change palette as you jump into them, while off-panel graphics stay the same or get darker.
That and sometimes they used raster fx INSIDE a panel (like moving water in the sewers), which must not affect the other panels either.
And those are just the backgrounds; you need graphics and code for the characters and the enemies too.
The game may look simple, but because of the comic book layout, it was one of the most complexly coded games of the time. It's why it glitches up every so often, they just do way more stuff than what the machine could do.
>>3285553
And those are like half the effects that made it into the final game. The prototype roms had things like full-screen animated cutscenes, a lot of them 3d cause they could rotate the orbs around easily. There was a giant running Vectorman and I think a spaceship launch in there.
it also has just a shit load of detailed sprite work, on top of the vectorised animations, and the insane raster fx background tricks.
To this day I still don't understand how the fucking title screen does all those effects.
>>3284763
It's hard to imagine how they achieved this level of graphics on the N64
>>3285504
I remember it wasn't explicitly called "Paintbrush" though, but I can't confirm it right now. I looked into Sutte Hakkun though and apparently it's graphic banks have a header like this.
>>3285365
I think these design graph paper images are beautiful.
>>3285365
What's the source for this pic?
>>3285306
>>3285325
Grid paper was used because all graphics on early consoles consisted of sprites, which consisted of fixed size tiles, which consisted of fixed size pixels.
So it was much simpler to just draw everything on a grid. It allowed you to easily design around things like how many tiles you are allowed to use, how many tiles a graphic used, or to make a graphic take the best use of the amount of tiles you have.
Actual pixel art was often drawn on the actual computers though, simply because it was faster and more convenient.
God, reading this thread is like listening to those annoying hyper-curious 5yos questioning their parents about topics that far exceed the comprehension of their 5yo minds, and following up each of the parent's carefully composed and dumbeddown responses with another question.
"How did they do that?"
"Yes, but how did they do that?"
"Yes, but how?"
Fuck off and do some research yourself, OP.
>>3285524
>as I recall Comix Zone or Vectorman was made in C as well
I don't think those games were entirely written in C.
https://youtu.be/-M8RIc6Ek0Q?t=4m36s
Comix Zone and Vectorman probably had a lot of assembly for those impressive raster effects.
I think most just used an old version of Unity.
>>3285753
I pity your kids.
Hopefully you don't have any.
>>3285830
RPG Maker 95 was the shit.
>>3284712
It depends. Making custom map making and graphic software wouldn't be hard or you could just do it all on grid paper and type in the hex values in a text file which might be a better work flow
>>3285524
>as I recall Comix Zone or Vectorman was made in C as well
No way, Sonic Spinball was coded in C and that's why it's sluggish. High level languages were to slow to do most things till 32-bit systems
>>3285753
A 5 year old is less annoying and at least listens to and learns from what you say.
>>3285740
I remember a little back an anon posted production sketches of some fighting game. The cool thing was, the grid on the paper was stretched, to account for the non-square pixels of the target system. So the artist could draw freely and the digitizer would get the right proportions
>>3286282
I listened. People tiptoed around the actual subject, and the short exchange about the graphing workflow was handling what seemed to be a contradiction.
Responses on here tend to be very shallow. Maybe anon can't be bothered to write more, but as a result, it makes a thread useless like many others. Actually coercing some answers out of people, with specifics, got the thread going. It's a shame that this leads to whiners like you disrupting it.
You got a thread topic specific to /vr/, that's actually rare, so you complain to make it go away and get back to your daily scheduled top 10 postings and console wars. Doesn't strike me as very useful
>>3286571
No one tiptoed. You just didn't understand what they were saying. If you hadn't pretended you knew anything about how games were made people would have spoon fed you more. Instead you just pissed people of by being a retarded sperg. Of course you will argue deny, and justify it all because well, that's what you do.
>>3286618
>>3284712
>did they hand-code the location of every single tile / sprite, or did they have a GUI of some kind to make it easier?
This right there is specifically about the tools involved. OP made clear they know about tiles, sprites and the general data model.
>>3284726
>>3284775
>>3284792
all went to great lengths to describe what OP already knew.
>>3284747
>>3284752
>>3285340
gave generic non-answers (tools, handroll their own)
>>3285331
was a lol-meme answer, but enough to get started, but then >>3285337 dropped the ball with a paint-like equivalent
So, yes, a lot of useless filler, because people seemingly can't be bothered to actually give this topic a thought. Fortunately also a handful of good answers, which I'm thankful for.
At GCC they used a lite-brite for character development
>>3286190
Don't be so sure. The Motorola 68000 has great C compatibility and performance for an old processor. Recommended by Dennis Ritchie himself.
>>3286637
It's not our fault you can't get basic programming concepts into your head. Search online for a SNES devkit, and you'll understand.
>>3286692
snes was not programmed in basic
>>3286692
devkits tend to not contain the custom tools
>>3286693
Well mem'd my friend.
>>3286637
Actually in the OP you made it clear you knew nothing aside from a few meme words you'd seen somewhere on the internet. If you knew how any of that shit works that you claim you already new this thread shouldn't exist.
>>3286783
I'm not OP, just someone else interested in the subject. Knowing the data structure says nothing about the workflow
>>3286792
Worst. Samefag. Ever.
>>3286637
>gave generic non-answers (tools, handroll their own)
Tools aren't a generic answer, it's just the way things were done. Most of them look the same and are really simple, but a lot of the time it was just graph paper. It's just a bunch of scripts.
>>3286992
>it's just the way things were done
That they used tools is a no-brainer. The question was what these tools were capable of, what they looked like, what steps specifically were automated and how automated
>>3284774
>They were made the same way but with simpler tools.
Well yeah that's what I'm asking, I was curious about what tools (if any) they had to work with.
>>3286997
>The question was...
Not it wasn't. The question was
>did they hand-code the location of every single tile / sprite, or did they have a GUI of some kind to make it easier
They used tools is a perfect answer to exactly what was asked.
>>3287006
OP here, I was looking for examples of the tools they used. It should have been easy enough to infer that.
>>3287013
Most of the tools are long gone and never seen again, I guess.
I've written OAM data by hand and it's extremely tiring. There are no tools to automate it, but writing a quick and dirty "OAM assembler with a GUI" wouldn't be too hard if you're a programmer. Same with tilemaps - doing them by hand takes forever, but even a beginner could write a script that converts Tiled's XML files to SNES tilemaps.
>>3287013
Sorry spergboi. Now matter how hard you insist we aren't supposed to read your so called mind.
>>3287397
>>3287402
>>3287403
>>3287397
wow, it almost looks like the left screen is a real-time preview of the sprite being worked on in the context of a level backdrop. Pretty sophisticated shit.
I like the "Digitizer System III". Looks like they really digitized the drawings of the artists directly, using that CAD input thingy in the foreground.
>>3285021
That guy isn't shilling in this thread retard. He has like 280,000 subs and that video has 2,300,000 plays.
>>3287013
Jesus christ you are such a smug faggot.
>>3288354
>i don't know the meaning of the word shill
Then look it up sport
>>3285569
By lagging like crazy.
Wasn't the Color Dreams NES devkit leaked at one point?
>>3288423
>there's a wiki article that somebody else wrote that would answer your questions but I better not link to it because it would be shilling for whomever wrote the article
>>3288761
Damn your stupid. How much spoon feeding do kids like you need?
>>3287013
The big studios like Capcom and Square had sophisticated template/software environment, that's why a lot of the games had the same look/feel about them. With optimized design kits and macros instead of assembly, their workflow was probably more like a modern game studio than some amateur making SNES games today writing assembly ad hoc by hand.
>>3284712
Drawn out on graph paper. Then coded and tested
>>3289726
Your stupid what?
>>3290076
Fuck me. When will the mods just net ban the brazilian nigger babies?
>>3290431
>brazilian
You're the one who sounds ESL.
ITT brazilfags make asses of themselves.
>>3290541
Irony: the post
