• 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
thanous-m

game development in the 80s

14 posts in this topic

what did huge game companies like Nintendo or Sega or Atari or even those awful companies like ljn (shivers) or great companies like konami use to program there games in the 80s?

0

Share this post


Link to post
Share on other sites
what about for the original gameboy or the turbo grafx 16? it doesn't say you can use 6502 it just says BBC MicroAtari 2600Commodore 64Apple II, and the Nintendo Entertainment System.

 

The gameboy used the z80, another very popular 8 bit processor.

I don't know what the TurboGraphics used.

 

One should not forget that these game devices also came with a custom GPU that let you do things like sprites efficiently without much CPU load.

It was nothing like a modern GPU though.

 

And also, that assembler for an 8 bit processor is very much easier to handle then modern asm. You can fit the entire instruction set on a single page, and it was not uncommon to know the hex opcodes for all of them by heart.

2

Share this post


Link to post
Share on other sites
And also, that assembler for an 8 bit processor is very much easier to handle then modern asm. You can fit the entire instruction set on a single page, and it was not uncommon to know the hex opcodes for all of them by heart.

 

True. I used to program the 6502 by hex code. Still remember a few instructions. That was fun, but a waste of memory today.

 

Only way to update the code was to replace buggy code with a jump to the first free memory, add corrected instructions, and then a jump back again. That was true spaghetti programming. My first game was a Asteroid look-a-like, but using character graphics.

 

I remember the day I could afford an upgrade of the RAM from 4K to 8K.

 

800px-Ohio_Scientific_Superboard.jpg

 

Wow, old memories coming back. I implemented my first programming language at that time, being a Lisp-look-a-like (implemented using the string functions in the built-in Basic). Didn't work very well, due to a memory management in the Basic interpreter that would eventually hang. I complained to the retailer, and they said it was "normal behavior".

 

It was possible to save the binary code to a tape recorder, but I don't remember the details.

2

Share this post


Link to post
Share on other sites

Even C was almost unheard of until the Playstation/Saturn/N64 -- There was some on the Genesis*, but it was the only early machine that wasn't too register-starved, or otherwise limited, for contemporary compilers to be useful. Even with the option to use C, many devs clung to ASM for long after.

 

*The Genesis had a luxurious 16 registers in its 68000 CPU, the z80 systems like the Gameboy or master system had a workable 8, but word size, memory segmentation, and lack of memory was still a serious hurdle.

0

Share this post


Link to post
Share on other sites

They book I was thinking of is Core Techniques and Algorithms in Game Programming by Daniel Sanchez-Crespo Dalmau.

 

Looking back over it he just spends some time in the early chapters chatting about the chronology of game development. Most of the book after that ends up begin about 3D graphics stuff, though he does talk about a lot of different things on the way.

0

Share this post


Link to post
Share on other sites
And also, that assembler for an 8 bit processor is very much easier to handle then modern asm. You can fit the entire instruction set on a single page, and it was not uncommon to know the hex opcodes for all of them by heart.

 

True. I used to program the 6502 by hex code. Still remember a few instructions. That was fun, but a waste of memory today.

 

Only way to update the code was to replace buggy code with a jump to the first free memory, add corrected instructions, and then a jump back again. That was true spaghetti programming. My first game was a Asteroid look-a-like, but using character graphics.

 

I remember the day I could afford an upgrade of the RAM from 4K to 8K.

 

800px-Ohio_Scientific_Superboard.jpg

 

Wow, old memories coming back. I implemented my first programming language at that time, being a Lisp-look-a-like (implemented using the string functions in the built-in Basic). Didn't work very well, due to a memory management in the Basic interpreter that would eventually hang. I complained to the retailer, and they said it was "normal behavior".

 

It was possible to save the binary code to a tape recorder, but I don't remember the details.

 

I'd recognise that computer anywhere - Ohio Superboard or UK101 (in the UK) a computer sold in kit form in the 70s - My mum convinced my dad to buy one :) I never programmed it beyond basic but got into 6502 once she convinced my dad to buy an Acorn BBC-B. Nice job with the case! We actually bought a case to go around it but my dad added a PSU that sat on top and got so hot it required a massive fan which didn't have a cage and affected the video output making it go wavy.

 

I'm not sure if other platforms did this but when Acorn implemented their version of the Basic language they made it incredibly easy to drop in and out of 6502 assembler within the basic program - IIRC it was as simple as putting a control code and then getting on with using the values you were passing in and out.

 

I think that was a big step in getting early coders into assembler easily on the BBC.

 

Personally my first steps in 6502 were disassembling the code for a game until I figured out how the game was drawing the sprites. Due to the fact that computers only had video memory and no buffer to draw a sprite that didn't destroy the background you first had to save the background onto a stack. Draw the sprites, calculate new positions, then draw the background back onto the sprites by pulling off the stack (to preserve any multiple overwrites with other sprites), push the new location backgrounds onto the stack - repeat.

 

That's about as much as I can remember!

0

Share this post


Link to post
Share on other sites

[quote name='skuzzbag' timestamp='1356603377' post='5014662']
Nice job with the case!
[/quote]

I am afraid the case isn't mine. I got the picture of the board from Wikipedia, as I don't have any picture remaining of my own board.

0

Share this post


Link to post
Share on other sites
Even C was almost unheard of until the Playstation/Saturn/N64 -- There was some on the Genesis*, but it was the only early machine that wasn't too register-starved, or otherwise limited, for contemporary compilers to be useful. Even with the option to use C, many devs clung to ASM for long after.

 

*The Genesis had a luxurious 16 registers in its 68000 CPU, the z80 systems like the Gameboy or master system had a workable 8, but word size, memory segmentation, and lack of memory was still a serious hurdle.

 

Even in Genesis' case C was generally ignored in favor of assembly simply because of how slow the generated code would be back then (optimizers simply weren't all that good). Also there were some performance tricks that were easier to do in assembly than in C (like abusing the MOVEP instruction to create a list of commands for the video hardware).

 

It'd be more interesting to know what kind of hardware they used to develop games.

0

Share this post


Link to post
Share on other sites

I have read stories about how they programmed Elite and it was very fascinating. I mean they really took code beyond the capabilities of the platform, which is really incredible. If I remember correctly, they even made multiply and division calculates with natural logarithms to save some memory. One can only wonder how much we could save resources on modern platforms if the code would be that optimized.

0

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