Sonic and Sega Retro Message Board: Candescence - Viewing Profile - Sonic and Sega Retro Message Board

Considering this is a Sega-published game that was highly anticipated by more than a few people...

The average review score on Gamerankings is roughly 39% right now.

Yeah. This game is riddled with bugs, the visuals are garbage, the campaign is far below par, the AI is generally bad, and the multiplayer has its own problems despite being the best of the bunch. Wanna see?






An ex-Gearbox dev is claiming that the development is an absolute mess and a two-bit studio did the main game while Gearbox only did the multiplayer. Sega and Gearbox are both denying this, but the ridiculous lapse in quality indicates otherwise.

I feel bad for the people who preordered it.

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.

Ah, Torque. One of the earlier 3D game engines to be sold to the public. Nowadays it's pretty much been overtaken by UDK, Unity and UE3 due to them becoming free to use.

However, what I wasn't expecting was for Torque to to all the way and become open-sourced.

http://www.garagegam...logs/view/21876
http://www.garagegam...logs/view/21875

It's an incredibly surprising and unexpected result that could result in good things for the engine in general, now that the community has the opportunity to build upon it themselves.

Might as well nip this one in the bud. One of the core parts of creating a 3D game is level editing, and you need a good WYSIWYG interface in order to easily create levels. But there are plenty of examples out there that we can use, so why not discuss how to make something, well, better that what is already there now?

Over in the Generations Hacking Topic, a few peeps and I were discussing how to improve ease of use for creating custom levels. And it became blatantly clear to me...

Creating 3D assets is fucking complex. But does it neccessarily have to be that way?

Candescence, on 06 June 2012 - 08:45 AM, said:

So, that results in a few ideal goals that I think should be necessary when it comes to what I call the "Minecraft Creation Philosophy":

• Something that literally anyone can use with very little learning (with more advanced tools for various applications)
  
• Something that allows designers to create unique setpieces and worlds with just a limited set of 'building blocks' (not necessarily blocks, duh)
  
• Allows collaboration via LAN or over the internet
  
• That is fun to use
  
• That can be be customized to suit the needs to the user

How can these goals be achieved? I'm not sure right now, but I have examples of such a philosophy in action:



FyreUK are very prolific Minecraft builders, who have gained a huge following for their creations and timelapses. They gather a whole bunch of people together, and then start building shit. They make stuff in hours that would take professional dev teams months to create - because Minecraft, despite providing only a limited number of 'blocks', allows a huge range of creativity, building is extremely easy and only limited by imagination, and these people are working collaboratively in groups. And, best of all, they do it because it's fun. Making things becomes a game in itself. That's why Will Wright made Sim City - he thought that creating levels in the level editor in his last game was more fun than the game itself.

Mind you, we're talking about creating a level design interface for more complex things than just a bunch of blocks put together, but the closer we can get that ease-of-use, collaborative ideal that promotes creativity, the better it'll be. Sometimes the best solutions can be simpler than you realize.

Discuss! What can be done to make the best 3D level creation interface we want?

Now, considering this is a 3D engine and all (and I want to reinvigorate discussion in this section), I figured that this stage in development warranted some planning for assets for actually testing the renderer. After all, without 3D assets, we can't actually render any pretty pictures, now can we? And then there's stuff like collision and whatnot for when we actually get into physics and whatnot.

What we need at this early stage, IMO:

- A Sonic model, with proper animations
- Basic level geometry

Neither of these have to be fancy at all. The Sonic model could be pure crap, for all we. Pretty simple, right? Of course, we will have to test these in various model formats to make sure they work correctly, but baby steps. As we move along in development, we'll need more assets to test the engine and eventually showcase it, but that's a while off, yet.