- Concepts -
As I see it, there are a few fundamental design points to a prospective engine, most of which are borne of pragmatism: only the game that gets made and played matters. First, the functionality should be easily accessible to game designers, with a minimum of duplication of effort or difficulty learning the environment. It should be accessible by users, in that it should be able to run on the average PC at acceptable rates. It should be technically capable of making games that feel like Sonic, but should be as flexible as reasonably possible instead of reproducing the Genesis engine. It should be extensible and improvable by those with the technical knowhow. And because this ultimately is a hobby, it should be fun to use as well as fun to play. With those principles in mind, my design centers around a few basic components (some or all of which may be combined): the art and music assets, object editor, level constructor, core engine, Internet libraries and publishing, and the online asset server backend. I'll describe each in order and how they interact.
- Art -
Existing art editors of various flexibility and power are sufficiently commonplace that I don't think duplicating that functionality is the best use of time, so PNG/GIFs (JPGs?) will simply be imported, either separately or as spritesheets. I'm not sure whether or not palette cycling techniques are hot stuff in the Sonic community, but palettes are the one "feature" I intend to omit, rather implementing stuff like waterfalls as multiple frames.
Art is at multiple supported scales: 1x Genesis (320x240 equiv), 2x standard (640x480 equiv), and 4x HQ (1280x960 equiv), with maybe a hypothetical 8x for scifi future PCs. It may be necessary to store an additional 2x tier of 4x quality art to keep the game within the reach of low end CPUs. It may also help with memory issues to compute art usage data that's inserted into the level design and used to stream art from the hard drive as required. I imagine that'll become clearer with performance data in hand.
- Components -
Level components fall into the broad categories of level terrain blocks, the objects which exist upon them, and groupings thereof. Terrain blocks historically are exclusively composed of 128x128 or 256x256 tiled chunks, but the reasons for that restriction no longer apply, so here the only restriction is a multiple of 8 1x-res pixels for simplicity of positioning in the level editor. One pane in the editor will allow you to assemble groups of blocks or objects, through which you can effectively create a tiled block or link blocks for ease of positioning or scripting purposes.
Collision maps for objects will probably consist of automatically generated but overridable boxes, while blocks' collision is a collection of lines, each of which can be given a separate state. These are drawn in another pane in the editor, in which you can also create additional collision layers for blocks.
Scripting will be available for objects and flat images. As for object scripting... ultimately it'll boil down to a set of detection and state functionality. It may be preferable for this to be relatively consistent one or more other implementations because it's something people tend not to want to learn. I know E02 does something to this effect but if there's documentation for it it's sufficiently well hidden that I haven't found it (not that I've spent strenuous effort looking). MMF I don't know anything about.
Backgrounds and other interface doodads are comprised of chunks of art that are moved around with a simpler set of scripting. In many cases this will be operationally limited to the camera position, but sometimes it's a bit more complicated, such as the ring/time/score counters. There will be premade scripts for both doodads and objects that can be "plopped in".
Art/music metadata, object designs and scripting, and level design data will all be stored in XML, so that working with the data outside the primary programs can be pretty straightforward.
- Level Editing -
This is technically the simplest part of the lot. Pick out stuff and set it down, try it out, publish it.
- Core -
Well, most stuff is covered in the other sections already. As for platforms, I've done some very basic exploratory coding in OpenGL/SDL with C++. DirectX, XNA and C# also look like pretty attractive options, but come with that MS limit against Macs and Linux.
- Online -
This is probably one of the biggest selling points for the package. All of the components for developing levels will be made available in sets similar to how package managers operate on Linux (in my understanding anyway). There'll be a standard library of objects, art, and blocks from the original Sonic games that have been ported over, and developers will be able to publish their creations online as well. And since I know it's ever so popular, spriter type folk will be able to list their names alongside their creations and get credited on levels that make use of their creations, with the aim of encouraging people to contribute to the service.
Players will be able to download published levels and entire games, for which single player time-attack leaderboards (my specialty) and possibly online netplay will be available.
- Yeah -
Anyway... uh... yeah, that's it. I hope the wall of text hasn't been offputting, and thanks if you read through it. I still left a fair number of things out in the interest of space, heh. If you think you would use this or help to develop it, please let me know. If I end up working on it it'll probably be open source, and it definitely will be if I get partway and lose interest. Ideally separating everything with XML would mean that others can split work on different components, since I know there's quite a few folks out there taking stabs at engines and I doubt I'd ever get through everything myself. And if this works out it isn't necessarily limited to Sonic... Criticism, suggestions, questions very welcome.