[Aerosol]

Yea, I meant to do this sooner. Whoops.

So I popped open Blender to get cracking on the Countryside demo, taking some time to refamiliarize myself with its interface (or lack thereof). Then it occurred to me that I had some questions as to what purpose it should be built to.

I thought that it should primarily be a showcase of Mobius Engine's rendering muscle. Like I said in another topic, we have movement engines that have accomplished what was once thought impossible. That is, full 360 degree movement in 3D space that functions just like the classic games did. So my take was that the area didn't necessarily have to be a large one. Just big enough to facilitate showing off any the rendering features of the engine.

But someone else may not see it my way. So let's talk about it, ya'll.

[Candescence]

Well, by those terms, it could easily be argued that having a massive area could also be a good showing of the engine's rendering capabilities. The Serious Sam games (and by extension the Serious Engine and its increments) were showcases of massive draw distances and massive areas that had an incredible feeling of scale, and that's as well as rendering dozens of enemies on-screen at once!

Having a simple showcase is what's already been done with Sonic GDK. We want to be able to separate ourselves from the UDK engine and be able to showcase the engine's own merits.

[Aerosol]

I can agree on that. I think those merits are in its rendering solutions though, not in its physics capabilities.

The other reason why I was thinking of a relatively small area first is because it's more practical. A huge area would take its toll on my laptop, unless certain parts of the terrain were generated procedurally by Mobius itself. Something in the scope of the Sonic2006 E3 demo from '05 would be lovely, but I don't know how practical that would be for me to create. A smaller area can still contain enough objects to show what the renderer can do. Same goes for most people's PCs, really. Games with vast areas like that stream the data so that your PC isn't trying to load the whole thing at once. I don't even know if Mobius is going to have something like that for the first demo.

I mean, when I say small, I'm not talking "Cornell Box" small. Something roughly the size of Sonic GDKs test map. Maybe a little bigger.

[Sofox]

Quote

full 360 degree movement in 3D space that functions just like the classic games did

By the way, which engine are you talking about here?

We won't be quite sure what rendering features to showcase until they are implemented, so until then just a good looking level.

I've always preferred large areas, but I'm not sure what'll need to be technically implemented for that to happen. As such, I think it would be best to start out with a small test level, before we get to the full Countryside demo. Once we've gotten to grips with the level, we can talk about expanding it.

A good test level will have variety. Some open sections, some tight platforming sections, a few alternate routes, and preferably good variety in terms of the Y vector (in other words, going up and falling down, not just an open plane).

Those are my thoughts, whoever makes the level will have the ultimate say in how it's designed.

[Aerosol]

Sofox, on 01 December 2012 - 10:56 AM, said:

Quote

full 360 degree movement in 3D space that functions just like the classic games did

By the way, which engine are you talking about here?

Both BlitzSonic and SonicGDK allow you to run through loops and upside down and shit, like the classic games. I've never thought that Mobius Engine's raison d'etre was to be another Sonic physics engine. I've always thought it was a 3D engine first, a Sonic physics engine second. A close second, but second nonetheless.

That's why I thought that making a demo area that served as a showcase (or even a benchmark) of Mobius's rendering abilities should take priority over making a demo area for people to play with. But it's not like this is my project, or that I have the final say. So I opened this channel of discussion to see what the consensus view was.

[Covarr]

When designing a game in the engine, the physics can be whatever the user wants, no? It seems to me that's not something that needs showing off nearly so much as technical things that other engines can't necessarily do as easily or as well.

[winterhell]

I think there is a confusion of the term "physics in the engine". For the gameplay of a platformer game (be it 2.5D or 3D) what is needed is collision detection between 2 meshes giving true/false and a ray-mesh intersection giving distance and angle. Even without quadtree optimized collision meshes, the speed is generally quite high for a single character. Not to mention the code fits in a single page. The rest of the gameplay physics is coding logic and, in this case, Sonic Physics Guide.
The other type of physics, the one that can be "showed off", are mostly just that, for show. Remember in Sonic '06 the boxes that can float around? Basically any rigid objects that roll differently depending on the relief they land on, explosions, falling debris, particles, fluids. Here an external library like PhysX or Bullet3D can help. As for gameplay, they are most useful in racing or puzzle games.

[Aerosol]

The physics themselves could be whatever the user wants, exactly. Hence my predilection for renderer prioritization.

[Sofox]

I think winterhell nailed it, there's a little bit of confusion between super advanced physics, and basic physics that will be needed to run the engine.

By the way, if we want more talk on the render features specific ally, it might be best to put it in the Renderer thread.

[Aerosol]

Oh, I understood the difference between super advanced physics and basic physics. It's precisely that reason why I favor working on the renderer and getting it to a certain point before doing anything else. It's a matter of integrating a physics library and coding behavior. Compared to writing a real time renderer with realtime GI, the physics are simple. I mean, not mind numbingly simple, but there's a reason why BlitzSonic and SonicGDK are built on pre-existing rendering technologies.