next »

[vdapps]

-== RTG ==-

is the puzzle / platformer game in development which will combine 2 principles:

- classic 2D puzzle / platformer gameplay
- in-house software ray-tracing algorithm for rendering.

Idea for the game was born when I was browsing through my 17-years old source code (ray-tracing demo), yet from the times when I just finished university. As the game will use software ray-tracing for rendering, no special graphics HW will be required to run the game. Because ray-tracing is very demanding algorithm, game will need to be low-poly and low-res (which is hardly an issue in indie game). The game will be integrated with my simple 2D editor / engine, in which I made my previous game Universe Quiz. As the game will be puzzle / platformer, combination of 3D ray-traced rendering and 2D engine / editor for game logic will be feasible.

RTG webpage >>> https://vdapps.net/rtg
RTG on GameJolt >>> https://vdapps.gamejolt.io/rtg

And finally, some WIP examples:

Sample of rendering from my fore-mentioned 17-years old demo

Test level for lighting model testing

Carriable boxes level example

Carriable light level example

[vdapps]

-= Devlog #1 =-

I plan to update this devlog with at least every 2 weeks cadence. As the name of the game suggests, game world will be rendered using ray-tracing algorithm. Original idea for the game came to me when I was checking some super old sources from my early twenties, which I wrote 17 years ago. I was just finishing university and aspiring to enter game dev business (in which I succeeded, as I started as junior programmer in Slovak game dev company Cauldron later).

Fore-mentioned old C++ sources were ugly as hell (comparing it to my today's coding standards as senior developer). My obsessive-compulsive reflexes obliged me to rewrite and re-indent that code, as I was not able to stare at this coding mess and live with the fact that it's my own code.

More I indented the code, more ideas came into my head to possibly build some game above this algorithm. When I finished refactor, decision was already done. So here it is. What you can see as the first devlog showcase is the visual output of the fore-mentioned demo.

[vdapps]

-= Devlog #2 =-

After 2 weeks, devlog update.

First things first, before implementing any gameplay mechanics I had to optimize current ray-tracing algorithm as it was too "academic" (not meant originally for making a game, but as just mere showcase of ray-tracing algorithm).

To tweak the algorithm I needed some good test case, and to have good test case, I had to implement some dynamic creation of geometries. Thing is that original demo with chessboard and one figure was brutally hard-coded, so not very suitable for optimizing. After implementing dynamic creation of geometries, I prepared new test case. The same reflective chessboard, but now 64 boxes over it and 2 light sources floating around.

As expected with heavier scene, frame-rate and "ray-rate" dropped significantly. So I headed up into optimizing. In scope of one week, I was able to improve performance around 2 to 3 times. Same scenario, before: ~1 MRays/second, now: 2,7 MRays/second.

Optimizations done:
 - move from double to float in most of computations (to save bandwidth)
 - optimized ray vs bounding box intersection search (most abundant geometries in game will be boxes)
 - objects clustering (first find ray vs cluster´s bounding box, if hit, then proceed into cluster to particular objects)
 - small tweaks in parameters passing in algorithm call tree (there are millions iterations per second through same routines. Any saving in most invoked routines is important)

I have more optimizations in mind, but I think now it's better to do some gameplay prototyping first. So hopefully with next update, I´ll be able to show off some first gameplay mechanics. ¡Hasta pronto!

Short animation (animated PNG) from current test scenario (2,7 MRays/second)

[JobLeonard]

Ooh, I am so down for this! Looking forward to more dev updates on your explorations of software-based raytracing

[vdapps]

Ooh, I am so down for this! Looking forward to more dev updates on your explorations of software-based raytracing

Thanks JobLeonard!

Yep, one can play with ray-tracing algorithm and tweak and enhance it all along. On the other side, I need to progress also on gameplay, so I'll interleave. Moving forward with gameplay mechanics, if I'll see that I'm dropping under 60fps, ray-tracing tweaking, then progress in game again, then add some new ray-traced FX and so on.

[vdapps]

-= Devlog #3 =-

Next DevLog update, now a bit sooner as is my planned "every 2 weeks" cadence. Last time I planned to implement some game mechanics, however I realized that better would be to implement editor integration first. Reason was that everything until now was a bit hard-coded on C++ side. I have already simple 2D engine with editor made in C# in which I made my previous game Universe Quiz (here's the link if you want to take a look: https://store.steampowered.com/app/1211100/Universe_Quiz/).

My ray-tracing engine is naturally 3D, engine / editor is 2D, but it's no problem as the game is going to be puzzle / platformer. Even if what you'll see in the game will be 3D in nature, game logic will be mostly along x and y axes with camera looking into level from side, so 2D engine / editor will suffice. Editor allows me to place elements into scene, those elements can have properties. All elements and properties have auto-support for serialization, elements query and properties change at runtime, either from C# or from built-in simple script language.

What I had to do is to make new elements for this editor which then will translate into ray-traced game world objects at run-time. This way I'm be able to edit / manage world from editor and more comfortable C# language (or from my script) using all underlying goodies of my engine, and ray-traced algorithm in C++ will be just interpreting current state of world.

That said, I integrated first elements: RTBox, RTLight and RTGActor. To have an idea, here is a screenshot of editor and how looks VERY first test level in it.

After basic editor integration, finally I was able to implement some basic gameplay mechanics. So, I started with basic gravity and player vs box collision. Together with fore-mentioned test level (one actor, one light source and few boxes), voilà, it results in such "gameplay":

As a next step I want to make first few levels (simple tutorial levels) which will resemble intended look and gameplay of final product.

¡Hasta pronto!

[JobLeonard]

Niiice, and that gif looks solid!

[vdapps]

Niiice, and that gif looks solid!

Thanks! It's very inspiring for me. Now I finally started on very nice part of development. Namely implementing game mechanics and specific game elements, which will be present in final game, so game will start taking a shape. I can't wait to post new devlog.

[vdapps]

-= Devlog #4 =-

In last 2 weeks, my pace was not so fast as I hoped, but anyway, here it is. After lot of just algorithm testing and basic prototyping, which I made before, I wanted to do first elements in game which will resemble intended final look and gameplay of final product.

Naturally, first thing first, I made "first level". Very first levels of game will be in fact just tutorials which will teach a player about basic gameplay mechanics, interactions and puzzle elements. In first level it will be just movement and basic interaction, in second level it will be also jumping, etc, etc..

In very first level (shown here in animated gif), there are 2 important elements shown. First is "terminal". Terminals will be scattered through game and apart of giving you important info and hints, player will be able also to unfold a story behind a game by accessing them. Second element here is just end-level "portal". Goal of every level will be to get to the portal. After interacting with it, camera will leave upward, while screen will be blank, new level will quickly load (in milliseconds) and then camera will roll to new level from downward. Level switch should be super-fluent.

So not as much as I hoped, but here's first version of Level 1. Basic movement, accessing terminal and leaving level.

[JobLeonard]

It sounds like quite a lot of progress to me tbh, but I don't know what your original ambitions were of course

[vdapps]

It sounds like quite a lot of progress to me tbh, but I don't know what your original ambitions were of course

I wanted to implement also level switch and 2nd tutorial level (jumping). 2nd level is no problem as everything needed for it is already implemented, but quick level load in fraction when you see blank screen after camera fade out needs to be implemented.

So at least I said what to expect in next devlog.

[vdapps]

-= Devlog #5 =-

Hi All! Last 2 weeks were quite productive in development of RTG.

--> The most important stuff implemented is level editing in my editor and level switching at run-time (as my engine upon which I built my previous game Universe Quiz had no concept of levels (everything was just thrown into memory at once), I had to implement that now).

--> Other important thing, languages support. I started writing game from beginning in 3 languages: English, Spanish and Slovak (my maternal language). Maybe I'll add French as well as I have lot of francophone friends (I was living in French speaking part of Switzerland before).

--> From game mechanics - toggle switch was implemented which will be integral part of various puzzles (i.e. opening / closing doors or changing environment in other way)

With previous things done, I was able to do Level 2 (jumping tutorial) and Level 3 (toggle switch tutorial). Here you are short presentation.

Development is starting to be fun and more fun things are just ahead. As game is using ray-tracing, in next updates, finally I'm going to use what is natural for this algorithm. That means game mechanics and puzzles based on lights and shadows.

[JobLeonard]

Nice! 

The language support, I assume that's using some kind of "easy to edit external text file" approach?

Looking forward to see the actual gameplay mechanics that you were planning to focus on!

[vdapps]

Nice! 

The language support, I assume that's using some kind of "easy to edit external text file" approach?

Thx! Yep, it's JSON file, keys with corresponding texts.

Looking forward to see the actual gameplay mechanics that you were planning to focus on!

Yeah, me also! There's looot of pre-requisites to be done to reach full gameplay but at least for upcoming levels I'm finally going to use lights!

[Ishi]

Development is starting to be fun and more fun things are just ahead. As game is using ray-tracing, in next updates, finally I'm going to use what is natural for this algorithm. That means game mechanics and puzzles based on lights and shadows.

I was going to ask if you were planning on making use of the ray-tracing in the game mechanics, so was happy to read this! The way the doors cast shadows in the toggle switch tutorial is lovely. Good luck with progress on the game

[vdapps]

I was going to ask if you were planning on making use of the ray-tracing in the game mechanics, so was happy to read this! The way the doors cast shadows in the toggle switch tutorial is lovely. Good luck with progress on the game

Thx Ishi! I'm glad to read your feedback. Yes, definitely, I'm eager to implement game and puzzle mechanics based on shadows and lights, however, there are pre-requisites to be done so I have to be patient. I have to lay good foundation for further development. But at least next tutorial levels will count with lights.

Also currently I'm bit limited with algorithm which is still bit academical and far from optimal performance wise. But I have at least 2 big optimization in mind. I want to tune game so it can ran on any potato computer 60fps (just with lower ray-tracing resolution). I have some mediocre i5 2C/4T mobile Skylake here at home connected at TV with controller, so this will be my benchmark.

[vdapps]

-= Devlog #6 =-

Hello All!

In last 2 weeks I was not able to work very much on RTG because of personal reasons, but anyway I tried to do at least a bit of something interesting.

Like I mentioned in previous devlogs, it's time to use something what is natural for ray-tracing algorithm, by that I mean lights and shadows. In the game, dynamic lights will be the key to various game mechanics. One of the most basic elements will be portable light, which is also something I was focusing on.

I'll be happy for any of your feedback, and I hope that in next 2 weeks I'll be able to deliver more. Cheers.

Here's how looks example of portable light which player can carry

[vdapps]

Hi All!

Not sure, if it's OK to write it here, to devlog.

Last weeks were very rushed, with little to no time for RTG development. Then, when I finally had some time to continue, I felt very demotivated to follow, as such interruptions affect heavily effectivity and productivity and make my original idea of delivering project up-to 1 year from start of development very hard to meet. As in this case it requires focused development without interruptions (3-4 hours daily). On the other hand, I hate the idea of not working on any project.

I don't want to ditch this project completely, so I'm just moving it being as "backup" project and started new project, where interruptions don't give me so much frustration, as it's designed in a way, where I can follow in more relaxed manner. As I'm very big fan of rocketry (everything from Sputnik up today to SpaceX) and space exploration (I also made small related quiz game Universe Quiz), new project is space exploration and rocketry related. It's called Universe Quest, there's already new thread for it (https://forums.tigsource.com/index.php?topic=70718.0).

I'm not marking RTG as RIP as I just don't feel to do it. It's still strong idea for me. I just sorted it in my head as being paused and backup, with possible return to it later (in my ideal world, where I am financially independent, I would work 5 hours daily on Universe Quest and 4 hours daily on RTG, however world is not ideal and with my 2-3 hours daily with lot of interruptions I prefer working just on Universe Quest for now).

Thanks to everyone who checked RTG here, specially to JobLeonard and Ishi for their kind replies here and I warmly welcome everyone on Universe Quest thread.

[JobLeonard]

There's plenty of on-off devlogs here where it's temporarily or sometimes even permanently dead (sadly). It's all good

Hope you'll find the energy and motivation (and joy!) to resume developing somewhere in the future, I enjoyed reading the updates to this project!

[vdapps]

Thx! Yeah, that's why I'm not RIP-ping this project. If situation will come when I'll be less time constrained, or maybe I'll need a break from Universe Quest development, I can resume RTG anytime. It's in my repo, side-by-side with Universe Quest. Both projects are using same my engine against which they compile. I can even use ray-tracing in Universe Quest or merge levels from RTG there, however that would be like cheesecake with chili sauce.

Time is very scarce in my case, so I don't want to force myself on project where I feel ineffective. So I just sorted it that way in my OCD head, so I can focus on Universe Quest now.