Sonic and Sega Retro Message Board: Rolken - Viewing Profile - Sonic and Sega Retro Message Board

A lot of Retro projects (including Retro itself) have had trouble with focusing on the wrong things, endless chatter, drama, etc. In the interest of nipping that off in the bud, note that on a project like this...

Democracy is bullshit.

Democracy is the best we've come up with for running a country, but this isn't a country. You can enter or leave any time you want. And since the project is open, if you disagree with the leadership, you can fork it and try to do better, and let the marketplace of ideas decide.

One person (Gen?) or a very small group of people should have absolute authority. The role and responsibility of a good leader, then, is to demonstrate to everyone else that that authority is well-placed; that their judgment, insight, taste and just plain good sense can be trusted. This is a very difficult task to live up to and requires an excess of self-awareness and self-doubt. It's, frankly, a huge pain in the ass, and not for everyone.

The most important role of a leader at Retro is probably to settle debates on details and provide canonical answers before the debate stops being productive. This is where having trustworthy judgment and taste comes in.

“If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.”

The only way to succeed with a volunteer project like this is through mutual trust, respect, and dignity, with a focus on building something beautiful. This can't be forced; it can only be nurtured. Everyone should bear that in mind.

I venture that the primary threat to this project's success right now is a lack of clear direction and progress in that direction. We can talk grand vision all day, but at the end of the day there's no code committed. A lot of ideas have been thrown out there but few have been settled. So I'd like to push things along the path to clarity.


The first step is to establish, in a single sentence, what the guiding purpose of this project is. For example:

Quote

Then, in a paragraph of a few sentences, explain what the vision for fulfilling that purpose will look like from the outside. Another example:

Quote

And then figure which parts of that vision you'll pursue first. For example (this is something I threw out there on IRC):

Quote

Establish a master vision for the project, get consensus, make decisions, chisel them in stone. And then you can focus on the technical details for how to achieve those goals without getting lost in the technical details. Get these few early wins in, start demonstrating progress, start drawing in more developers, and you get a virtuous cycle of compounding success going.

Any thoughts or suggestions along these lines?

edit: also worth noting that I have no idea what the plans are for an IDE, or if an IDE is even the plan, so my examples are definitely not intended to be canonical.

Is anyone working on

- interesting projects
- with concrete vision and purpose
- making measured and measurable progress
- in open development (not a source snapshot sent out to die)
- that welcome contributions
- and focus on building cool stuff (not bikeshedding)
- for modern platforms

or is everyone here just playing around?

I've been mulling over engine design for awhile. By my reckoning, the existing engines have severe flaws, as made most evident by that nobody uses them; they just hack Genesis games. So I'd like to present an outline of my own to gauge opinions and get alternative suggestions. If there's interest in this topic I'll describe details or make mockups later, because this is already going to be pretty tl;dr.

- 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.

DsS from TSC has found a glitch that allows you to walk through any sufficiently thin wall and fall though any floor (nothing new there lolol), and another glitch that allows you to use the uppercut as a superjump to grab poles and such things. His summary from YouTube:

Quote

Shamar night in 79 seconds.

There's all kinds of ordinarily inaccessible areas that can be romped around, but the most notable is in Adabat: you can reach the area past the goal ring that's normally barred off by a solid gate, and within lies an unused device that changes the water level and a tree that can be knocked down to walk across. If you can manage the wallwalking glitch, you can get to it by going through the barred door on the right side of the Adabat ghost mission, after which the ordinary goal ring area isn't barred. He's putting up a video, but apparently having some problems with his DVD recorder <_<

edit: not directly related to the above glitches, but another hidden area in Shamar, from Paraxade of TSC 8)

edit2: DsS has put the video up for the Adabat hidden area. It's primarily a round chamber with platforms that rise with the water level as you reach each new platform and turn the switch, similar to Lost Temple or various Zelda puzzles, with the level's actual original goal ring chamber at the end - since he's actually in the ghost mission, activating the ring results in a failure message. The reason they cut it is pretty obvious once you watch it: while the platforms and the kill plane rise, the actual water graphics don't. My guess would be that it got left on the cutting room floor when time was short. It's a shame, as the concept is much more interesting than the rest of the level and the ring chamber is quite a bit more impressive than how they ended up leaving it in front of a barred door. Given that the engine capabilities for handling the area don't appear to have been implemented, I'd say that's fairly solid evidence against these hidden areas simply being reserved for DLC.