Well I think we where talking about doing a little of both, jump&run and adventure. We want the game to feel like a sonic game, where the main point is to get from point A to B be within a 10 minute time frame. On the other hand, just in like the eariler sonic games, if you explore the level a little you can find secret stuff. I'm not sure what exactly, maybe some development stuff like with the Krypt on Mortal Kombat, you can get secret pictures of stuff done during development. On major problem that I have found myself, with the Sonic 1 Physics, is that Sonic runs too fast for these little exploring levels. Like the Red Sands test level. My first problem was I had bought a Xbox 360 controller for my computer when they first came out, and d-Pad on this thing is horrible. So I hooked my Playstation controller up to the computer and it help so much in playing this game. I still found myself struggling to keep sonic on the level. Like tapping the d-pad back and forward to keep sonic steady. I hooked my Model 1 Saturn Controller to my computer and what an improvement, but still struggle to keep sonic from running his fast ass off the level. When definitely won't be a sandbox game, you could try to use it as one, but you will die every 10 mins :D. The rotations are good and bad. They are good because they can make the game rather interesting, and also make a small level large very easily. For example run all the way to the right, rotate the level, run all the way right again, and you've just taken a small level and doubled its size. It can also be bad. It can make the game extremely, excuse me xtremely, confusing, and impossible to play. Which would be interesting for some final levels, but to make the whole game like that would just be aweful. There are badnik sprites, but the only place I can think of finding them right now is SoSt, and I think their site is infected with viruses. So I wont linky. Overall developing the levels is so much harder then we though. Expescially designing ones that have already been made. Finding screenshots of the level and trying to see where it lines up with other screen shots. Not to mention Jade Gully... So many screens shot of the level, and none of them line up. Jade Gully level looks pretty messy too, not sure how much of it we are going to copy.
I have to say, I'm xtremely excited for the things you've shown for Sonic Xtreme thus far. I know it may take several years yet but when it comes out I'll definitely be looking forward to it. Well, if that's the case you should change them. They may be accurate to the Genesis Sonic games, but Sonic Xreme's style is very different from them. Part of good game design is figuring out a balance between controls and gameplay style. I can see how the fastness of Sonic from Sonic 1 could cause you to run into things or fall into pits because of the fish-eye lens. It could agitate players. It'd probably be better if the fish-eye lens were removed but then this wouldn't be mimicking Sonic Xtreme very well, seeing as that was what made that game different from others at the time. :P
We're planing 2 versions of the game, The "labeled" PC version with the super crazy Fisheye lens, and E3 version with a toned down fisheye lens effect. the above version of x-treme is current project. hope that puts you at ease with is almost non existent fisheye effect. In the above video we can adjust the fisheye effect on the fly, and( not in the video) disable level rotation sections, via model texture ID, Theoretically, it would be quite easy to do both games with the same engine, as well as slap in classic levels for some 2.5 D fun. the hard part will be modeling all the levels lol
I made this after 3 days of work. It will eventually become a full-on level editor, but for now we are going to use it to place and delete objects per each level. It saves the file in real-time, so it seamlessly loads and unloads the saved file which contains all the objects stored on the level. Andrew has created a few new things to add to the level editor that should make it a little less annoying to use. In the video, I made a plane. Anything below the plane would not be rendered. Then when you moved it would allow stuff to be rendered again. This was done so it is easier to see how high you where in respect to the level. Without it, the user would believe they are on the right height when in fact they are not. After I made the video, Andrew devised a new system that would simply use a semi-transparent plane that would allow the user to see the entire level and still be able to tell how high they were in the level. This idea has not been applied in the video, and was devised so that the flashing level wouldn't induce a seizure.
Will the level editor support custom textures? If I like the game enough I may want to make some full-on level packs. Also, will the final version still have the "pop-in"? The objects in the distance suddenly appearing? It's kind of annoying, really.
You mean something like my conceptual level editor I showed off back on page 2 of this topic? lol Hey! Yes you may eventually see a fully featured level geometry editor in the future. We have some of the base technology set in place already, like realtime Vertex weld. You will be able to make and load custom textures into the editor yes, However the editor does not actually export physical objects or textures. It does export Position and item type to an external file with which the game engine than reads the file and places the appropriate objects where they should go, You will be able to set up and add your own custom textures in the level editor, However They will need to be import into the game engine as well.
There's a better technical term for what I'm talking about. But you see how when the game is running that blocks just appear in? "Pop in" as one might say? That was a graphical gimmick in the original game, due to the hardware limitations of the Saturn, but really it would be off putting. What if there was a pathway off in the distance that users couldn't see because it hasn't appeared yet? The same bug is in the other physics test videos. The only video it doesn't seem to be in is the one where you are adjusting the fish-eye. EDIT: Actually, looking at the video again, the pop in doesn't occur in the grassy level. :s Another edit: In that editor mockup, it says it will only support cube shapes, but some videos show "loops" and curve-shaped pathways, as well as some hexagonal tunnels and slanted sides. I notice in the Physics test 3 there's a path button, as well as a path button in the editor mockup. The slanted tiles can be food for thought though. Also, I'm not trying to heckle you guys or anything. I'm just really excited about this project and as a result am just very passionate about it.
Yes the pop in does not appear on Jade gully (grassy level). the first level , was built as a quick un-optimized testing level. The question of will there be pop in or not. It all depends on how or if I need to break the levels down into smaller chunks. we're still in the testing phases with this. Right now our levels are not built of cubes( the green grassy one), levels themselves are a single mesh without any holes or leaks in the geometry. With this there is no popin whatsoever. however the frame rate will suffer, I'm experimenting around with breaking up the level geometry into smaller chunks, which boosts the fps up quite a bit. In some instances gains of 60 fps or more. (don't forget, I'm on a super computer, check my Sig) With that there will be pop-in off in the distance. The technacle reason there is pop-in in the first place with the cubes is that The combination of the fisheye rendering in an off-screen direction, and that the Ult 3D game engine, doee not draw Geometry off-screen. causes visual pop in. but since the Jade gully model is a single mesh. ult 3D keeps it from disappearing since its not an off screen object.
Ah, okay. That explains it perfectly. So with that in mind, I don't suppose there's a way to render off-screen geometry? (I've never developed or really examined how a 3D game works, so if that's an ignorant question, tell me!) I have a few hypotheses but they won't prove useful most likely. Yes, I can see how rendering the entire mesh at once can cut down the FPS - my experiences with Minecraft tell me that much - I was told that rendering all those vertices can be taxing on less-than-modern hardware, which is the case for me.
In response to your edit. Yeah we got lots of slanted cube shapes in the game already. as for the moc up, it was a quick and dirty mock up, not every feature was put in. its hard to go over every detail on whats going on behind closed doors with the project. you see that green hill zone loop we tossed in the Red sands test level? It was tossed in for testing different types of angles. ya we have a few plans set in place for off-screen geometry. won't go over all the specifics till we do more fiddling around. We may be able to push the pop in distance back quite a bit with code. That part is up to Xeniczone,
Showing off my new custom Redsands texture and test benchmark stage, (stage wont be in final game) Fisheye position related to sonic has not been finalized quite yet. (WIP)
Is there a cap on the polycount for levels when using the level creator? Or is the engine designed to work regardless of how many blocks I'd drop into it without lag? (fade-in graphics and all that jazz)
In its current state the level editor does not build levels, it just places objects like rings, enemies ect, The levels are built in a standalone 3D application like 3D Studio Max. than imported to the editor for object placement. there is no limit for placing objects. I placed 2,000 + without any slowdown. When it comes down to it, you will only be limited by your systems specs. Also its not as simple as placing blocks to build the levels, levels are curently being built by polygon faces which are welded together to form a single mesh, This allows for better performance on lower end systems. When we get to the level building part of the editor, I'm sure that there wont be any limit on polygons, and the welding of vertex will be automated for the user.
Amazing Red Sands shot, it really is quite breath taking how much you stuff you have rebuilt by hand. Like I was saying to you on MSN, it's very impressive that a two-man team has made this much progress. Keep at it your work is amazing!
Ah, I see. I currently do all my modelling in Autodesk Maya.. -will I be able to create levels in that too or will I have to buy 3D Studio Max? Which file-type are you using to save the models in? Oh, and how do texture imports work, will it just use the ones mapped onto my model within the application or will I have to re-map them all in your editor? Is everything I model going to be solid? For instance, if I add a flower patch to a stage, will it be solid or can I set it so that Sonic can run through them? Sorry, this is a lot of questions. Hopefully this means I should probably be able to create level-packs for this engine fairly easily once the project is done though. (I'm assuming it'll work on my tri-core computer with 4GB of memory and a nVidia G210 512MB? Or would it lag?)
yeah your computer should be able to run Xtreme. The supported format is 3DS for user made levels. There are plenty of converters out there for the format. when we get closer to completion, I was planing to wright up some level design tutorials for Max users. However, that may not be the case for when the level editor is finished. you guys may not need to model in external programs anyways. For now I can tell you that Textures are handled by Texture ID on the polygonal level in the modeling application. You will need to assign a texture ID for the desired polygon and apply the texture to it in your package, ( in max I use Multi/sub materials) than drop the applied texture into the games texture folder. 2 ways to do Flower patches. User would need to place there spirit into in the game via level editor(and in game engine's GFX folder). This way the game engines billboard system can rotate the game spirits accordingly to camera angle. Or We are using 2 models for the levels, 1 for collision and 1 for graphics, So you can built the collision model without the flower patch, while the graphics model has the patch. The underlaying technology behind AXSX is pretty complex for building levels. its not as simple as just dropping levels in. When your modeling, Quite a bit of work needs to be done on the collision model so the game engine knows what does what at where, P.S. Details on Modeling requirements, like Model scale and other random settings will be covered at a much later date.
A really awesome project and kudos to all the work you already put into this project. You archieved a lot and your videos and posts are a great insight in project development. There's just one question that bugs me: if I'm looking at your rig, I can see it's quite powerful, so I wonder if there are high system requirements, when released... I don't care, I have a good system aswell, but I think some potential users could be disappointed. Or is it a decision, that hasn't been decided in this state?
Prior to this reply, AXSX was ran on my neighbor's AMD 64 single core, 2 gig memory, with ATI HD 4600 card (AGP card) For you Geforce users out there, 8800 would run the game just fine, although I think this is the borderline. anything lower , I'm not sure how well it would perform, we'd have to send some benchmark kits out sometime.
If you could give an estimate, about what year do you think you'd have had to buy your computer in order to be able to run it? I have a 2005 and a 2008 computer for example as well as a 2007 Laptop.
