Carmelle

They've already said that parts of it will be animated and such

Probably not, unless they build that sort of functionality in to begin with. Definitely possible, it's just a lot of work and a bit hard to do. I know there's at least some work and that have worked on creating procedural, real time and reactive animations. That kind of system might be able to do it, but it'd definitely cost a pretty penny to license something like Euphoria, and more to get it working well enough to do what you'd want, if it's even possible. And even then, they're not the greatest of animations....work really well for things like reacting to falls or things hitting them, but not so much for more nuanced movements.

That screen to me looks like it's designed to set the mood or introduce an area (whatever is behind those statues), not be a complete map itself. I doubt any sort of encouters would occur there...and it's definitely large enough to fit the heroes for that purpose. Especially if they have any sort of depth, so as you move towards the entrance the characters would become smaller still.

I still think of StarCraft on the N64...ugh......so bad :/

Recent? Hell, Age of Empires 2 is over a decade old. Lol, true enough. In my mind I was thinking more along the lines of the newer Total War games as the basis. But yea, even the older TW games and AoE2 and such had pretty decent pathing with formations.

Keep in mind that the Linux kernel also compiles on ARM, and many distributions offer full ARM support as well, including all (FLOSS) libraries and capabilities. As long as you're mindful of some architectural differences (like endianness, but those are things you normally encapsulate away early anyway), it doesn't matter on what of the dozens of architectures Linux works your program runs. I suppose that works fine for most things (basic libraries or utilities, maybe even things like SDL or what have you) but the main differentiator is still the graphics hardware. PC -> opengl/directx, ARM/Mobile -> opengl es/directx mobile. There's definitely game engines out there that work on both (I think Unity is one of them), but the game would have to be built with the mobile graphics hardware in mind, and with mobile hardware constraints in mind (memory, cpu, whatever). Plus at the end of the day, it's yet an entirely 'nother platform to do tests, validation, etc... for. And one where, unless touch-friendly controls were added, the vast majority of users wouldn't be able to take advantage of right now anyways. And then adding touch controls would likely either 1) gimp the controls for the PC version, or 2) Add on to the list of things that need to be entirely separately tested and such on the new platform. All in all, it's still a lot more difficult to go PC -> ARM, than it is to move between different PC operating systems or different Mobile operating systems.

Well, Unity does run on Arm with its mobile flavour, and I know that android supports a physical keyboard/mouse out of the box + hooking up to an HDMI capable display. That said, I don't think it'd be that simple. Although the industry is definitely shifting towards ARM for lower and mid ranged devices, it's a bit too early to say with confidence that they'd be able to ship for it down the road, let alone make it as a part of their roadmap. Linux/Mac/Windows at least share the same set of libraries and general capabilities (i.e. the PC). When you start getting to ARM based devices, you have to begin designing for the lowest common denominator. They're still vastly inferior in specs, input options, and more importantly the libraries which make things like 3d graphics possible (ex: mobile devices generally use OpenGL ES, not the full directx/opengl like the desktop.) It may be possible for simpler programs like Angry Birds or w/e, but it'd probably take too much out of the game and their resources to target ARM on their budget.

In this area, I would love if the game took a bit out of some recent RTS games that allow for formations... where you can have individual movement per character but as they move, have them try to adhere to a single formation too.

I absolutely love these kind of things, especially if they affect the gameplay or story going forward. Adds for replayability, and makes it feel like my choices actually matter. Plus the harder they are to decide on, the more likely I am to wanna replay the game and see how it would have turned out if I went the other way. << Possible ME3 spoilers ahead: >> Mass Effect 3 had me going for the longest time in trying to decide between Geth and Quarians, and once I found out I could save both by doing certain decisions in the previous ones, made me wanna replay them all to do so :/ heh. That said, it didn't feel as a big of a decision once you actually made it. Characters commented on it slightly here and there, but ****, that was just effectively planetary-scale genocide of an entire species. You'd think it'd be a bigger deal O.o

I don't really care about # of locations or maps or whatever, so much as the actual content that goes with them. Having 100 locations is useless if most of it is empty land imo. It's kinda how fallout 3+ felt for the most part. You had interesting locations interspersed with vast amounts of barren land which had nothing of interest, and were a chore to walk from and to. Luckily you could quick teleport to locations once you've discovered them though I suppose. Skyrim on the other hand wasn't as bad. It still has a similar setup, but as you're wandering through the map you find a lot of cool little things. Either the AI doing something interesting, some sort of encounter, random NPCs going about their way, etc..

Just thought I'd throw some light on a few of the topics I've seen discussed, as I understand them. Feel free to skip down to the TL;DR Just wanted to add some insight. On fractal-based textures: This is kinda cool, and it's however not too difficult to combine fractals to generate interesting looking textures for things like rocks, walls, brick, etc.. anything that's either regular and can be modeled mathematically (ex: bricks) or is very random (ex: sand). And you can always layer fractals on top of one another to add depth to the textures and make it difficult for the eye to detect any patterns or whatever. I used to do this a lot in my 3d work back in the day, i.e. procedurally generated textures. Placement of things could be calculated once on level load, and you switch out CPU time/ram usage for storage space. The problem with this is it takes some control away from the artists, and kind of goes against (what I think is) the design ethos of the project: to create beautifully hand drawn (or at the very least, hand placed) worlds, full of detail, variety and purpose. On the topic of compression: Generally lossy formats like JPEG don't provide a simple and hard-set conversion in terms of, if the original picture is x bits per pixel it'll compress down to y bits per pixel or whatever. From what I remember in messing with lossy encoders, there's a few different tricks you can follow. 1) One is encoding parts of the images as a composition of other parts of the image. 2) Another is doing heavy down sizing to different color or chroma channels that the eye can't easily distinguish (ex: blue/yellow). 3) And the third is replacing color information in the picture with an index. You develop an index of all colors used in the picture and assign each a number, then each pixel only has to store x,y,color-index instead of x,y,r,g,b and the index has a defined color per ID in only one spot per image (This is similar to what most loss-less formats probably do, along with other tricks I'm sure). 3b) You can then do things like, combining colors that are visually similar together so you remove some colors from the image too. The first two and 3b are what lead to things like artifacts appearing in the image. So what this means is that the amount of compression you get varies greatly depending on the entropy of the image itself. Lots of different colors near each other with very little stretches of one or similar colors = bad compression. But if an image uses lots of similar colors and areas where one pixel easily blend into another (like the IWD pic used earlier), it's easier to compress more. Just something to keep in mind with the estimations. And lossy compression is definitely viable for a game, you just wouldn't want to push it too far. On the topic of actually using/displaying the massive environments: that's much easier. They can be drawn in, and separated into, smaller chunks. Then you could preload blocks in the direction your character is walking, before they're rendered onto the screen. No need to have an entire aaaaaaaaa x yyyyyyyy 500 meg in memory at once. More likely though, it'll probably be some sort of 3d asset(s) that have textures applied to them. A building could be actually rendered in 3d and have a very detailed texture applied to it. Especially since they said that environments were being created in 3d first, and then modified in some sort of post process. Plus doing it this way would allow them to keep extra information that could be useful for pathing, occlusion, dynamic lighting, etc... And as for time it'd take to create the environments: I suspect there will be duplicated assets (either drawn in as some sort of brush, or actually placed as a separate entity within the game) all over the place to make it less work. Not *everything* needs to be unique. And by keeping them as separate entities, it could help reduce disk usage. 5 trees could be used 5 times each to make a small group, instead of drawing and keeping texture information for 25 separate ones. ### TL;DR: Fractals are cool, but detract from artists ability to really make the world their own. As for compression, it's hard to speculate on numbers without knowing more about the worlds. So really it just feels kinda pointless to me... Finding solutions and stuff might help, but things like EXR are already well known and used in 3d work, and I'm sure these devs know of a lot more solutions too. I'm not saying there's no point in discussing, I enjoy it Just saying, not sure how much we can offer the devs short of finding some magic and miraculous new way of doing it that most people have never done before But hey, if you do come up with something, lemme know, we'll go sell it Display/Creating massive environments, I'm pretty sure they have that on lock if nothing else. No worries

How do you know it won't be? As I already explained in another thread, the Unity engine is not the actual cRPG game engine for PE like the Infinity Engine was for BG. Unity is just a low-level framework and toolset on which Obsidian is building its own custom cRPG engine, which in turn will run the game content that will make up PE (and maybe additional games in the future). So how do you know that replaying of scripted battle sequenced will not already be supported by this engine anyways? It might very well be, for cutscene-like sequences etc. It all depends on how they decide to implement it though. If it's used specifically for cutscenes, then it's not necessary to design, develop, test, a UI to let the user make recordings, play them back, etc.. And they'd likely be able to cut development time by making it less generic and specific to the cutscene scenario. Anyways, when they do look over this thread, they may add it to some bucket list of "nice to haves" that fits after the "nicer to haves", since we also made it clear that it's not something that the community deems absolutely necessary either

I would love a day/night cycle, but having quests tied to specific times can be annoying sometimes. For example, in Skyrim and Witcher, every time you wanted to advance the day/night cycle, it'd take a while and you'd have to wait for really no reason except that the game engine had to load all the new lighting settings and such. But having the world react to the day/night cycle as it progresses is definitely something I would like to see. Right, but that's only two different light levels for (some of) the areas. You didn't get the sun moving across the sky or the shadows dhanging as time passed - it just went from day to night and back - which is the same as I expect to see in PE. Although backgrounds are "prerenderered", the game is still 3d itself. It's not 2d/sprite based. So objects like trees, buildings, characters, etc... can actually be their own 3d model (and I think they said they would be) and thus still cast shadows/react to light dynamically. I think the pre-rendered dealy means more along the lines that the 3d elements will be limited to a single orthographic-like view and will have a focus on more detailed texturing work rather than trying to create complex models, and then the ground itself would be static? I dunno. But there's a lot of tricks that can be done these days to make games look as good and far better than the old school 2d games, while still keeping the same feel, and allowing for newer effects like the day cycle and other dynamic lighting, dynamic or destructible environments, etc...

Personally, I absolutely despise ammo management. It becomes far too much work, especially with parties of several characters. I do like the quiver approach mentioned by Aoyagi though. For a happy medium, perhaps quivers that magically regenerated ammo over time (outside fights) or something. So you'd have some ammo for each fight, but would have to be careful with how you managed the ammo within a fight itself. Then the ammo management is restricted to strategic use within combat instead of managing an inventory with no real addition to enjoyment, only realism (eg. "oh crap I forgot to buy arrows at the shop DAMMIT" or "didn't buy enough arrows, UGHH" and your ranged character becoming useless.)

Good to know.. just to clarify though: I was referring to the 3d model itself, not the portrait. And the sort of disconnect that occurs if the model looks one way (or changes with gear or whatever) while the portrait remains static and looks another way.