Jump to content
A 2021 backup has been restored. Forums are closed and work in progress. Join our Discord server for more updates! ×
SoaH City Message Board

UnityBlitzEngine (BlitzEngine port to unity)


Recommended Posts

Hello!

Inspired by this video:

I decide to port the Damizean BlitzEngine to unity. I always wanted to see a good freeRoaming sonic done right. The BlitzEngine made by Damizean allowed many people to try to do just that and experiment with this idea. Progress have been made and good idea was born, but to my knowledge nothing tangible was born.

I was a bit disappointed that most mod focus on sonic movement edit and level design while gimmick interaction is nowhere to be seen. Aside from people like Bagjac and his retro sonic edit (Which I can't find the video back) or Azukera and his WIP FreeRunner there is little work and open sharing on gimmick (aside from bumper edit). The blitzengine is also powered by the aging Blitz3D which have its weakness.

Unity is more powerful and multiple platform. It also have a much better workflow to do level and edition. Coding and sharing is also easier thanks to his script component system. It's more powerful and have more option for graphics while still allowing older machine to run the game. And unlike Blitz3D, it's totally free!

The unity port will try to be fully compatible with older blitzengine file (configuration and stage xml). I also plan to share not only the code, but also a complete 3D pack to ensure people would start quickly and easily. It will feature some editor to directly modify parameter through drag and drop without having to code (character creation editor, physic editor, gimmick editor and unity is already the level editor but would also generate XML for sharing level with old blitzengine). I will try to emulate all sonic physics, from classic to unleash going through adventure. It will also feature a small demo level to showcase instance of 3D design and will be release with illustrated documentation of the inner working of the engine and code.

What I want to achieve in the end is a versatile 3D platformer engine that will allow 3D freeRoaming game in the vein of sonic, mario 64 and mario galaxy.

RoadMap:

Cycle 1

- Straight port of the core code (mouvement, input and camera)

- adapting the straight port to unity's quirk

- Adding Xml support for level loading and saving.

- Polish and reorganization of code, first pass on documentation to help modding (compatible with blitz3DEngine and explain difference)

Cycle 2

- Making the demo showcase

- Making the physic editor

- Making the gimmick editor

- Making the character editor

- Documentation for editor

Cycle 3

- research on sonic physics and gimmick

- Doing classic physics and gimmick

- Doing adventure physics and gimicks

- Doing unleash physics and gimmicks

Cycle 4?

- Making a full fangame that show case 3D freeRoaming sonic gameplay with a "repaired" sonic story.

Right now i'm only planning for cycle 1 and reevaluate each cycle base on previous one.

Currently I'm in the last (difficult) phase of fixing the code to work flawlessly with unity.

Here is some analysis that will guide the creation of the demo and maybe the fan game to an extent.

sonic 2D light analysis

Sonic is much more Toy like that a mario, who is more challenge based. Basically it's a simple set of movement the level support, it's much more like tony hawk complete with half pipe and ramp.

The only thing I may add is that like toys, sonic work with sensory overload, level are total playground and they play with you.

Actually you can see the evolution of the game from sonic 1 which is a more regular platformer with usual platformer puzzle and classic jumping challenge (marble zone exemplify that) with the occasional playground level (spring yard zone). Sonic 2 start to take advantage of sonic movement much more and in much more nuance way with use of subtle ramp and overall rounder layout with more playful use of the two layer of collisions but still mostly straightforward. That's level like chemical plants and metropolis that will first start with the brainfuck layout that totally take advantage of sonic has a physical toy and brought the sensory overload to a maximum (metropolis loop top and bottoms and there is a spot where you can endlessly fall with wall covered with spring, total vertigo guarantied!).

Sonic 3 + knuckles is the top of the sonic level design, and to my knowledge I have never seen "a to b" level design so masterfully done, a single level sometimes feel like a metroidvania (marble garden i'm looking at you). The main design pattern is some kind of "brainfuck", there is an obvious visual path that are not the real path, you think you can simply run across the visual path but there is a gimmick or a level configuration that send you on another path.

What makes the brainfuck awesome is that it's layered with multiple condition that send you on multiple path and it takes into account the double layering of level. For instance if you are on one layer at some playthrough, the next time you might on another layer because of small decision you made earlier, or maybe you just backtrack, and the game is not the same.

Also the game works with some kind of obfuscation through complexities, most of the time in sonic 3 I don't where I am, i'm just confident I'm making progress, even I don't know where the fuck I just land! It hide the simplicity of the path and marvel the player as each time a new situation happen. Enemy play with that, depending on how you navigate they CAN totally mess the timing, timing is important as speed and momentum are affect therefore which path you will choose or land on.

Level design are truly folded and even with a map dump it's hard to plot a path (unlike mario) because there is too much parameter at play. It's emergent as hell.

sonic freeroaming 3D analysis

The main difference between 3D and 2D for sonic is verticality. Platformer rely a lot on gravity and that's a vertical force. 3D game are more forward and horizontal based, verticality is therefore harder to manage. The way they go with modern sonic is wise from this perspective, except they didn't do a lot of thing with. Sonic was a game about speed not just with speed, every gimmick was powered by speed or momentum, and the game was much more environment (navigating through hazard) based rather than interaction based. The navigation was a challenge + a puzzle.

But how can we translate that in 3D? Verticality can be kept and still be seen from a horizontal perspective. I see some major case:

Pure horizontality

Like every game it's about navigating around elements and hazard in any direction, a maze or a labyrinth is the main aesthetics. It's easy, aside from gimmick that impact navigation, hazard and enemy to avoid, the player can go at it's own pace.

Downhill:

This one is a bit more tricky and gravity start to play a larger role. Basically gravity force you down and therefore impose a way to go and a pace. That's where SSX style gameplay can help, you still have opportunity for multiple path and timing is much more important.

Wall climbing:

It's the exact opposite of the previous case, gravity work against you and prevent you to reach higher place, Momentum is what you need to go farther. You still can have multiple path with gimmick or rest place to help you stick to the wall, but it may forbid some movement like jumping, or any movement that will make you sliding down. This is kept horizontal by having the camera aligning with the character movement for exemple. While some game feature a bit of wall running, parkour like, it's not exactly the same, generally they are just forward horizontal path.

Ceiling running:

One effect of speed and momentum in sonic is the ability to stick to surface. Ceiling run is interesting because it makes the character keep running otherwise he will fall, not counting the dizzying effect of having the entire world reversed.

Freefalling:

Falling can be a way to build momentum, especially if you land on slant surface. Therefore whole design can be build around the idea of falling as seen in some instance of modern sonic gameplay (unleashed, colors, etc)

Stepping stone:

This is the direct translation of 2D vertical gameplay, this should be kept on expert routes for advance user. Or use very moderately with ample margin.

Of course those design pattern can be combine together:

Slant ceiling have gravity pull and the no slow down effect combine with the dizzying reverse world, a bridge toward this pattern and a stepping stone would be a very hardcore feature to pull for the player (especially if he need a free falling land on a downhill slant to gain enough speed to cross the stepping stone).

There is plenty to do

Another things it can take advantage of is inertia and takes clue from F-zero X.

For example, it use flat curve instead of banked curve, it's more difficult to turn without anticipating and keeping the speed and not being ejecting from the path. A sonic game could take advantage of a reversely banked curve to add a layer of complexity to keep a path. Turning is under used in modern sonic aside from some cinematic effect. Drifting without skidding, controlling speed under a frame windows to avoid ejection without slowing down and lose the contact effect, are challenge unheard of in any game and that could be specifics to a good sonic 3D.

Here is the current FUGLY code source and prototype. Sonic borrow from damizean test zone and level borrow (momentarily) from linksonic5 skydive engine. Code is heavily annotated and in wip state.

Download link:

http://dl.dropbox.com/u/24530447/build.rar (exe and package)

http://dl.dropbox.com/u/24530447/script.unitypackage (script only in unity package)

http://dl.dropbox.com/u/24530447/script.rar (script in *.cs file)

Control:

Reconfigurable before playing

QSDZ (azerty) + arrows: movement relatif cam

Click left: jump

Click Right: instant stop

Both click: spindash

Mousewheel scrolling: zoom in/out (broken)

debug toggle cheat (beware: no feedback on activation):

R: sticky mode (don't fall from steep angle and ceiling)

G: galaxy mode (jump relative to current slope, beware don't reattach! on steep angle)

Current known problem:

1. The character is F**** sticky!

- Cause: The collision engine in unity is way more powerful than Blitz3D and this is the consequence of this, it solve the occasional "bump fly" blitzsonic is known for but now you can't fall edge.

> status: solvable with raytracing and flags, secondary priority.

2. The camera is strange, it have a small delay which get bigger with ample movement!

- Cause: Unknown, it's like a desync of unity's internal loop with rendering and physics.

> Status: solvable, create from scratch a new camera system based on unity internal working. Secondary priority

3. You can't jump from ceiling, the character stick to the ground!

- Cause Unknown, it does not happen when i trigger the "galaxy mode", it may come from some magic with realignment after a jump.

> Status: Researching! this is a fundamental element of the 360° movement engine! Maximum priority! request help and info!

4. The character misAlign after some 90° movement (and lower angle) and mess up movement!

- Cause: Unknown, to solve Gimbal lock (yes without rotation and with quaternion for you math headed) I use a vector projection but it has it's own flaws, it mess up on certain angle configuration, I don't do math I have no idea why.

> Status: Researching! Core 360° movements is the whole game, CRITICAL priority! request help and info!

5. The character visual mesh became wacky and spin non relative to movement, lost direction!

- Cause: Gimbal lock (because it happen on pole even more wildly)! The vector math is not immune to gimbal lock, the solution used for the collider does not work because the mesh rotate and the collider don't (fixed reference frame). I'm not math headed enough.

> Status: Researching! Core 360° movements is the whole game, CRITICAL priority! request help and info!

6.The character is repel in outward slope upward after some loop de loop onto sphere or other outward shape!

- Cause: Unknown! look like the game lose tracks of reference, damizean also hard coded the dot product to evaluate slope vertical friction in the Y value of the motion alignment vector which is in global scene space (gravity is supposedly always align to Y).

> Status: Researching! this is a fundamental element of the 360° movement engine! Maximum priority! request help and info!

7. The character animation is too low relative to speed

- Cause: Difference between the build setup and the editor test.

> Status: solvable, cosmetic, low priority

Cool spot on the test stage to test the broken aspect: look for the big sphere! walk on ceiling and under the level, laugh!

If you want to help you can contact me there:

ether.n.aile (at) gmail.com

Special zone:

Will this project be finished someday?

I just quit my jobs, have a bank account and is full time on this! As long I don't bankrupt! Therefore I'm in for just enough time to at least finish the core engine. If I found people to helpme on critical aspect maybe it will be even bigger than that! No social pressure, no part time work, no side project, I would better finish this!

Why are you doing that?

Because I'm a sonic fan and want to contribute the community, and to pragmatically teach myself unity and programming to start my own games. A sonic project have the right level of complexity for me to learn things I want, 360° movement engine is critical to many game idea I want to experiment. SO it's the best of all world!

  • Like 1
Link to comment
Share on other sites

...pretty interesting. I''d like to help. Unfortunately, I know nothing about BlitzSonic or Unity. But I still can deal with equations, functions an programming logic with ease. I may get some mathematical answers for the problems you're experiencing. Dunno. Let me see if I can think on something.

Link to comment
Share on other sites

Hello!

Thanks for being interested guys! :tgrin:

@LH The HedgeHog

Great! I'm not too good when the math became advance and only progress by trial and error. I already solve Problem n°5 But I believe the n°4 to be more mathematical in nature and 4 might a direct consequence of it.

Also I might have some question about some equation done in the code so I know how to manipulate them precisely!

Most of problem are about retrieving coordinate system and convert them in a different one.

The current one I experience is:

4. The character misAlign after some 90° movement (and lower angle) and mess up movement!

- Cause: Unknown, to solve Gimbal lock (yes without rotation and with quaternion for you math headed) I use a vector projection but it has it's own flaws, it mess up on certain angle configuration, I don't do math I have no idea why.

> Status: Researching! Core 360° movements is the whole game, CRITICAL priority! request help and info!

The beige square under the feet in picture below is the reference frame in which movements are calculated! If it's fucked up, movement are f*******

It should always be align to the world ref.

Correctly align

referenceframe02align.jpg

After a lot of whoopee loop de loop de loop on various angle MISALIGN F*****

referenceframe01misalig.jpg

The way movement is calculated is that the collider translate along his local coordinate and should match to world axis when his Y is up. All the code do is translate the collider and aligning Y to surface normal (no rotation). But if you do it too much it lost his reference frame (alignment on XZ (horizontal) to the world once Y is up) and that mess the movement of the player.

The bit of code that manage that is pretty simple:

			//adapt to character controller

MoveController=new Vector3 (

this.Motion_Speed.x * Time.deltaTime,

this.Motion_Speed.y * Time.deltaTime - (0.015f/5f + (this.Motion_Speed.magnitude * 0.33f * Time.deltaTime)),//magnet to ground

this.Motion_Speed.z * Time.deltaTime);



this.AlignForward();



this.body.transform.Translate(MoveController,Space.Self);

[/CODE]

Basically what it does is:

- I take the motion data (motion speed)

- Apply a function Y to keep feet on the ground based on

- Align the character with a special function that fixed previous gimbal lock cause by a naive alignment.

- simply translate it along his local coordinate using motion data to move tangentially to the ground

The problem lie in the alignment, previously, despite using vector alignment and quaternion (no explicit rotation) I had a gimbal lock, googling and asking question like now solved partially the problem:

[CODE]

Vector3 fwd = Trans.transform.forward;

Vector3 proj = fwd - (Vector3.Dot (fwd, Align)) * Align;

this.transform.rotation = Quaternion.LookRotation(proj, Align);[/CODE]

What it does is calculating a projection of the GameObject's forward vector on plane defined by Align vector, then generate a rotation that looks in direction of the projection vector and has the align vector as up vector.

The align vector is passed either as gravity when on air or surface normal when on ground.

*transform is the structure that hold the spatial data of object (rotation, position and scale).

I tried to force alignment to the world at each step (using the old code) and then align him back to surface normal but gimbal lock reappear!

[CODE] Trans.transform.rotation =

Quaternion.Lerp(

Trans.transform.rotation,//from

Quaternion.FromToRotation(AlignAxis,Vect),//to this

Rate//at this rate

);[/CODE]

What it does is that it linearly interpolate the current rotation to a target rotation define by the function FromToRotation, which take in input the axis to align and the destination vector.

This code was discard because it was explain to me that:

I suspect this may be your problem. Your input information is a Quaternion (representing your character's current rotation) and a Vector3 (representing the surface normal). You can interpolate to take your character's local Y ("up") onto that normal, but you need to also set your character's local Z ("forward") to a suitable tangent. This is not uniquely defined by your two input. Now informally it's obvious to both of us which particular tangent you want, but how are you calculating it? Because it sounds like you're ending up with the wrong one!

Googling based on that explication lead me to the new algorithm with projection to pick a reference. But I still use the old code for gravity alignment on air, which correct the reference of the object back to correct data (but the incorrect data mess up the direction of jump when switching from ground to air).

But problem will happen as soon as I implement varying gravity!

Link to comment
Share on other sites

Hey, I'm working on something like this. At the moment I'm doing some other background stuff, but I plan to continue on the actual control aspect soon.

The basics are in place, but it still has a fair bit to go.

EDIT:  *Snip*


We should work together.

Edited by Nemox
Link to comment
Share on other sites

Agreed :) I'm still working on the bug I had and making small progress but progress nonetheless!

If you want to help you can contact me there:

ether.n.aile (at) gmail.com

Ah, I had just sent you an email via your profile.

If you prefer, you could reply here, or through said email.

But yeah, I'm working on some reeeeally baseline stuff to go into a game, such that characters' powers and abilities will be truly quantifiable.

Basically fleshing out and refining the character system, so that when we test new features, we'll already have a character to work with.

Link to comment
Share on other sites

Downloaded and Played..

Well it's still very early stages but if you put your mind to it you could really make something good out of this. I know how powerful Unity3D can be when you use it right and this has some damn good potential dude!

Link to comment
Share on other sites

@Azukara

I missed your Kind word the first time for some reason, but now I can repair that mistake. Let me tell you I'm glad you appreciate the effort since If you pull out FreeRunner (which have been an inspiration for me too) I will the one Hunting you to uber HighFive! Actually I would have proposed my service as soon as I had something working flawlessly!

@JetHawk

Thanks for the kind word!

@Tuah

Can you explain this quote above more?

But yeah, I'm working on some reeeeally baseline stuff to go into a game, such that characters' powers and abilities will be truly quantifiable.

Basically fleshing out and refining the character system,

I received your email.

My plan was to get basic movement correct first (360° navigation) and then get the code ready for an easy and accessible editor akin to game maker (not as powerful and more specific to sonic/mario like character and gimmick). It will be restrict to mouse and directions, people who want more will tweak the code. Then I will make "physic pack" that will research various sonic and co physics.

"Fluff" like menu and graphism, the plan was to let people take care of for this first core engine, and when I would start the graphic part, I would focus more on providing a starting pack that will work on many platform (without advance effect like shader) for people to prototype level quickly.

Link to comment
Share on other sites

@Azukara

I missed your Kind word the first time for some reason, but now I can repair that mistake. Let me tell you I'm glad you appreciate the effort since If you pull out FreeRunner (which have been an inspiration for me too) I will the one Hunting you to uber HighFive! Actually I would have proposed my service as soon as I had something working flawlessly!

@JetHawk

Thanks for the kind word!

@Tuah

Can you explain this quote above more?

I received your email.

My plan was to get basic movement correct first (360° navigation) and then get the code ready for an easy and accessible editor akin to game maker (not as powerful and more specific to sonic/mario like character and gimmick). It will be restrict to mouse and directions, people who want more will tweak the code. Then I will make "physic pack" that will research various sonic and co physics.

"Fluff" like menu and graphism, the plan was to let people take care of for this first core engine, and when I would start the graphic part, I would focus more on providing a starting pack that will work on many platform (without advance effect like shader) for people to prototype level quickly.

The baseline stuff I mentioned is things like character stats and some RPG elements. In this way, all characters will have unique skills that set them apart from others. Sonic with high speeds, Espio with high traction, Knuckles with high strength, etc.

Also, as I mentioned in the email, a clothing/customization system which will allow for any character to wear any item, and even have custom characters. It'll allow for much more varied NPCs than, for example, Sonic '06's "Bald Man" and "Middle-Aged Man".

I've come to realize, though, that this stuff is rather superfluous without an actual game for it to go into.

So instead, I'm going to slap together a main menu and character selection screen, and refine the basic control system. As you said you wanted this to be a learning experience, perhaps you'd like to handle in-game HUD?

This would also allow you to go ahead and make some graphical stuff much sooner. (Feel free to take your time though. Quality >> Speed.)

As for the real meat of Sonic games, I have a new philosophy behind "Universal" character movement, so I'll give that a shot. Once it's finished and a basic character is playable, I'll send you the package.

A little explanation of how I made it, and the learning process behind it:

The Locomotion System, free on Unity's website, has a scene with planetoid gravity, ala Mario Galaxy; exactly what I was looking for, and even a perfect calculation between the controller and the character's orientation.

However, it's a terrible system. I cranked the speed up, and he went flying off into space! Hell, he didn't even go as fast as Mario.

It's because of how gravity is handled. Every FixedUpdate, a raycast is done in the character's "down" direction. Whatever surface (normal) it hits becomes the new "down", and the character is adjusted to the normal. Gravity is then applied in the character's "down".

This means if there is -nothing- under a character, he will not get adjusted, and gravity will throw him out into the abyss. Instead, I keep track of the surface and the planet. I raycast between the character and the planet, and "down" becomes the down direction of whatever surface the raycast hits. This means if Sonic is on a cube planet, gravity doesn't just pull him inward like a sphere, but toward the flat surface he's standing on. But if he walks off the edge, it ends up hitting the next side of the cube, and gravity is applied in that direction instead.

If the raycast hits a different planet entirely, it starts raycasting to that planet instead.

As far as basic movements go, I have a few calculations that are simple to follow. Acceleration to top speed is just desiredVelocityVector.normalized * Clamp((topSpeed - velocity.magnitude), 0, acceleration);

I forget the calculations at the moment, but I also included an offset so it wouldn't interfere with gravity, an addition to Top Speed that accounts for a platform's velocity and rotational velocity (dot and cross products, respectively) and friction, and some other stuff.

Now, I have a completely different idea of how to handle gravity. Instead, I think it should not be based on the character (or object), but on the planet. The planet will do all the work, and the character should behave reactively to his environment. It'll be pretty confusing, but I think it'll work in the end.

Addendum: Oh yeah, don't be afraid to rely on tutorials for stuff! I learned a ton from BergZergArcade's tutorials on Youtube: http://www.youtube.com/user/BurgZergArcade

It's not just a bunch of mindless "put this here, click this" stuff; the tutorials really do teach you a lot about C# programming. What you're doing, why you're doing it, and how it applies to your own personal game.

Link to comment
Share on other sites

I see what you are doing, My locomotion system is even simpler and is a derivation of Blitzsonic.

I only update alignment on contact with a surface, apply a contact force toward the surface and move the collider respective to his local coordinate (movement are calculate into a local reference). It don't miss the ground at all and can even handle very sharp slope (at least 90° so far) at any speed (thanks to unity high update rate).

I don't use raycast yet, I will use them to test for sharp feature and allow falling down an ledge instead of being sticky like now. But my major problem now is gimbal lock and loss of direction reference who mess mouvement.

I handle gravity like you plan to do, basically sonic have a gravity alignment data that he align to on some condition (jump or falling down), I just let a planet "own" and update this gravity data (I plan to do this with a onTrigger around the planetoid and some editable priority management in case of multiple owner).

I think we have same goal of an elusive universal platformer engine! Your RPG stat is basically what I mean when i talk about the editor and making the data accessible through it. And the "clothing" system is also what I will handle through the editor (ironically dub recolor editor). As a designer, gameplay programming is the most important aspect for me, everything else (hud, graphism, menu, etc...) are irrelevant if the basic control are not perfected first, it's were the game is.

However when I said this is a learning experience, i'm rather experience with making game in general, i'm pretty confident in my solving skill too. It's more like being in sync with the dev environment. I'm a former professional game designer who jump indie by conviction. So I already know the basic concept I just need to get up to speed with the new tools (and I was never a "really" a programmer too). Get solid basis is important before starting anything that don't contribute gameplay.

Link to comment
Share on other sites

In Unity, we have access to much more advanced physical interaction through PhysX. Instead of directly moving a character and his collider, it is much better to use a rigidbody and AddForce. This way, characters will interact fully with the game's physics! If you're running fast and you ram into a flimsy box or another character or something, it'll send it flying! Or, if the character or box is really heavy, your character will only end up pushing it a little bit.

This is where the real "universalness" comes from! >:D

While advanced physics may sound complex and bulky, it's actually very clean and simple. Handles collisions automatically, and no additional scripts are needed for such emergent character-object interaction.

This is also where that Strength stat comes in. Characters with a high strength will be able to apply more force against other objects.

As far as a clothing/equipment system goes, I've been trying to make something akin to World of Warcraft; clothes are a combination of a texture applied to a character's body and an extra model attached to the character, which is resized to fit the character's size.

Then, if a character's body clips through the clothing model even after resizing, that underlying body texture will keep the character's body from showing through.

Through this method, even clothing can be universal. Only real problem is that all character models must share a similar UV layout. Not difficult, but all of the Sonic Heroes models I have will require a completely new UV map. x_x

At the moment, I have a function that takes all of a character's materials (which are layered on top of each other automatically), places them on a plane, and renders them. It then uses ReadPixels to spit out what's rendered, and you get a single texture, reducing draw calls by many times. Only downside with this is that without Unity Pro, textures are restricted to the size of the game's resolution.

Only thing left in it is combining these flattened materials into Texture Atlases and stitching the meshes together into one single object to reduce draw calls from (material layers * (body parts + clothing parts) ) down to one.

But yes, this can wait.

At the moment, the really important parts are a main menu, character/level selection, and a refined control system with easily accessible variables so we can connect it to a stat system later.

UPDATE:

I've been re-learning how to work with Unity's GUI. I still have a lot to learn about creating really good setups, but it's functional at least.

Currently it has a start screen, adventure mode with character and level selection, options menu (though no options yet), and an extra info/credits menu. Very rudimentary, but next up is a way to automatically handle local multiplayer with splitscreen.

As far as loading a level through XML, it'll be more complicated than the Application.LoadLevel() function. In Unity, if a level is not added in the Build Settings before the final build, it can't be loaded. It shouldn't be too hard, but it'll take some work.

Link to comment
Share on other sites

  • 4 months later...

http://dl.dropbox.com/u/24530447/build%20of%20sonic.rar

I have been halt for 7 full month on some handful of bug (really only 2) :(

But here is the latest build ...

Learning programming on the go is hard but it's not the big bug that halt you, those are easy to spot and research, the sneaky ninja bug is what kick you in the face while staying in cover, they are easy to get rid, but have to spot them first D:<

Camera still not done, level loading is next since camera work will be a tough one to meet my standard. I might need some refactoring.

I need to playtest that to the hell to be sure there is no bug left and tighten the code. Notice It's still blitzsonic physic, good physic is not yet plan for tweak (need the basic code to run properly).

Link to comment
Share on other sites

  • 1 month later...

Ah, back into it then, eh? I am as well!

I've been working here and there on the control system from my old videos, and I've made some drastic improvements. At the moment, I'm just having design issues with wall-walking and acceleration; so hard to decide how I want it done.

Basically as it is, Sonic can easily accelerate past gravity, so he keeps speeding up even while going straight up a wall. Was thinking of some sort of 'traction' variable; decrease the acceleration based on his angle away from the ground.

Not sure how I like it.

Also, a 'sticky feet' variable of sorts. Basically if you go too slow, you fall off. But actually creating a formula for it is hard to decide. Simply defying gravity would cause issues with acceleration and all. Maybe lowering the rate of any gravity acting directly against the character's ground surface...

EDIT: Works like a charm! I'll get some other baseline system stuff worked out (new, better player-handling system for splitscreen), and then maybe I'll assemble some sort of playable pre-alpha demo to show you how my design philosophy works.

Link to comment
Share on other sites

  • 1 year later...

The project is still alive, after porting (successfully) the blitzengine, some aspect did not satisfy me about control and camera, I wanted something more robust because the blitzengine had some bugs.

For example while going into a loop works fine most of the time there is special case where you are likely to get stuck spinning endlessly if it happen to be a mathematical pole. That mean that running on ceiling was mostly forbidden.

It took me literally 3 years to identify and fix the problem for good and have the kind of control relative to the camera I wanted. But it's done! I'm currently implementing generic physic engine before moving onto sonic physics and merging with the old blitzsonic code.

This is develop on an intel gma so, unlike Sonic GDK, it will be a versatile engine to use. I expect to do a pass to clean and comment code for easy use so anybody can make 3D sonic game for free. The objective is to make an easy editor which allow character, level and enemy customization.

Disclaimer: code are given "as is", it does not reflect the final product and might be unsuitable for easy use, it is provided for anyone courageous enough to tweak them.

If you want to dabble with it, early code of the revamp are accessible here:

http://forums.tigsource.com/index.php?topic=32182.msg872412#msg872412

The unity project is here if you want to toy with it:

https://dl.dropbox.com/u/24530447/sonic%20engine/lite%20sonic%20engine%206b.rar

Old project but it's a bit mess up as I was heavily experimenting with it

https://dl.dropboxusercontent.com/u/24530447/sonic%20engine/UnityBlitz-S2-Engine.rar

You can try to merge it with the new code if you can make sense of it.

Link to comment
Share on other sites

If you want to understand why it took so long, here is some resource for you, it might help you understand what's specific to mario galaxy and 3D sonic as a challenge:

1. the first problem you meet is gimbal lock:

2. generally quaternion is the solution

3. but quaternion fail because of that too

The solution is to not think into rotation but in vector and projection, kinda like lighting calculation ...

Link to comment
Share on other sites

  • 1 year later...

I'd love to see a BlitzSonic port into UDK, maybe I should make that going off your port of BlitzSonic into Unity as a base. I am also going to make a port of the "Sonic World" Blitz3D game into Unity format, in order to make my final goal (A large-scale UDK Sonic title) easier.

Basically, I'll finish what Neoshaman started.

Edited by Miru
Link to comment
Share on other sites

  • 4 weeks later...

I'm considering making the playable characters easily editable by making them XML files like the stages are, rather than hard-coded into the engine. This is because I ended up listing a few dozen unneeded characters I kind of regret including (Pinky from that "OMG Most Original Sonic Fanfiction EVER!" parody video? Blonic? Yeth from that crappy Sonic 1 hack?) Maybe I will end up making Super Forms XML files as well?

I'm also considering making Badniks, and maybe other objects, XML files, rather than flooding the game with unused nasties. I also found all of the "stage" parser C script was dummied out, so I'm undummying it.

Link to comment
Share on other sites

I'm considering making the playable characters easily editable by making them XML files like the stages are, rather than hard-coded into the engine. This is because I ended up listing a few dozen unneeded characters I kind of regret including (Pinky from that "OMG Most Original Sonic Fanfiction EVER!" parody video? Blonic? Yeth from that crappy Sonic 1 hack?) Maybe I will end up making Super Forms XML files as well?

I'm also considering making Badniks, and maybe other objects, XML files, rather than flooding the game with unused nasties. I also found all of the "stage" parser C script was dummied out, so I'm undummying it.

 

Actually Unity uses a handy prefab system.  If you create a character prefab, you can load it up on the fly I believe.  If I understand it properly, you should be able to point to a particular folder, search for all Character prefab objects, and instantiate them.

 

The only issue I can think of is whether this counts as asset streaming if it isn't straight from the build.  Streaming requires pro, but I don't think that's what it is.  I'll come back to this subject eventually.  Got a big project to work on, then an app I have to finish, school registration, oral surgery, and it looks like my laptop has to go get fixed.  Bugger all.

Link to comment
Share on other sites

Actually Unity uses a handy prefab system. If you create a character prefab, you can load it up on the fly I believe. If I understand it properly, you should be able to point to a particular folder, search for all Character prefab objects, and instantiate them.

The only issue I can think of is whether this counts as asset streaming if it isn't straight from the build. Streaming requires pro, but I don't think that's what it is. I'll come back to this subject eventually. Got a big project to work on, then an app I have to finish, school registration, oral surgery, and it looks like my laptop has to go get fixed. Bugger all.

Yeah, I'll begin making prefabs of the cast tommorow. Will likely end up cutting at least some of the siller or redundant characters like Blonic. The first demo will likely ship with about 20 or so characters.

EDIT: Overwhelmed by the sheer amount of code errors so far. It'll take me a while to get all the kinks out.

Edited by Miru
Link to comment
Share on other sites

  • 2 weeks later...

Hello

I was supposed to continue working on this engine but I burn out, also attempt to use nurb collisiohn didn't go well in a 3D tiles way. The current version is kind of rough on only deal with controls and some optimization can be made. The main problem was to have a flawless 6dof movements the original engine didn't have.

However I can offer help for any code issues, I'm not sure if the current code is up to date with new unity version. One burden wa sto be totally alone while corking on this. One thing I think needed to be done was to create exporter, a bltz3D exporter (with one texture layer) exist and can be expended upon. A converter for stage is needed too (and bringing hard code fog value in the xml).

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...