-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Splintered Core Official Thread - Design Update 8/10/10
- Thread starter soggie
- Start date
First piece of the soundtrack is done: http://craze.se/customers/splinteredcore.htm
@mondblut
Drugs... probably not as prominent as it was in FO2. Dogs, is that any surprise? They're great to have around in any apocalyptic event.
@Zed
South East Asia. It's just southeast of asia, and the musical theme is pretty close to what we have locally (surprisingly so, considering I never mentioned anything about our local musical style).
Anyway, he did a new version, and it's much much better with a deeper bass track.
Christian is an extremely talented guy.
Drugs... probably not as prominent as it was in FO2. Dogs, is that any surprise? They're great to have around in any apocalyptic event.
@Zed
South East Asia. It's just southeast of asia, and the musical theme is pretty close to what we have locally (surprisingly so, considering I never mentioned anything about our local musical style).
Anyway, he did a new version, and it's much much better with a deeper bass track.
Christian is an extremely talented guy.
JarlFrank said:
I liked that (both of them). Not bad.
Could be a bit darker, but not bad overall.
Jaesun said:JarlFrank said:
I liked that (both of them). Not bad.
Could be a bit darker, but not bad overall.
Moonstone's the tutorial level, which is set when things were still fine and dandy for the protagonist. So the tone in this track is pretty upbeat, relatively speaking. In fact this should be the "happiest" and most "hopeful" track of all towns.
The next one's one of the darkest tracks, being based in a town that's pretty lenient on slavery - Redwater. Stay tuned!
soggie said:
Awesome. Looking forward to hearing it then.
And we don't even have a dog follower planned... it's just on the concept art. 
But maybe mondblut will be more optimistic when we have a combat demo ready, because combat is the one and only important feature.
But maybe mondblut will be more optimistic when we have a combat demo ready, because combat is the one and only important feature.
I like the tracks.
Irrlicht? Why the change of heart from Ogre3D, only to go back to it?
Also, so much effort wasted which could be done relatively hassle-free with Unity.
You could try throwing in a little more ambiguity. Also, that sounds a bit too much like Old Camp / New Camp / Hippie Camp from Gothic 1, not that that's particularly bad. Thinking about it now, Vault City / NCR / New Reno was a pretty good political set up in FO2.
soggie said:
Irrlicht? Why the change of heart from Ogre3D, only to go back to it?
Also, so much effort wasted which could be done relatively hassle-free with Unity.
You could try throwing in a little more ambiguity. Also, that sounds a bit too much like Old Camp / New Camp / Hippie Camp from Gothic 1, not that that's particularly bad. Thinking about it now, Vault City / NCR / New Reno was a pretty good political set up in FO2.
denizsi said:
I was just fooling around with different engines. Irrlicht seems to be pretty easy to use, but its multitexturing capabilities are pretty questionable. I still like Ogre3d's material scripts.
It's good to test a few engines in the early stage, just so that you don't wind up with a hastily chosen engine and then regret it down the line.
Also, Unity3d CANNOT do what I want. I am 100% sure of it. The editor can't help me, and that reduces it to a closed-source engine with a C#-like language. What's the point? I'd rather have Ogre3d with its complete source code and tons of integrated plugins on my hands just in case I want to try out new stuff. That's why I dropped U3D early in the decision process.
denizsi said:
Of course. The above description is the general framework of the faction, which can be considered the official stance/philosophy of the organization. And like most organizations, not everybody subscribes to the hive mind, and there will be splinter elements. In fact, this theme is so central that the game itself is named Splintered Core.
There is an 70s' TV series, named Survivors; survivors after a killing global epidemic. There was a semi-military faction, remnants of an army with scientists, working to produce medicine and using it to trade. It looked like a pretty sensible thing to do and was nice to see in the show.
No objections if you know your programming but, uh, what was it that Unity can absolutely not do again? I've asked this before and you've given a sketchy answer about rendering 2D planes/building a 2D game world with 3D models (which has actually been done), which I didn't mind because of your programming experience. Perhaps you are putting way too much weight on the editor; it's not the end all of Unity. People are constantly creating crazy stuff, including their own editors to suit their own needs, all in Unity. Unity != game world editor with benefits.
soggie said:
No objections if you know your programming but, uh, what was it that Unity can absolutely not do again? I've asked this before and you've given a sketchy answer about rendering 2D planes/building a 2D game world with 3D models (which has actually been done), which I didn't mind because of your programming experience. Perhaps you are putting way too much weight on the editor; it's not the end all of Unity. People are constantly creating crazy stuff, including their own editors to suit their own needs, all in Unity. Unity != game world editor with benefits.
denizsi said:
Okay I'll try to explain this is the most straightforward way possible (which seems impossible because I haven't completely figured out how exactly to do it yet).
There are 2 common problems with 3d engines: (1) polygon limits and (2) camera controls. I'm sure all of you know the latter, which can't be solved even with fixed angles (especially when you have tall buildings that might get clipped in the camera's near clip plane). Polygon limits, while being very capable of rendering ultra realistic scenes in games, doesn't not perform well on older generation hardware. The last factor is pretty crucial as I can't expect my target market (indie game consumers) to always have cutting edge hardware.
So the question here is, how to insert highly detailed environments into the game without having it slaughter the hardware? This is where 2.5D comes in.
Take a look at FOnline and Total Influence Online. Both have 2D environments with 3D characters. The former for detail, and the latter for easily showing equipment changes and animation flexibility (with skeletal animations).
In order to do this, you need to draw the 2D environment on a flat plane using traditional 2D rendering techniques (with the only difference being the artwork are rendered onto textured quads instead), and the 3D character placed on the screen at the correct angle. In order to achieve a proper Z-order, we need to manually control the drawing order, with little to no help from the built-in z-buffer.
Now in Unit3D it is always possible to do this by manually placing all these things in the editor, but what about reference grids, grid snaps, and so forth? All these are crucial to isometric map building and unless you want to place the world by hand, I don't see how U3D fits into the picture.
Now about U3D's engine issues. Yes it is powerful, but without access to source code and a limited license (100,000 revenue before you have to upgrade the license?), that's a huge turnoff. Imagine if you wanted to try a specific rendering method, and found out that U3D only supports a specific way of forward and deferred rendering. You'd be limited to playing around with shaders to achieve what you need, when using Ogre3D you could have dug into the source and replace what you need. Arguably, U3D's plugin system might be able to solve that, but I believe that's not worth the trouble when you have all the source code in your hand.
Finally, we're talking about bulk here. I need a rendering library, not a full blown game engine. This is where Ogre3D comes in handy, because it does what it does best - rendering. I like specialized libraries like these.
I can type more but I'll stop here for now.
soggie said:
That is a design problem, not an inherent issue with 3D. Seriously, tall buildings? Come on, what kind of programmer are you to cite such a non-issue? For every 10 3D games with overview camera that got it horribly wrong, 1 got it right. Most recent example that I've played might be StarCraft 2 where the I've yet to experience a single instance of obscurity due to tall buildings or other structures and SC2 was full of them.
Unless Unity comes with Unity henchmen who oversee your development and put a gun to your head when you use low poly models and don't exceed a certain poly count, I don't see the problem here. Such a non-issue again. Besides, hardware-wise Unity is pretty flexible unless you start using the default bell and whistles features. User base of Unity doesn't exactly consist of the bleeding edge hardware owners.
You only have to upgrade to Unity Pro from Unity at that point, where the latter is actually free. I find that pretty reasonable and agreeable. Some people have also been granted the source code; they have an address specifically for handling source code requests. I imagine it would depend on the commercial viability of your project, your experience with Unity and your ability to convince you have the skills to see it through. They are pretty much hush-hush about licensing conditions, though. They probably handle these on a project-basis.
Invest in a month or two to develop your own editor -using Unity again- to do all of that just the perfect way for yourself, then. It's been done. You'll have to do that with any API anyway, otherwise content creation pipeline will be immensely cumbersome and what would take a few days to create a simplistic quest in, say, Bethesda's games could possibly take beyond a week. There are at least a half a dozen Unity projects where people have done exactly what you have described and not surprisingly at all since 2.5D is one of the oldest methods of achieving good looks with least resources and thus one of the most widely recognized way of achieving a goal in game development.
How fortunate that it doesn't. Community is crawling with custom rendering and lighting techniques, based on who knows what, like obscure papers some Russian published in some obscure indie-dev platform and they work. Some of them quite very advanced too, mind you.
For an experienced programmer, I can't argue about the value of source code vs. low-level scripting (ie. that's a lot more than just plugins) and plugins.
Unity is only a full-blown game engine if you need it to be. There are as many people developing non-gaming middleware using Unity as people making games.
Even though I'm at best a novice at programming (I most certainly couldn't endure to start from absolute scratch with just a renderer; it's just way too fucking much work without advanced libraries that I can simply adapt to and work around, instead of studying and revising), I can safely say that your knowledge of Unity is terribly criminally limited and skewed. Unity isn't a mere plugin based game world editor with them shinies. That would be like saying Excel is MSPaint+ with more text. That's the impression you seem to have of it, anyway. I probably sound like a Unity fanboy, what with suggesting it every now and then in random threads when the subject comes up, but I only speak of what I know to be true by experience.
Also, not that it's much of an argument by itself but just to add weight to it anyway: when Google goes out and picks Unity out of a hundred similar software to provide native support in their OSs and browsers, you know there's something to it.
Okay denizi, I'll take some time to reply things one by one. Hope I don't miss any.
1. Camera controls
I didn't say all 3d cameras suck. What I meant was that taking time off to wrestle with camera controls and logic isn't what I'm prepared to do. Simple reasons really - I'm not an experienced camera coder and I'd rather play it safe, save my time and go with something that I actually know and understand - 2d cameras and rendering methods.
Just to give you an example, every camera has a near and far clipping plane. If any object goes beyond these two planes, they get clipped and are never rendered. So the question here is how do you zoom in the camera enough to get the level of view you want, and how do you handle the camera clipping with structures along the way. It's easy to say that oh, we're only going to do structures no higher than 3 levels. So sayeth the programmer, which the artist or level designer would need to understand and stay on the same page to prevent nasty clipping issues.
Once you got that one right, you'll need to think about rotation, and zoom. How to handle the clipping plane with a dynamic camera position. Don't want to do that? Fine, lock it to X,Y axis and solve 80% of your problem. Then you'd have an issue of how to get units obscured by buildings to show up.
This might sound like a lame excuse until your level designer starts to design the level. With a 2D isometric map, things are relatively easy, especially if you choose to use a tile based placement. With 3D, you need to think of odd edges, which will definitely occlude some of your entities. Once that happens, because your camera is locked, you'll need to figure out a way to bring them out to the front.
You can draw a highlight around them, or use some fancy alpha blending techniques, but the question here is, how much time do you have to wrangle with all these issues when you can minimize them by doing something you know (for me at least), which is to use a 2D drawing method augmented with 3D character models?
2. Polygon Limit
First, I never said U3D does not allow low poly scenes. The whole issue is that there's a limit, which means in order to draw something like Fallout's autodoc, I'd have to make do with a low-poly model to accomodate for older hardware. Why do that when I can go full resolution on a 2D pre-rendered entity instead? Yes, you can probably create multiple models with different LOD, but then that's doubling and tripling the art asset work, which costs me money. I can't afford to pay that much on art assets, and I am not good in art creation (or patient enough) to do it myself.
I must clarify here that while I'm not an artist, I do have a certain baseline when it comes to artwork quality. I cannot accept myself creating a game that looks like Avernum, even if it has awesome gameplay. I do have a very specific art direction that cannot be easily implemented with 3D scenes, or would be too expensive to do so in terms of artwork commissions. Believe it or not, artists that I have talked to so far spend less time creating high-resolution pre-rendered scenes than low-polygon models.
Here's one of the reasons why. When you create a low poly model, what artists usually do is to create a high resolution version of it first. This is used to render the normal map, which is used by the lighting shader to shade the model (to make it look more realistic and to hide the fact that it is a low poly model). After that, they create a low poly model, rig it, texture it, and then send it over to me to put in the scene. This is twice the time taken to do just a pre-rendered version.
Of course you can skip the high-res normal map portion, but that would mean your low poly model would look LIKE a low poly model. Which is not what I want, aesthetically.
Note that I'm not talking specifically about U3D here. I'm talking about 2D vs 3D here, or more specifically 2.5D vs 3D.
3. The rest
Look, the thing here is that you expect me to use U3D just because... of what exactly? I am not saying that I can't make a game with U3D, in fact U3D is simply awesome because it has one of the best editors in the market. But right now I'm evaluating engines based on my own requirements.
I can do it all in U3D if I invested the time into it, but bear in mind of the closed source nature of U3D. It is pretty serious because like I said, while the techniques that I want to use might be do-able in U3D, I can't have the guaranty without investing serious hours into fiddling with the engine. Time is one thing that cannot be refunded in case somewhere down the line I realize that U3D doesn't do what I want, and then what? Duke Nukem Forever?
Think about it. Having an extensible plugin structure and a powerful scripting language does not mean it can do everything. Specifically, I would need to FIND OUT rather than digging into code immediately, which I can do with open sourced libraries like Ogre or even OpenGL.
The issue here is again, I repeat - time. I can dig in immediately in Ogre3D while I need to spend time to research whether or not U3D's architecture supports my idea. Time that I am not prepared to invest.
4. Conclusion
There are many things that are debateable in your points, but I think it's unnecessary considering that right now it is about a choice of an engine to accomplish a very specific list of requirements. And I am the one who's going to have to suffer through the entire development process, so it is my call to use something that I am comfortable with rather than jumping on the bandwagon for something that I am not sure with, based on what I've experienced and what research I've done beforehand.
It's like buying a ferrari just because they had won a string of F1 competitions when that good ol' minivan could bring your entire family out for a beach holiday complete with a canoe tied to the top and two bicycles strapped to the rear bumper. You choose a tool depending on whether or not it fits the requirements, not because it has tons of features that you won't ever need.
I'll leave this here, and say this: if you want to defend U3D on grounds of its capabilities, then there's no point for me to continue this debate. We both have our own valid points and there would be no end towards this argument, so I don't see a point in it when by the end of the day it is my list of requirements and the limited time frame that I have to complete this game that matters.
1. Camera controls
I didn't say all 3d cameras suck. What I meant was that taking time off to wrestle with camera controls and logic isn't what I'm prepared to do. Simple reasons really - I'm not an experienced camera coder and I'd rather play it safe, save my time and go with something that I actually know and understand - 2d cameras and rendering methods.
Just to give you an example, every camera has a near and far clipping plane. If any object goes beyond these two planes, they get clipped and are never rendered. So the question here is how do you zoom in the camera enough to get the level of view you want, and how do you handle the camera clipping with structures along the way. It's easy to say that oh, we're only going to do structures no higher than 3 levels. So sayeth the programmer, which the artist or level designer would need to understand and stay on the same page to prevent nasty clipping issues.
Once you got that one right, you'll need to think about rotation, and zoom. How to handle the clipping plane with a dynamic camera position. Don't want to do that? Fine, lock it to X,Y axis and solve 80% of your problem. Then you'd have an issue of how to get units obscured by buildings to show up.
This might sound like a lame excuse until your level designer starts to design the level. With a 2D isometric map, things are relatively easy, especially if you choose to use a tile based placement. With 3D, you need to think of odd edges, which will definitely occlude some of your entities. Once that happens, because your camera is locked, you'll need to figure out a way to bring them out to the front.
You can draw a highlight around them, or use some fancy alpha blending techniques, but the question here is, how much time do you have to wrangle with all these issues when you can minimize them by doing something you know (for me at least), which is to use a 2D drawing method augmented with 3D character models?
2. Polygon Limit
First, I never said U3D does not allow low poly scenes. The whole issue is that there's a limit, which means in order to draw something like Fallout's autodoc, I'd have to make do with a low-poly model to accomodate for older hardware. Why do that when I can go full resolution on a 2D pre-rendered entity instead? Yes, you can probably create multiple models with different LOD, but then that's doubling and tripling the art asset work, which costs me money. I can't afford to pay that much on art assets, and I am not good in art creation (or patient enough) to do it myself.
I must clarify here that while I'm not an artist, I do have a certain baseline when it comes to artwork quality. I cannot accept myself creating a game that looks like Avernum, even if it has awesome gameplay. I do have a very specific art direction that cannot be easily implemented with 3D scenes, or would be too expensive to do so in terms of artwork commissions. Believe it or not, artists that I have talked to so far spend less time creating high-resolution pre-rendered scenes than low-polygon models.
Here's one of the reasons why. When you create a low poly model, what artists usually do is to create a high resolution version of it first. This is used to render the normal map, which is used by the lighting shader to shade the model (to make it look more realistic and to hide the fact that it is a low poly model). After that, they create a low poly model, rig it, texture it, and then send it over to me to put in the scene. This is twice the time taken to do just a pre-rendered version.
Of course you can skip the high-res normal map portion, but that would mean your low poly model would look LIKE a low poly model. Which is not what I want, aesthetically.
Note that I'm not talking specifically about U3D here. I'm talking about 2D vs 3D here, or more specifically 2.5D vs 3D.
3. The rest
Look, the thing here is that you expect me to use U3D just because... of what exactly? I am not saying that I can't make a game with U3D, in fact U3D is simply awesome because it has one of the best editors in the market. But right now I'm evaluating engines based on my own requirements.
I can do it all in U3D if I invested the time into it, but bear in mind of the closed source nature of U3D. It is pretty serious because like I said, while the techniques that I want to use might be do-able in U3D, I can't have the guaranty without investing serious hours into fiddling with the engine. Time is one thing that cannot be refunded in case somewhere down the line I realize that U3D doesn't do what I want, and then what? Duke Nukem Forever?
Think about it. Having an extensible plugin structure and a powerful scripting language does not mean it can do everything. Specifically, I would need to FIND OUT rather than digging into code immediately, which I can do with open sourced libraries like Ogre or even OpenGL.
The issue here is again, I repeat - time. I can dig in immediately in Ogre3D while I need to spend time to research whether or not U3D's architecture supports my idea. Time that I am not prepared to invest.
4. Conclusion
There are many things that are debateable in your points, but I think it's unnecessary considering that right now it is about a choice of an engine to accomplish a very specific list of requirements. And I am the one who's going to have to suffer through the entire development process, so it is my call to use something that I am comfortable with rather than jumping on the bandwagon for something that I am not sure with, based on what I've experienced and what research I've done beforehand.
It's like buying a ferrari just because they had won a string of F1 competitions when that good ol' minivan could bring your entire family out for a beach holiday complete with a canoe tied to the top and two bicycles strapped to the rear bumper. You choose a tool depending on whether or not it fits the requirements, not because it has tons of features that you won't ever need.
I'll leave this here, and say this: if you want to defend U3D on grounds of its capabilities, then there's no point for me to continue this debate. We both have our own valid points and there would be no end towards this argument, so I don't see a point in it when by the end of the day it is my list of requirements and the limited time frame that I have to complete this game that matters.
soggie said:
Screen resolution scalability and asset creation flexibility?
I'm confused. What method will you be using, then? You don't want low poly models from 90s, you can't afford low poly models with high-res normals, where does that leave you?
No I don't expect you to do anything really, I just found some of your reasons to be out of touch with what Unity really is and saw it fit to clear whatever misconceptions there might be. Otherwise, all fair points. I wasn't particularly wishing for you to go for Unity. I don't have secret fantasies where everyone drop anything they are doing and run with open arms to Unity.
Screen resolution scalability is really a non-issue when you're rendering textured quads with an ortho camera to simulate a 2D scene. Asset creation flexibility, this one I'm not so sure what you're referring to exactly.
High resolution environmental artwork like I mentioned? Cut off the step to create a low poly version and then the corresponding diffuse texture, specifically. But anyway, while it's true that 3d level creations are more flexible, with the way my art direction goes, it doesn't really make any difference anyway, since we're practically creating one unique tileset for one town (well not really, but that's the general idea - each town looks different). To put it in 3d terms, you'd still have to get texture artists to bake different set of textures anyway, so the cost (at least I would think) shouldn't be that much of a difference.
Well, coming from a U3D user, that's not really unexpected. We all have our favourite tools, and as long as it gets the job done... The truth is that by the end of the day, every engine can clobber up a game if one invests enough time and effort to master it. Different tools, same results.
In these cases, I guess the results would pretty much be the only concern here, aint it?
High resolution environmental artwork like I mentioned? Cut off the step to create a low poly version and then the corresponding diffuse texture, specifically. But anyway, while it's true that 3d level creations are more flexible, with the way my art direction goes, it doesn't really make any difference anyway, since we're practically creating one unique tileset for one town (well not really, but that's the general idea - each town looks different). To put it in 3d terms, you'd still have to get texture artists to bake different set of textures anyway, so the cost (at least I would think) shouldn't be that much of a difference.
Well, coming from a U3D user, that's not really unexpected. We all have our favourite tools, and as long as it gets the job done... The truth is that by the end of the day, every engine can clobber up a game if one invests enough time and effort to master it. Different tools, same results.
In these cases, I guess the results would pretty much be the only concern here, aint it?
Which is exactly why we go for 2D with 3D characters: 99.9% of 3D isometric games have a horrible fucking camera. NWN 1 and especially 2, 7.62 High Calibre, even the AoD demo and Dragon Age (which has, in my opinion, a decent camera but it's still not perfect).
By going 2.5D, we can have more detailed graphics AND a camera that doesn't suck. Win-win situation. Also cheaper model work as Soggie mentioned.
By going 2.5D, we can have more detailed graphics AND a camera that doesn't suck. Win-win situation. Also cheaper model work as Soggie mentioned.
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.