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

A 2.5d platformer built from the ground up in the Blender game engine, Sonic Shift pulls ideas and influences from a number of different Sonic games. I'm not trying to make a perfect Sonic clone in either physics, nor gameplay, but rather a fun game built on the basic fundamentals of the Sonic series.

Sonic 1-like engine: Sonic Shift's engine is most similar to Sonic 1, this is to keep the design focused better than it would be if I tried to implement every special ability from the last 20 years.

2d look, 3d design: Levels only move left and right, but they utilize not only a vertical level structure, but a 3d one aswell. There are higher routes, lower routes, further away routes, and closer routes, and they may all intertwine. It is possible you may see a path in the background whose entrance is hidden earlier in the level. This encourages multiple replays and exploration to find fun new paths.

Simple Story: The story will be kept simple, no more complex than that of S3&K or Sonic CD. Again to keep developmental focus. This is a story that I've re-developed from one of my previous projects that I feel is simple enough for the style of the game, but interesting enough that players will enjoy it in the end.

--------------------------------------------

Todo list:

Engine:
Look up/down
Camera Movement
Water

Game:
Golden Gulch Zone
Crabmeat
Buzzer
More to be announced!

-----------------------------------------------



This little level was created mostly to start to get a feel for level design with the engine, so pardon some of the more crude looking areas in the video. I've been sort of off and on considering adding rings + enemy stand-in's to to this and releasing it as an Engine demo, but right now I just don't think it's a good enough representation of the work I've put into this so far.

Level development is really early, and I still don't think this is ready enough for a public demo (So no SAGE appearance this year), but I felt that I might aswell make a separate topic for this now that it's this far in development and get it out of the general screenshot thread. Feel free to ask questions, point out things you notice in screenshots/videos/demos(whenever they're released), criticize, whatever.

I've been attempting to plan out a Sonic game engine for what seems like forever now, with the impression that the movement physics would likely be the most difficult thing to figure out. So I've been focusing on developing a movement algorithm that will allow for loops and etc, and I've come up with something, but I somehow doubt it's the best method out there to do this. Anyways, I wanted to show what I came up with, and ask if anyone has some better ideas, or perhaps a suggestion to help better it.

------------------------------------------------



A picture is worth a thousand words, so I'll start with that. Theres a basic legend, and an arbitrary distance measurement in place just for reference. I kinda stopped with the arrows halfway through, but because it's all color coded it should still be easy enough to read.

Moving a character to a point x is the most simple movement I can think of, so what I've tried to do here is expand upon that. If the point of collision moves to a point where there is no collision, it assumes that it is above it, and moves the y point down until in collision. If the point moves to where there is a collision, it assumes the point is above it, and moves the y point up until its no longer in collision. This works great until we come to a point where the next point is vertical or greater. To fix this, I only allow the y point to go up as far as the x point has moved, then this new point moves back towards the x point until it is no longer in collision.

At this point, I assume that we're moving vertically, and thus swap my movements. I move similarly based off y, -x, until once again I find myself looping back, then move -x, -y, then -y, x, and back to x, y. I am aware however, that in the current state running on the outside of a loop becomes a bit awkward. I'm not entirely sure how to overcome this yet, though I'm still thinking about it.

--------------------------------------------

I'm not entirely sure that I've explained what I've thought here too well, which is why I've included the picture as well. I'm always open to re-explain it if I've done a poor job the first time. Is there a better way of doing this I'm just not seeing, or do you have thoughts on how to better this idea?