Sonic and Sega Retro Message Board: List of Overgrowth engine features we could use - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Page 1 of 1
    Locked
    Locked Forum

List of Overgrowth engine features we could use Because Wolfire does awesome stuff

#1 User is offline Candescence 

Posted 04 December 2012 - 07:55 AM

  • Posts: 1839
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
Overgrowth is the in-development sequel to Lugaru, which some people may know as 3D fighting game featuring rabbits. Overgrowth is looking to go above and beyond its sequel in so many ways, but right now, let's just check out the sort of features the Phoenix Engine (which also uses OpenGL) has that would be very much applicable to Mobius:

General Features/Features with their own vids:
- Intuitive In-game level editing (later improved in Alpha 169)
-- Brush Tool
-- Sky Editor
-- Decal Textures
-- Live texture, shader and script updating
- Detail Textures (demonstrated here,, textures that don't stretch when an object is resized)
- Live scripting
- Bullet physics
- Awesomium integration for UI and other stuff (such as a webkit-based colour picker)
- Procedural Animation


Features shown in Alpha videos:
- Alpha 108:
-- Decal Maps (textures on objects that tile rather than stretch when an object's size is modified
- Alpha 112:
-- Detailed Physics Modelling (physics objects have their own realistic center of mass that they rotate around)
- Alpha 114:
-- Partial Animation Blending
-- Active Ragdolls (ragdoll animations integrated with normal animation, in a sense)
- Alpha 115:
-- Colour tinting (objects can have their colour altered a via colour picker created using webkit via Awesomium)
- Alpha 117
-- Dynamic head/eye look
-- Automatic lip sync
- Alpha 122:
-- AI Waypoints
- Alpha 123:
-- AI awareness (limited peripheral vision, cannot see through walls, hearing)
- Alpha 124:
-- AI Pathfinding (via the open-source recastnavigation library and its companion library, Detour)
-- Jumping prediction
- Alpha 126:
-- Ragdoll transition animations
- Alpha 132:
-- Normal Mask can act as a tint mask (so you can colour parts of an object rather than the whole thing)
- Alphas 132, 133:
-- Smooth ledge-climbing and shimmying (just an example if we ever feel like adding something like that)
-- Dynamic collision ellipsoids
- Alpha 135:
-- Combining shadow volumes of nearby objects to avoid dynamic shadows overlapping
- Alpha 137:
-- Colour-tinted decal textures
- Alphas 138, 139
-- Detail Objects
- Alpha 141:
-- Abstract collision world
- Alpha 143:
-- "Mobility Bones"
- Alpha 147:
-- Automatic character mesh LOD simplification
- Alpha 149:
-- Procedural foot movement
- Alpha 153:
-- Splitscreen support
- Alpha 154:
-- Sounds are dampened by obstacles
- Alpha 155:
-- Weight maps for detail objects
- Alpha 156:
-- Common shaders use shader macros (to make them easier to maintain)
- Alphas 157, 158, 159:
-- Hotspot scripts
-- Parameter system for hotspots and characters
- Alpha 160:
-- Character colour palettes with colour palette editors
- Alpha 162:
-- AI keeps track of all nearby characters, including allies
- Alpha 163:
-- Automatic plant pivot points
-- Automatic plant convex hulls from point cloud
- Alphas 168, 169:
-- Detail object types can be modified in the level xml, and liveupdate works with detail objects
-- Overbright option for detail objects
-- Surface orientation parameter for detail objects
- Alpha 170:
-- Live updating for config settings
- Alpha 173:
-- Climb/drop pathfinding AI
- Alpha 174:
-- Nav mesh objects are no longer hollow, so AI can find jumping surfaces much easier
- Alpha 178:
-- Animated debug text using webkit (makes it much easier to see what's going on at a glance)
- Alphas 190, 191:
-- Attachment system for both weapons and non-weapon gear for both player characters and NPCs
-- Dynamic objects can be colour-tinted using the colour picker
- Alpha 192:
-- Time freezing (alongside slow-mo)
-- Appropriate controls for the parameter editor
-- Parameters for the entire level
- Alpha 193:
-- AI has slower reaction time to changes in target position
- Alpha 194:
-- Scripts can create, delete, rotate, scale, translate, change script paramaters, tints, colour palettes, and so on.

Whew! That's a long list. I'd recommend looking at all the Overgrowth alpha videos, even the ones that have features that aren't really relevant to Mobius, it's an interesting insight into Overgrowth's development process.

Feel free to add more stuff to the list that I may have missed or simply overlooked.
This post has been edited by Candescence: 04 December 2012 - 11:59 AM

#2 User is offline Aerosol 

Posted 04 December 2012 - 01:28 PM

  • FML and FU2
  • Posts: 9242
  • Joined: 27-April 08
  • Gender:Male
  • Location:Not where I want to be.
  • Project:Sonic (?): Coming summer of 2055...?
A lot of the features you noted at the top feel like "too much" for me. Most of the features present in the alphas also feel like "too much", but you noted that some of them aren't even relevant.

I can't comment on everything, but take the Sky Editor for instance. It's cool and all, but if we decide to implement GI, that makes it 1000x more complicated. Pre-baked GI is a shit-ton easier to achieve than even quasi-proper GI with dynamic lighting. Decal textures are handy, as are detail textures (which are more so, actually). But I'm not sure if the time taken to implement them would make it worthwhile. They're probably not that difficult to work in, though...

An intuitive map editor is a must, but not necessarily one that looks and functions like Overgrowth's. A map editor is essentially a 3D modelling app with functions that make developing levels for a specific game easier. Live texture and shader updating is also very neat.

The procedural animation features look like a lot of work for not much reward. What does a Sonic game need ragdoll physics (or ragdoll animation) for? And badnik AI isn't really going to need to be that complicated...is it?

I dunn though. Maybe modelling one engine's features list off of another's just doesn't sit well with me. Overgrowth is being created for a very different purpose than Mobius, after all.

#3 User is offline Candescence 

Posted 04 December 2012 - 02:00 PM

  • Posts: 1839
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
I simply made a list of potential features we could make use of, and included anything in the list that are potentially relevant, nothing more. What we actually want to implement is up to the team as a whole. It's simply a whole bunch of neat stuff I think Mobius could benefit from. ;)

To be fair, I think Overgrowth's interface is a good example because it's intuitive, simple, and powerful. I mean, good grief, look at what you can do with a mouse and a few keys. And there are other ideas already in the map editor discussion on how we can make our own map editor have its own unique, intuitive features. I should also point out that Overgrowth mainly relies on pre-baked lighting and stuff, with real-time stuff mainly for the sake of previewing (aside from dynamic shadows from moving objects).

The animation stuff (procedural and active ragdoll and whatnot) are mainly 'optional' in my opinion, though if done right, can add quite a bit of verisimilitude to the world rather than being gratuitous (though I think animation layering/blending could be quite useful, at least). The AI stuff is mainly for giving designers options, and badniks aren't the only things that'll use AI - bosses, followers (like Tails), and so on. Considering there's already a pathfinding and nav mesh library we can utilize, a chunk of the work would already be done for us. More AI options gives us more options for any kind of NPC, friend, foe, or otherwise.

I think the most appealing features on the list (aside from the map editor stuff) are the live update functions (for textures, shaders, and scripting), colour tinting (probably very easy to implement if we use Awesomium, and does wonders for variety), the scripting functions and parameters. They seem like the most worth it in the long run, in my opinion.
This post has been edited by Candescence: 04 December 2012 - 02:03 PM

#4 User is offline Aerosol 

Posted 04 December 2012 - 07:13 PM

  • FML and FU2
  • Posts: 9242
  • Joined: 27-April 08
  • Gender:Male
  • Location:Not where I want to be.
  • Project:Sonic (?): Coming summer of 2055...?
Well, it is a nice list of features to mull over :)

#5 User is offline Kharen 

Posted 04 December 2012 - 08:40 PM

  • Posts: 485
  • Joined: 29-October 11
  • Gender:Male
  • Location:Eastern Washington University
If Sonic 2 is any indication, you know that if people have Tails following them, they're going to find ways to torture him in the most horrible ways imaginable. Why not have an option to allow followers to utilize rag-doll physics? He doesn't lose rings or anything when hit, so it would be a fun little thing that doesn't hurt gameplay any...

...Although, I did just have an idea while typing this. Remember how a second player could pick up the controller at any time and instantly control Tails in mid-game? Imagine hidden collectables where you need to have AI Tails get rag-doll physics used to launch him to a normally unreachable spot, then a second player picks that time to take control and maneuver him over to the item. An entire gameplay mode dedicated to tormenting Tails for profit. I doubt it would actually get implemented, but I would love getting to do that.

#6 User is offline Sofox 

Posted 04 December 2012 - 08:53 PM

  • Posts: 86
  • Joined: 26-March 12
  • Gender:Male
  • Location:Ireland
Whoa, I've been going through those videos. A great insight into the development process.


The map editing is nice. Almost like a full 3d editor in game engine. We probably won't need to go full on with the editor. We definitley will need something in-engine for positioning power ups, enemies, goals and other items. For the core of the level, my idea is to have the base of the level made by a 3d moddler and exported to COLLADA. To compensate for lack of immediate editing, I think the engine should detect if the COLLADA file changed, and update the level accordingly. I'm also in favour of making as many things live update as possible, as the philosophy of making things as easy to change and update as possible is very present in this game.

Other stuff, like insights into the animation and view into technology like Awesomium for UI, are very useful. Kinda daunting seeing stuff like this since it shows how much needs to be done, but great to have another insight into how to approach something like this.

Thanks Candescence.

#7 User is offline Candescence 

Posted 05 December 2012 - 04:53 AM

  • Posts: 1839
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
No problem, I do what I can.

I can accept the compromise when it comes to the level editor, at least early on. Once we have actual gameplay and other core features up and running, then I imagine we can look into a more in-depth editor.

Most of these, I think, will likely be considered and/or added later along in the process when the 'core' features are implemented and working properly. We'll see what happens.

Page 1 of 1
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users