vintage gaming API

[proteanthread]

if one were to design an API to make it easier to allow game developers to "simulate" or "emulate" a classic game (say Pac Man, Super Mario Bros., Pitfall, or even Zork), what would that API have to include or be able to do?

 

i'm working on an game engine that i'm hoping will make it easier to develop vintage style games (coin-op, PC, or even console); with little effort so that they can easily be ported to other machines (MacOS, iOS, Windows, Linux, current consoles, etc.) and not just emulators.

 

what are your thoughts? what would it need? what would you want to be able to do with it?

[Mirage]

What development tools are you using to create this game engine?

[proteanthread]

C++ for 2 reasons:

1. Portability, plain and simple.

2. Keeping it pure C++ will allow developers to use the development tools they are most comfortable with.

[proteanthread]

In other words, a straight text editor is all that is required for those narcissistic enough.

[rockfistus]

For one, include emulation of all the cool sound chips. SID, Pokey, TIA, ym2151, SPC. There's already source code library's for these out there. Also, presets for the correct resolutions/color palettes for different systems. Just a thought

Edited December 2, 2011 by rockfistus

[proteanthread]

obviously sound will be much easier to simulate than color/graphics; may have to simulate in a window versus full screen to get the proper effect. controllers (either analog/digital) only slightly easier than sound (a simple software-based AD/DA convertor might do the trick).

[Rybags]

Adobe Flash already does this - to an extent.

 

It's available on Windows, Mac OS and various mobile platforms.

 

So, a game which works on one can in theory work on the rest. Of course stuff like resolution, use of 3D and advanced sound stuff might raise compatability issues.

 

Existing emulators like MAME and MESS have drivers for all manner of chipsets and CPUs, "Mess" is a good name really because both emulators can break when drivers and components are updated to support something new.

 

Realistically if you wanted to start afresh and create new "old looking" games on modern hardware, you wouldn't want to be restrictive in what you could do insofar as having constraints in the API or system you created, you'd just leave it up to the programmer e.g. use low resolution, less colour, less audio capabilty etc.

 

A modern day means of running some Infocomm stuff already exists - from the start they created their games to be modular such that each machine just needed it's own variant of the engine and the data relating to the gameplay was portable across systems.

 

For arcade types, there's various "construction sets" around. If you break 2D arcade type games down to the bare constituents, they're all fairly similar, ie - movement due to user input, interaction among objects, movement of enemy objects based on set patterns or position of other objects, objects appearing/disappearing/transitioning based upon other events.

[proteanthread]

problem is I don't like flash for game development and i doubt i'm the only one that feels that way. even java is not my cup-o-joe (no pun intended). i'm not looking at making another emulator outright but more an engine that'll make it easier to mimic the old games: gameplay, sound, graphics, etc. all these modern remakes of our favorite games use modern graphics and sound; but what I am trying to do is allow a programmer to recreate these games (2600 Outlaws or 2600 Donkey Kong for example) without the need of or use of an emulator.

[rockfistus]

And it's a great idea, never let anyone talk you out of it. It could be super awesome.. Matter of fact it sounds like a good Sourceforge project. You know others would get on board.

Edited December 3, 2011 by rockfistus

[proteanthread]

i intend to take it to source forge once i get something going which, hopefully, will be real soon.

[rockfistus]

I'll help if I can. I'm mainly a sound, music n & gfx person, but a jerk of all trades. I've made a few games and remakes in the past

[sack-c0s]

Couldn't you code a tilemap handler (possibly with multiple overlaid maps to allow paralalx scrolling), a 2D sprite system and embed the python/lua interpreter, so graphics can be loaded from a .bmp/.tga/whatever graphics file and the game code is handled by the scripts. That way you wouldn't need anything that wasn't free to write a retro-inspiredgame and you could write your own helper functions as you see fit to handle common games functions, such as collision detection.

[+Gemintronic]

You'd hafta re-invent CHIP8 basically.

http://en.wikipedia.org/wiki/CHIP-8