[Open Assets] SRB2 - Community Build! - Full color Edition! (PNG)

This content may be freely modified and/or maintained by anyone.
Status
Not open for further replies.
Could you actually give more constructive suggestions/criticism on what can be done?

Tell me what's lacking, and what this needs to be redone entirely, I already have stuff in mind, but do you have any ideas you want to add to this project?

I can't say what TO add either. As I've worked on SRB2, I can't really say I'd like to change anything, as I'm satisfied with what I have at my disposal with SRB2. Except "TURN SOC INTO DECORATE PLZ" and "ADD MORPH'S SOC ACTIONS TO SRB2", which I've been shouting forever but I know will never happen :P

EDIT: Oh, and that nasty bug where Homing is useless. The sole reason Dumbventure is incompatible with SRB2CB... I think.
 
Last edited:
EDIT: Oh, and that nasty bug where Homing is useless. The sole reason Dumbventure is incompatible with SRB2CB... I think.
That's the first way findin out homing attack is broken on CB by playing Dumbventure. I though it was a socing error like if one of the custom enemies were causing it or Donkey Kranken was
 
"TURN SOC INTO DECORATE PLZ" and "ADD MORPH'S SOC ACTIONS TO SRB2"

Oh, SURE! That's not that hard to do, morph's stuff is easy to add, I'll certainly try adding decorate too

, which I've been shouting forever but I know will never happen :P
Slopes will also never happen. :P Nah, but seriously SRB2Morph SOC stuff would be no problem


Oh, and that nasty bug where Homing is useless. The sole reason Dumbventure is incompatible with SRB2CB... I think.

Oh yeah, that can be fixed immediately.
 
Last edited:
Since your starting it up again, will you consider giving slopes more "launch" like I suggested earlier? It'd make them much more gameplay useful and fun. Right now, running off a high slope at full speed still lets you fall downward like a rock.

It's sort of depressing.
 
Since your starting it up again, will you consider giving slopes more "launch" like I suggested earlier? It'd make them much more gameplay useful and fun. Right now, running off a high slope at full speed still lets you fall downward like a rock.

Up till now, slope physics are kinda "glued together" as in, it doesn't feel 'right' yet and consists of a bunch of tweaks to give the illusion of slope physics.

Actually, the only way to do it RIGHT and make slopes non-gimmicky is to give the entire game full fledged sonic physics. So the collision and everything has to be rewritten. It's a crazy thing to do, but I'll try it! (Don't expect anything though :P )
 
Last edited:
I'm so glad this is getting work on again. Since this updated was very bad. It had to much mess up for a finale release. Mostly crash a lot. C Fails when bots are added. And the MD2 mess up that was not in the 1st release of this mod.

So i'm looking forward to this update Kalaron.
 
Ok, so let's step it up a notch by really fixing this thing:

Short term:

Step 1)
Whichever version was the most stable, we'll work backwards from there:
Apparently, version 1.1 is buggy, and the last version worked fine for the most part, right?

Step 2)
Linux & Mac love - What are the errors the Linux version gets while compiling?


Step 3)
Fix any bugs the current version had


Step 4)
WIKI FIX!!! I haven't given good documentation on core features like slopes yet, that will change (and will have lots of pictures too!)

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

Long Term:

Step 5)
Stable version of regular SRB2 to report everything over to - Anyone familiar with SVN builds can say which version works to best?


Step Impossible)
Do a serious redesign of all the code & clean things up - I can't promise it, but I've been interested in doing something like that.
 
Last edited:
Are you really serious about redoing all the collision code?
Though I know absolutely nothing about coding, it sounds very hard. But I 100% support you and your ambitions!
 
Last edited:
You should also add Portals in general so people can also make maps like Valve's Portal games. There's already a few videos on YouTube.
 
And hell, while you're at it, put it into the Source engine for us. :3

Well actually, instead of going to Source, we could just go completely revamped and crazy on everything.

How crazy? Like crazy crazy, like Water shaders, indirect lighting http://www.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf, and full fledged physics engine http://code.google.com/p/bullet/

We could also redo the wad format with UDMF http://www.doomworld.com/eternity/engine/stuff/udmf11.txt add scripting DECORATE / ACS http://zdoom.org/wiki/DECORATE features from GZDoom, make a new Octree based system that's dynamic and makes every part of the map moveable like polyobjects.

And simpler yet still cool: I know it's at least possible to do Quake style lighting I.E. real light sources in addition to sector based lighting as well.

I already have many source code implementations of the stuff I mentioned which could be ported to this game engine.


And, yeah mirrors and portals are nice too :P
 
Heh heh, here comes the crazy!


Optimization

To seriously optimize any level, we can take advantage of OpenGL display lists/vertex buffer objects and grouping.

The main bottle neck with OpenGL mode right now is that when in renders a map, it must first break up geometry into triangles.

This isn't anything unique to this game engine, but as it is right now, the Triangulation it uses isn't stable(misses polygons sometimes) and thus BSP holes can be generated accidentally. (This error is a combination of the engine's poor BSP system and using non GL friendly node builders)

The game must convert any sector's shape into triangles, example:

From this

superior.poly.gif


To this

superior.d.gif


The so OpenGL must then renderer all these triangles EVERY FRAME and UNGROUPED.
This puts a tremendous stress on OpenGL as it renders things in the most UNoptimized way

What we can do is:

  1. Group the required triangles commands for drawing one sector into a unique display list http://www.songho.ca/opengl/gl_displaylist.html , or even better: vertex buffer objects http://www.songho.ca/opengl/gl_vbo.html
  2. We can do this at runtime ONCE and it might be even possible save this data to the wad file
  3. We then do this for entire sectors - we can then use the same vertex buffer object for the floor and ceiling if the planes are the same, effectively only needing to really draw both the ceiling and floor of a sector with one instruction
  4. We can even extend these vertex buffer objects for FOFS TOO since those can also share geometry with the sector below it, effectively removing render passes for many cases of sectors

-----

MORE CRAZY MAP EDITING:

Finer Slope Control

When UDMF is implemented, and since I now have access customizing a level editor - SRB2DB2 - we can modify the map editor to support PER VERTEX Z VALUES, which would make editing level geometry even more powerful - not to mention it would be possible to implement realtime previews with this new method of level design.

3D Obj Support

Another thing that would make sense between a fully implemented physics engine is to add support for Obj meshes - which are basically MD2 files but more powerful.

We could use these new obj files for any geometry in a level that's difficult to express using sectors or sprites, it's possible to implement editing for this in the map editor so a level can be fully previewed and worked on in real time

To ease organization, 3D models can be added to a wad file so the user doesn't have to go messing with a list of objects.

-----

These added complexities are just that - additions, the simplicity of the map editor and the core concepts are still there, which makes new features like this just a bonus for anyone who's already skilled in the current map format and editor.

An in-game auto-conversion for legacy SRB2 levels would definitely be another implemented feature which would allow users to enjoy classic SRB2 level in a new revamped engine without any extra effort on the user (or level designer's side)



These kinds of optimization and additions are cool for even more unrestricted level design/size and sector complexities, and this stuff is more than just random tests - this is revamping everything for less creative restrictions when it comes to making levels and scripting new things. - It's essentially making a brand new, completely open source kind of 3D platforming game engine with an easy to use map editor!
 
Last edited:
Actually, if there's one more tiny feature I'd like to see, its disabling the MFE cam and allowing the camera to clip through invisible walls. If you do that, I have an idea for a level...
 
MFE code is GONE now :) And that actually fixes a nasty crashing bug the old code had too

---------- Post added at 11:34 PM ---------- Previous post was at 11:22 PM ----------

BOT RECONSTRUCTION

I love the simple bots even in the current public release - but to be a serious kind of AI, we need to revamp those too, with something called PATHFINDING

It looks like this
2en5e2o.png


Basically, we give our bots a little help - We let our bots choose from multiple paths that are created by the level designer himself, taking into account if any jumping or special actions are required for a specific spot.

I'm still working on this, but when it's implemented, path finding will be automatic AS YOU PLAY A LEVEL. There's similar engines that have this kind of behavior (mainly Sauerbraten http://sauerbraten.org/ comes to mind) it shouldn't be too hard to integrate the game to the map editor so that it can actually SEND that path finding data as you test play your level. There will be console commands of course that lets level designers customize the waypoints, but I'll try to make it as straightforward as possible.

With pathfinding, bot racing AI's, and coop AI's can be greatly improved, even SHOWING you how to finish a level can be another extra since the pathfinding data is from how the actual level design plays a level. CTF AI's can rely heavily on this pathfinding concept too to efficiently capture flags. The real challenge is Match - bots must be aware of the level's terrain AND combat against players, but actually, combining the current AI's with pathfinding will be enough to make decent opponents for Match gameplay.
 
Last edited:
I have to ask: why are you using Halaa as an example of pathfinding? The pathfinding for mobs in World of Warcraft is notoriously bad, with them running over things that players can't possibly climb and becoming completely invincible should they ever end up in a situation where they can't find a path to their target.

Hell, I have no idea what that image is supposed to illustrate, because the mobs that populate Halaa are essentially intended to be non-interactive, walking back and forth on a preset route for you to bomb from the air. The only time they even initiate their pathfinding algorithm is if the player makes a stupid mistake.
 
Heh, it wasn't intentional - I just grabbed a random image to illustrate, didn't realize it was coincidentally from a game with notoriously bad AI.

-

He's a better example then:

2en5e2o.png


Waypoints are branching paths that act as guides for bots to traverse a level - as in, without running into walls, they follow and choose paths based on recordings of how a real person plays a level. For complex things like single player or race modes, bots can follow multiple combinations of these branching paths for less predictable behavior, or even path choices based on events that are currently going on (Example: If a player is near a bot, the bot can attack, then run away by taking the path that will go farthest away from a player, if the player is about to drown, it'll find the nearest path to a spring or air bubble).
 
Last edited:
I was fooling around with SRB2CB, when I found a way to type in colored chat without the use of an external script or config file.

Here's how I did it:
shot0000j.png

First press T and then push TAB then push a number 0-3, because 4-9 are basically the same colors all over again. Here's a guide for the colors:
0: White
1: Purple
2: Yellow
3: Green

Major bump

I found out about that in the 1.09.4 CB. It the same way as the 2.0.6 CB.
 
Nice to see you back in business Kalaron, I am thinking of making a small level that uses some of the features of this mod, like slopes and hang gliders. But I would like to know if the way slopes are set up will be changed or not, that way I can decide if I should hold off or not.

Question about the bot way point system, will it be able to pick special paths for each character, or will they all share the way points. And how will it effect custom character's abilities?
 
Status
Not open for further replies.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top