'Balancing' & 'Modernization' about opentesarena

[afritz1]

Thank you for your input. This is the first actual feedback I've gotten! I honestly don't know how popular this project is going to be, so I suppose I will just adapt as it goes.

This is, in reality, my first considerable project, and it's more of an experiment than anything. I get to use SDL2, OpenCL, and FMOD directly, which is great practice as well, but I'm noticing that it's a little hard to really do all that I want to do because of a general lack of a tried-and-true code design.

I've played around a bit in Daggerfall Unity and I like how that project is progressing so far. I decided not to use Unity here because I wanted the experience of building something from the ground up myself without using a development program such as Unity. In my opinion, though, I think a better remake of Arena could be done using an "Arena Unity" approach, and that's likely something the Daggerfall Unity developers have already considered doing sometime in the next few years.

My primary objective with this project really was to demonstrate that a newer rendering process -- ray tracing on the graphics card -- could be used for some real-time games now. There isn't a single line of Direct3D or OpenGL code in this project, and I don't plan on adding any (yet). Several graphics programmers these days are only familiar with those older frameworks, and I want to be part of the group that shows that not all GPU-accelerated games have to be done with them today. OpenCL isn't a holy grail by any means, but it does make a significant enough departure from the traditional pipeline with much-needed flexibility that makes it worthwhile to develop with.

I will certainly take your comments into consideration and I'll revisit some of my designs in the coming weeks. Very few gameplay plans are set in stone yet, and the Readme I wrote is mostly just a brainstorm of ideas mixed with my original vision. I have already been using the manual as a kind of specification since the beginning, too. If this project really does gain traction, then I will be able to accommodate more options for various player preferences, but for now, I will use your advice with regards to recreating the game before altering it.

[Ragora]

It's been a viability since computer processors started getting powerful enough to do complex software rasterization. In fact, the ray tracing should be faster (depends on scene complexity, number of passes and so on) with enough threads on a regular CPU given the simplicity of the game world we're dealing with here. My FX-8350 should be able to do that (especially since it's overclocked slightly to 4.2GHz), though it will be at a detriment with only 4 FPU's to 8 CPU cores. The mid range i5's and i7's I would figure would be much, much better than my FX at it, too.

[afritz1]

I don't expect a typical CPU will be able to render my ray tracer in real time here. It's going to be quite computationally intensive, in fact. That's the whole purpose of using OpenCL for GPU computing instead of a software-based solution. I'm not just doing a simple upgrade or copy of the original Arena rendering here.

The game world is intended to be populated with hundreds or thousands of triangles gathered from voxel and sprite data (just like an ordinary rasterizer would use). A good ray tracer must have some kind of ray intersection acceleration in order to deal with all of these shapes efficiently, and so my ray tracer will use a uniform grid acceleration structure (essentially a 3D voxel grid) for each ray to walk through using the 3D-DDA algorithm (it's an extension of Lode Vandevenne's ray casting algorithm to 3D).

The current (unfinished) version of my ray tracer (the one the sample images came from) uses that voxel grid algorithm mentioned above, and it has proven successful in small test cases with the cities depicted in the sample images. The sprite intersection currently uses a naive for-all-entities loop, which is something I will fix -- using a handful of clever methods -- before the full ray tracer goes into this project.

The reason why the game world in OpenTESArena is just red/green/blue gradients right now is because I'm not finished developing the ray tracer yet! Those gradients are placeholders indicating ray directions coming out of the camera (X=red, Y=green, Z=blue), but they could in theory become sky and sun colors now, because the sky doesn't require any geometry to render.

[Ragora]

If you look around, there are applications/libraries capable of realtime on the CPU, though usually with a more high-end processor (likely Intel). Usually with heavy use of whatever specialized CPU instructions your device supports (like the various SSE versions, AVX, BMI, FMA3 & 4 and so on).

As I said, it depends on the number of cycles, desired resolution and scene complexity (not strictly geometrical complexity -- includes things like reflections, refraction and so on).

I've seen mentioning that https://github.com/szellmann/visionaray can be compiled to CPU code or CUDA code, and in one instance the performance was roughly the same. I have yet to actually try it myself, but I have no real reason to believe a CPU (possibly mine) can't deal with the game world provided by TES Arena. Overall, the GPU would just be better but the CPU should be able to at least do it.

[afritz1]

I think we can close this issue now. It has been a welcome reminder to me for the past year on how to approach the project. Early on, I did have some trouble figuring out my vision because I didn't know what I was capable of programming, but now, judging by the current state of the engine, it seems very probable that this will turn out to be a solid replacement for Arena in the end.

Back in June last year, before the Linux crowd found the project, I was still set on using pre-converted assets for everything because I didn't think I would be capable of decoding all the old data formats. But looking at where we are now, with most of the important data formats either decoded or almost decoded (thanks to some great assistance from a few people), it is now clear where the project is going. I'm frankly shocked at how far we've come already.

FMOD and OpenCL have also been replaced with OpenAL Soft, WildMIDI, and a software renderer, so it's looking pretty on-target for being an accessible FOSS project.

I completely agree with you @Demorde on replicating the look and feel of the game. Design decisions are being made with a close eye on the behavior of the original implementation now. I decided to add two options for the interface mode since I felt it was important to have the old-fashioned behavior along with an option for a new-and-improved layout. Classic mode is identical to the original, and Modern mode is for the new "quality of life" features like free-look and WASD to move. There's also mouse-drag to attack (although nothing to swing at yet), and it's looking basically indistinguishable from the original game at the moment. I just added text triggers recently, too, so you can see lore text about "drips from the ceiling" and stuff in places like the start dungeon (although it's kind of ironic -- the ceiling is missing at the moment, ha).

Anyway, thanks for helping set me straight early on.