Well, long ago the first thing people wrote was often a sprite editor, which tagged along with them from project to project gaining features over time. Using art packages came a lot later.

In the days before that, you were into designing stuff on graph paper and doing sums to get the magic numbers for SYMBOL statements...

Don't forget that in general, games often didn't use that many sprites and images; With memory around 64k, the screen could occupy a quarter of that. You need some space for level data, some for code, the stack... You might only have a total of 10k for sprites. Call it 20,000 pixels. For a decent sized sprite of 256 pixels, you don't get very many of them.

This is why a lot of 8-bit games "stretch" sprites, usually vertically by doubling pixel rows (because it was easier) to get more use out of the same data.

Games were hardly ever art-constrained; they were almost always limited by RAM and CPU speed.



If you really want to have a go at working in that environment, there's a programme called "SpritePad" which from the screenshots at http://www.coder.myby.co.uk/spritepad.htm looks not entirely unlike the sort of editors people used.

Back in the Commodore 64 days we would design the sprites on graph paper and then punch in the data statements.

Later we would do sprite editors and use existing drawing packages to do backdrops etc. (Koalapaint for instance)

On the Amiga we used the kickass Deluxe Paint package. Pro motion is definately it's successor in more than one way. Many of the old DP shortcuts even work! ;)

On the PC again Deluxe Paint and own font/sprite editors.

Nowadays it's photoshop mostly. We still use Pro motion for GBA and similar stuff. Even for cellphones.

mtPaint's a good free pixel-art solution. It has some options for dithering and simple animating that might help you out.

You can use almost any graphical application to create game sprites. All you need is a simple application that can change the pixel colors, some good knowledge about sprites and a little talent. I've seen on many forums people using windows paint to create cool sprites. Photoshop or gimp are as good as paint because you'll use only a limited set features.

Once you have decided to a specific application to use you could read some sprite tutorials. The 8/4/16 bit sprites were just a limitation of the existing game hardware. Those days you could have such limitation on mobiles. In order to have that look you just have to use less colors for creating your sprites. But you have to take in consideration that sprite creation is a job for an artist. You need to exercise a lot for getting some nice sprites. If you are a developer and you just want to use them in your games you can look for some free sprites.

Like back in the genesis, nes, snes days. What did Devolepers use to create sprites? I heard that you got to program it and stuff. Do you really have to create it like that without seeing it? Also what is a good simple program to use related to what game developers used to create 2d sprites that looks like it's from a 8 bit game, 4 bit game or 16 bit game?

Sorry If I sounded real dumb. I'm a kid with a big future dream and doing the best I can to learn all I need to know.

Thank you

There were no 4-bit games, unless you mean to suggest the Atari 2600 is 4-bits which is a myth of course.

As for how they did sprites, it depends what era you're talking about. In the discrete logic (pre-microprocessor) days all graphics were actually drawn by the circuitry of the game. These games had no game code, and all behavior (including graphics) were created by what's called a "state machine". A specialize grouping of circuits that reacted the various input stimuli to set up various states overall. Each aspect had a control circuit. In the case of PONG for instance, you had a circuit that controlled the hoizontal motion/drawing of a paddle, another circuit for the vertical motion of the ball, a flip-flop circuit that tracked which direction the ball was going and if changed would changed how the relevant circuits interacted and so on. And each of these had to be synced to timer circuits or IC's. I.E. the width of the paddle you see on the scree was defined by a length of time rather than pixels. The previous game, Computer Space, actually used a diode matrix circuit to create it's "sprites". For convenience of repair, the diodes were collectively laid out on the board in the shape of the actual object they represented (see upper left corner of the PCB):



That changed in 1974 when Atari/Kee released Tank, the first game to use ROMs to store graphic data. Once microprocessors were added to arcade games, you then had everything that was needed to turn these in to computer structures complete with bitmaped graphics and the ability to program games and store said programs. Each game PCB was still custom designed as most of it's capabilities were still hardware based, leading to in effect a "new" computer for every game. By the late 70's they of course got smarter and started using a custom hardware pcb for a series of games, creating an arcade "platform". In relation to your question, during this time (which is also the time microprocessor driven home consoles were introduced) you had graphics literally planned out ahead of time on graphing paper. Each box would represent the pixel, which it would then be the job of the programmer to translate in to the actual display data for the custom platform it was running on.

Here's an example of said procedure used in both the Atari 2600, Atari 5200, Atar Computers (400/800 etc.) and typical Atari arcade hardware at the time:

http://www.atariarch...gd/chapter5.php


In the case of arcade game development, you usually had a compiler running on a mainframe you connected to through a terminal (and usually a CPU simulator on there as well to test base compiled code). You'd then burn a rom of the compiled code and go and plug it in to the test hardware to test. It was then you'd actually get to see your graphics, game play etc. If it was wrong or you needed to make changes, you'd go back to the mainframe and make code changes and repeat the process. In console development, you'd be lucky to have a burner in the same room. Here's an example of a typical setup of the time period, this one from the offices of GCC (designers of Ms. Pac-Man, Food Fight, and Quantum to name a few):




Click here for an article that captures the typical development process by the early 80's for console/computer games.


It was the early 80's really when the industry first started using actual artists to design said graphics (or "sprites"). And with the arise of these types of non-coder job positions came the need for more specialized graphics programs to help in direct computer based sprite design, as some of the other posters mentioned. In arcade and big budget software houses, these generally included access to drawing tablets as well.

It wasn't until the mid through late 80's when mouse driven computer platforms became more prevalent that you had the rise of more standard general drawing packages that could be used to generate graphics that more freeform graphics/sprite generation arose (depending on the intended platform's capabilities of course, sometimes you still had to plan for a system's sprite generation limitations).


Marty