next »

[vdapps]

Hello,

Was working on another prototype level. This time focus was to start programming first 'puzzle' (or level building) elements for the game.

Before getting to main devlog entry covering last batch of work more deeply (with some fancy animations too), here's short story how level was built and how lighting affects output visual quality.

1. only ambient light - everything looks flat (maybe I'll add some ambient occlusion later in development or in RTG 2 )

2. darker ambient and added one strong point light (with weak attenuation) - just one light brought brutal change

3. all switches have small lightie (red or green depending on state) with strong attenuation - so they do just small 'local' environment illuminations

4. finally added 2 more lamps (one white at bottom of the level, one red at exit door) - just to add even more depth to scene

Note: those reddish vertical walls are doors and black part of the floor in front of player is elevator. Both are now changed to look more 'final'.

[Schrompf]

I love the tech behind this. Was a bit disappointed, though, when I read that you're cutting the story mode. Pure puzzles without a human touch don't stick with me for some reason.

[vdapps]

Thanks for the feedback @Schrompf and that you like the tech. I'm happy for it.

Yes, I had to cut down my original ambitions (deeper story with some animated sequences). Due to time constraints (I have just 3-4 hours per day), it's not very feasible. Not if I want to deliver the game in some reasonable time.

However, it's true that 'just' puzzle levels without any context can be very shallow experience. So very probably, I'll scratch the surface of the story. In previous animations you can see those terminals. I'll use them to bring player deeper into story to have that feeling, that 'something is happening', there 'something behind it'.

If the game will have some financial success and I'll be able to dedicate more time to it, I'll make expansion or RTG 2, which will be more story focused.

[marcgfx]

Would it impact performance a lot if you had a background-wall? Maybe with windows showing some night time city scape.
I also was thinking that infinite depth walls could be interesting, possibly even quite cheap to calculate as you know for sure that a ray will hit them

[JobLeonard]

However, it's true that 'just' puzzle levels without any context can be very shallow experience. So very probably, I'll scratch the surface of the story. In previous animations you can see those terminals. I'll use them to bring player deeper into story to have that feeling, that 'something is happening', there 'something behind it'.

May I suggest the tried and true literary technique of hinting at a deeper story but never fully going into it? It saves you all the major hassles of an actual story like having to create a (mostly) consistent universe for it to take place in, filling in the fine details, and resolving plot threads.

[vdapps]

Thank you both for suggestions!

Would it impact performance a lot if you had a background-wall? Maybe with windows showing some night time city scape.
I also was thinking that infinite depth walls could be interesting, possibly even quite cheap to calculate as you know for sure that a ray will hit them

I guess I will have to address it, as it's quite empty. I see 2 options: background (to fill now empty areas), or more 3D elements behind or in front of scene (will not fill so much empty areas but will add depth and parallax). Will see how I'll address that in the end.

May I suggest the tried and true literary technique of hinting at a deeper story but never fully going into it? It saves you all the major hassles of an actual story like having to create a (mostly) consistent universe for it to take place in, filling in the fine details, and resolving plot threads.

Yes, good point. This will be this 'scratching the surface'. Let it be more open to interpretations, and be more specific in sequels (hope there will be sequels, it depends on feedback).

[vdapps]

-= Devlog #10 =-

Implementation of firsts 'level building' elements

Hi All,

in the last batch of work, finally I got to implementation of 'level building' elements or 'prefabs'. Until now, things in showcases were a bit hardcoded (except of 'Terminal' and 'End level portal'). E.g. when pressed specific button, moved specific piece of wall from here to there with special piece of code. This is of course not suitable for further development.

For building levels, I need functional prefabs, so I can just place them in editor and things will automatically work. E.g. place switch here, door there, link them, so in game by pressing switch, linked door will automatically open/close. Same for operating lights, elevators, etc..

In this batch I started with some basic stuff:

- doors
- switches which can now operate doors or lights (or any element that will implement IToggleable interface, programmatically speaking )
- switches can be 2-states (on/off) for IToggleable elements or 1-state (one time actions)
- elevator

In following short animations, there's one level with doors and switches. I just walk around, not spoiling solution (even if this is easier level). Another level is showcase of 'color mixing' puzzle (this is very easy one, almost tutorial, so I can spoil I think).

[Alain]

Interesting! I am not much of a puzzle game player myself, but your second Gif makes me wonder what kind of puzzles await after that door These switches alone provide endless possibilites of complex puzzles for players to sink their teeth into.

[vdapps]

Thx! Yeah, next part of work on RTG is level design and make some puzzles (for at least batch of 20 levels). So I'll take a break from programming, take paper and pencil and try to design something nice with some wits in it. TBH, I never created puzzle levels before, this is my first time.

[Alain]

Sounds like fun! I am quite sure you already know this, but there is a great GMTK video called "What Makes a Good Puzzle?". If you haven't watched this one, I can highly recommend it. (I don't want to post the link and bloat your devlog with the auto-embedded video )

[vdapps]

Thank you Alain for the tip! No, I don't know this video and I'm going to check it right now as arcade/puzzle levels building is now #1 in RTG's priority list.

[oahda]

Looking good! Makes me wonder if you have any plans for a level editor in the game for players to use.

[vdapps]

Thanks Prinsessa! This editor thing, it's not decided yet, in my plans, I have it in 'maybe' category. I think, if reception and sales of the game will be good, I'd give 80-90% probability to release it.

I have editor in which I make the game, but as I never planned to release my engine/editor as a product, it's not designed to be user friendly. So if I will want to release editor for RTG, I will have to cut the corners, polish it, and document it very well, but it's still viable idea. So, we'll see.

[vdapps]

Hello,

Not working much on ray-tracing stuff currently. I want to give some consistency to game builds as until now, I was running every level just separately from editor. So I made simplistic 'Main menu', where 'New Game' will rotate this bunch of test levels I made so far. For the rest, animation of menu is self-explaining.

'Main menu' is also a good place to benchmark your PC and set-up your ideal resolution. Underlying level is special benchmark intense level, so if it will run okay there, it will run okay in the rest of game. As can be seen in the animation, still lot of optimizations before me.

However, I have to say, fps is lowered by grabbing and encoding to MP4, but even without that it was something below 30. Not good, even if I'm running crappy 15W mobile CPU. But I'm calm, it's still single threaded. Obvious optimization for ray-tracing is implement multi-threaded rendering. Ray-tracing is very friendly with multi-threading, performance should scale almost linearly with more CPU cores/threads.

[Schrompf]

Nice work! Combining levels with a menu or sequence is for me a huge step towards a "real game" feel.

However, I have to say, fps is lowered by grabbing and encoding to MP4, but even without that it was something below 30. Not good, even if I'm running crappy 15W mobile CPU. But I'm calm, it's still single threaded. Obvious optimization for ray-tracing is implement multi-threaded rendering. Ray-tracing is very friendly with multi-threading, performance should scale almost linearly with more CPU cores/threads.

Oh, I thought parallelizing stuff is the very first thing you'd do in raytracing :-) It really helps a lot, raytracing scales nearly perfectly in most cases. In some cases you even get more than that due to cache coherency gains. But beware: concurrent execution will mercilessly find any design flaw and global var you have in your code

Good luck!

[JobLeonard]

Sounds like a good thing to implement early to avoid technical debt later then

Can't program in design flaws and global vars if it immediately crashes your game!

[oahda]

Looking forward to seeing if you can figure it out and how much speed will improve.

[vdapps]

Thank you all for feedback! Current algorithm is single threaded because it's based on what I've written when I was at university. It was quite academic, not very optimal. I already made some optimizations, but it was about clustering objects to bigger bounding boxes, and optimizing recursive ray-tracing call tree.

Checking my code, should be no big deal to parallelize it. Global is only scene (all thread will just read concurrently from scene, which is not a problem) and framebuffer (every thread will receive own portion of framebuffer where it will write, so no problem as well with MT). Structures used for RT computations are all on stack, so totally thread safe.

But I think I'll keep that optimization for later. When designing levels, it's good if it's "just on edge" with unoptimized algorithm and then optimizations will bring it to 60fps realm. Keeping some margin for me.

[oahda]

But I think I'll keep that optimization for later. When designing levels, it's good if it's "just on edge" with unoptimized algorithm and then optimizations will bring it to 60fps realm. Keeping some margin for me.

I'm in this situation too at the moment, telling myself the same thing

[vdapps]

Hmm, with such game as RTG is, really hard for me to "invent" some logos of the game. This is especially the case when I'm anything but artist.

Playing with Krita did not led me to anything useful, so I setup "Logo" scene directly in-game (text was made in PixelFormer and I placed it over the box inside of the game so it looks like floating text). I took screenshot and put some noise filter over it in XnView. Voila.

My goal is something simple which will define the game (hence player and terminal in front of name plus few RT FX), which will be intriguing if some potential player will see it, not overly artistic (as I'm no artist), but also not looking very amateurish (of this I'm afraid most, again, I'm no artist).

Can you give me some humble opinion? Is this something close to what can be put on storefront? Or does it look like crappy, low quality, so most of players will decide to pass this game?

I'm afraid this will need more polishing but I'm totally out of ideas here.