• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
yats55

How did/do game developers create 2d sprites? How did it work?

17 posts in this topic

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
0

Share this post


Link to post
Share on other sites
Program it? The only computer art I've heard of being programmed directly was back in the really primitive days of things like Pong. Well, and I think they assign C++ homework of drawing some simple shapes on the screen with programming. But from Atari, Apple II, Commodore 64, NES, original Gameboy, and forward it's all been pixel sprites. The oldest pixel sprites had a limited color palette (in some cases monochrome because the screen they were being displayed on was monochrome) and each pixel had to be a solid color, but that limitation was quickly overcome as improving technology allowed screens to be higher resolution and greater color depth, and more sophisticated graphics file formats were invented. Currently unless you are making a game to be played on a handheld device of some kind there are basically no technological limitations on 2D art - you can even make your art in 3D and take screenshots for frames, or you can make your sprites with vector art then choose whether to use vectors natively or export them as bitmaps of any desired size.

So, is your dream to create modern games that look retro? Or are you wanting to create games that actually run on old hardware? Or what? You can use Gimp or Photoshop just as well for retro sprites as modern ones. You could also use something like MSpaint, or I imagine there are several programs available which make sprites in one specific color palette and format. There are many collections of sprites people have ripped out of actual games available around the internet; while you can't legally use them in a game, they are very helpful to look at as an example. You can get a sprite or animated gif of exactly the style you want to copy and see how many pixel wide and tall it is, and what color palette it's using.
0

Share this post


Link to post
Share on other sites
I remember pixel-arting in my math exercise book 24 years ago. You know, the one with the tiny squares (5mm grid paper). Later switching to 1mm grid because it resembled the screen beter. Colors? Way too advanced back then.
0

Share this post


Link to post
Share on other sites
My big future dream is actually a very bigger thing but creating a system is a part of it.

I wanted to develop a system that is as powerful as ps3 or xbox 360 or more powerful actually I wanted to it to have many many games that range from the most weakest graphics to the pressence.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by bigbadbear9885
My big future dream is actually a very bigger thing but creating a system is a part of it.

I wanted to develop a system that is as powerful as ps3 or xbox 360 or more powerful actually I wanted to it to have many many games that range from the most weakest graphics to the pressence.


With the state of emulation you can achieve this today with a moderate pc setup. Just build it in a shuttle or htpc case to get that console form factor and load it up with emulators. Write a little app to let you browse your games with a joystick, plug it into your tv and play!
0

Share this post


Link to post
Share on other sites
Back in the day a lot of people used DPaint and similar software. Nowadays there are more sophisticated programs that make it a bit easier than artists had back in those days. One application that is used today for sprite work, such as for DS games, is Pro Motion.
0

Share this post


Link to post
Share on other sites
Wow I wasn't aware of Pro Motion, it looks pretty good! Shame there's no free version. :(

I use GraphicsGale, which is free. It can be somewhat buggy, but the lastest version seems fine so far.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
Most of the old videogame pixel art was likely hand coded from graph paper drawings and such. IIRC, NES used 2-bit patterns for 8 by 8 pixel tiles and sprites, which were filtered through a number of limited color palettes for something like a maximum of 16 or 24 colors onscreen at once.

I recall useing a graphics tablet at school on a Apple II. But the software at the time made Windows 3.1 MS-paint look extreamly robust in comparison.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by zer0wolf
Back in the day a lot of people used DPaint and similar software. Nowadays there are more sophisticated programs that make it a bit easier than artists had back in those days. One application that is used today for sprite work, such as for DS games, is Pro Motion.


This.

DeluxePaint was *the* art package back in the day. When you heard that it was programmed in, it works for small/limited numbers of sprites. Remember that images are just data -- doesn't matter if you encode it all in a C array or if you packed a bunch of image files after your executable on the rom using a resource linker or binutils. In fact, the former was usually easier, so most art programs had the option of saving images out as C arrays that you would just include or copy/pase into your code.

ProMotion is an excellent, more-modern alternative to something like DeluxePaint, I've used it for years and its very capable. It's not free, but its reasonably priced (I think $70ish) for software that's for commercial use. I've heard decent things about GraphicsGale (and the free version should be enough for your needs) but I've not used it myself. GrafX2 looks promising also, and there's also the Pixel Image Editor which runs on just about every OS under the sun.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
DeluxePaint. Easy as that. Programming art? No way, not from the early 80's. (maybe in some zx basic, where you "poked" the pixels, but professionally I did never do any art programming).

0

Share this post


Link to post
Share on other sites
[quote name='bigbadbear9885' timestamp='1290637731' post='588702']
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
[/quote]


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):

[img]http://www.computerspacefan.com/30447Computer%20Space%20(19).JPG[/img]

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:

[url="http://www.atariarchives.org/agagd/chapter5.php"]http://www.atariarch...gd/chapter5.php[/url]


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):

[img]http://galleryszy.stevenanne.net/M/050-GCC-PPL-MSC-024.jpg[/img]


Click [url="http://books.google.com/books?id=pGYEAAAAMBAJ&lpg=PT65&dq=video%20game%20graphics%20design&pg=PT63#v=onepage&q=video%20game%20graphics%20design&f=false"]here for an article[/url] that captures the typical development process by the early 80's for console/computer games.


It was [url="http://books.google.com/books?id=zS8EAAAAMBAJ&lpg=PA37&dq=video%20game%20graphics%20design&pg=PA36#v=onepage&q=video%20game%20graphics%20design&f=false"]the early 80's really when the industry first started using actual artists[/url] 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
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0