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

neoshaman

Members
  • Posts

    16
  • Joined

  • Last visited

Posts posted by neoshaman

  1. It's not dummied out, it's not ported, the code in blitz3D was really just an xml exporter, there is also no object code but those are trivial to makes. You can just drop level mesh and then set collision layers and it works. Coding the collision for object will be easy to add.

     

    This port is only the character and control code so far. But the blitz one was too limited, I need to rethink the code for flexibility.

     

    I'm working on another project I will resume this one after that project.

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

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

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

  5. The project is on hold because Pelikan is busy with his new job, but hopefully we'll retake it once he has more free time. On my end, I've been thinking on upgrading the engine's paths system to something more stable, robust and fast, but I still need to figure out some of the math behind.

    Basically, how to find the closest point to a Cubic Bezier? Been thinking of using a numerical approach, something along the lines of a divide-and-conquer algorithm.

    Anyone ever messed with this issue?

    I'm not sure about cubic spline but I had stumble on this one for quadratic curve, I guesss you could approximate the cubic with a bunch of quadratic to make it quicker to implement.

    http://blog.gludion.com/2009/08/distance-to-quadratic-bezier-curve.html

    From cubic to quadratic (not personally test yet)

    http://steve.hollasch.net/cgindex/curves/cbez-quadspline.html (short version)

    http://www.caffeineowl.com/graphics/2d/vectorial/cubic2quad01.html

    http://www.timotheegroleau.com/Flash/articles/cubic_bezier_in_flash.htm

    http://fontforge.sourceforge.net/bezier.html

    (I like giving multiple ref to cross check)

    I stumble on this when I was researching the exact same matter but for surface. I plan to roll out my own take on 3D sonic engine but using "nurbs point" for smoother collision kinda like they do on racing game.

    more here:

    http://www.gamedev.net/page/resources/_/technical/game-programming/terrain-system-for-circuits-r2729

    resource:

    http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/bezier-curves-and-surfaces-r1808

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

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

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

  9. This fangame is on my watch list for so long! can't wait it to be finished. It feel like the perfect blend of all sonic aesthetic, from a more platformer take like sonic 1 and sonic GG but even more fitting to sonic rush but tone down rightly.

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

  11. 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
  12. Mario 64 and Mario galaxy would always compete for the best 3D mario because by design they are vastly different.

    When you think about it Mario 64 was insane. To get one star you need 3 skills at the sametimes:

    1. Figure out where is hidden the stars, you are grant one hint

    2. Once you find the star you must figure out one path to it.

    3. Once you figure out the path you must have the skills to perform it.

    But that's not all, it's not one puzzle at the times it seven interwoven at the same time! and there not trivial puzzle, they were spatial skill base puzzle. Not counting dynamic element (water level, size change, etc...).

    Banjo series, sunshine and DK64 just took that formula and went totally crazy with it while streamlining the design. Heck i remember having explored a whole level in TOOIE without having a clue to where to start, not counting level had influence on each other.

    On contrary Galaxy is much more streamline. You don't thought that much and it's closer to smb than any other mario... you cannot "scroll" back. Galaxy kept things focus on plateforming and using planet or area as discrete unit of challenge. Each unit have a very clear goal to clear to proceed to the next. Puzzle if any where trivial and base on repeated element (find piece of star, etc...). It seldom have interwoven challenge. Actually Bowser level in mario 64 are closer to that.

    I prefer Mario 64 more, it blew my mind with solid control and clever challenge. I like the spatial puzzle that had put down many of my friends (they don't like running in circle).

    However how would sonic play in SMG2, yoshi plays an important role, that mean sonic would ride yoshi? kind of weird isn't it? Would sonic use fire flower? ice flower? drill? it detract from the character too much, but i would like to see sonic in smg if they avoid this, it would be like revisiting level and finding new way to play them with sonic ability (replace yoshi with tails following it, and inflate could be tails flying). A little cameo would be also nice! :ssmile:

  13. look like the sonic cycle is wide in the second part, still undecided whether to balance into good or bad... we need more gameplay footage and more hands on to break the cycle completely.

    Look decent so far BUT hardly exciting.

    Some friend trick me with a video of SONIC XG (

    ) saying sega is doing Sonic 4 RIGHT! Googling for more i have seen the real footage... When an official game look less awesome and inoovative than a fangame, you know...

    :ssleep:

    Hope they quit with QTE like gameplay, bottomless pit, blind into depth run, stupid "best branching path", dull cinematic speed corridor... They still have many way to fuck the level design, even trying to return to the basics.:tsleep:

    Wait and see

  14. Well played on WII not that bad but not good either

    What's with all those instant death in the game? I don't remember dying a lot in cheap death in old good sonic? I'm not that bad, i have finish the game in one day...

    The game find way to inovate but it is a big hidden QTE, fail? DIE!

    > slow down? die

    > accelerate? DIE

    > miss the stupid targeting cursor? Die!

    > stupid wall jump use 3 times in the game? DIE

    The targeting upset me most as it doesnot depend on the game state (like distance or whatever like in SA1) but the actual showing of the cursor (QTEd!) that lead to weird situation where i'm near an enemy but cannot attack and instead i dash the hell to DEATH! Where is the control?

    Anw what's with the bottomless pit? Metropolis didn't but you have the endless falling loop, old sonic let you fail and have a chance to receover, you always felt that you die because of your own not because the game want you fail...

    The game pretty much play itself until the death test, all you have to do is to wake up at the right moment...

    By the way it's a right step i hope future installement would as fun as some part of this one was (i hate secret rings)...

    I enjoy the game and there was little burst when i thought "wow SONIC IS BACK" :) (shamar)

    That's my opinion not something that hold the truth about the game

    There is difficult game (Ninja Gaiden is) but this one is no hard, it is punitive

    The old sonic was "flexible" this one you must play the designer's way.

    As it turned out, according to Mr. Andac, after Sega had restructured itself to re-integrate external development houses like Smilebit and AM2 back in to the main Sega offices, Sonic Team was kept external strictly as a sweatshop to milk the Sonic cashcow, assembly-line style. Sega of Japan had intended NiGHTS: Journey of Dreams as a brief rest from the never-ending onslaught of Sonic game after Sonic game. In Ben’s own words: “There’s no doubt that Sonic Team have lost their quality touch. They are worse than talentless: they are without passion. Bored, weary, closed-minded and out of touch with any sense of what makes games good anymore.” Quite simply put, after making so many of them, Sonic Team is tired of Sonic games - something Ben cites as a reason for Yuji Naka’s resignation in 2006.

    By the way for the paranoid FANBOY

    http://kotaku.com/5124622/rumor-nights-sequel-was-originally-an-xbox-360-ps3-game

    http://www.tssznews.com/2009/01/05/the-blog-sega-doesnt-want-you-to-read/

    http://web.archive.org/web/20070408161400/http://bossrush.blogspot.com/2007/03/nights-2.html

×
×
  • Create New...