next »

[JobLeonard]

@Ramos:

Reason number one. Because of my life setup (I'm Slovak living in Spain) and 2020 Covid situation, our summer vacation to Slovakia this year spanned to almost 2 months (as we not saw our family for very long time because of Covid). Yes, I took laptop with me (as I work for one company as my main job, RTG is naturally "just" side-job), however, with all time there with families, there simply was no time for RTG development.

Reason number two. Apart from creating games, I'd like to play them as well. I can theoretically work up-to midnight, 1AM, 2AM on RTG, but I really also want to play games. Initially, I was working on RTG also at nights, but I got quickly burned out. So I'm trying to find more sustainable pace, albeit slower, where I can develop RTG but also have some times to play games. But who knows, maybe sometime I reconsider and I'll start developing at nights again (I can imagine something like that near finishing project).

I don't even have a devlog, but "spending time over summer with family we hadn't seen in one-and-a-half years and not doing anything else" was literally what I did too. I bet it's true for a lot of other people too. Family is important

[Ramos]

@Ramos:

Reason number one. Because of my life setup (I'm Slovak living in Spain) and 2020 Covid situation, our summer vacation to Slovakia this year spanned to almost 2 months (as we not saw our family for very long time because of Covid). Yes, I took laptop with me (as I work for one company as my main job, RTG is naturally "just" side-job), however, with all time there with families, there simply was no time for RTG development.

Reason number two. Apart from creating games, I'd like to play them as well. I can theoretically work up-to midnight, 1AM, 2AM on RTG, but I really also want to play games. Initially, I was working on RTG also at nights, but I got quickly burned out. So I'm trying to find more sustainable pace, albeit slower, where I can develop RTG but also have some times to play games. But who knows, maybe sometime I reconsider and I'll start developing at nights again (I can imagine something like that near finishing project).

I understand, my situation is a bit diferent, but I do agree that night time seems to be more productive for me too

[vdapps]

@Alain, @JobLeonard: thank you both for your kind words! I'm finally prepping some new animations, it'll be my first devlog update after 6 months! Ooopphh.

@Ramos: Indeed! I'm currently posting here, grabbing some animations for new post, converting to WEBP etc.. It's 9:30pm in my time zone. I'd like to play games now as well, but yes, this time is also ideal to dedicate to project (my son sleeping, everything calm and silent). Now to find right balance between 2 worlds.

[vdapps]

-= Devlog #17 =-

(RTG is in version 0.3.1)

'Charged light shooter' levels

Hi All!

New devlog for RTG is here after a big break (3 months I was totally out of development, another 3 months I was developing, albeit without writing devlogs and in much slower pace). But now to the point.

What's new is the gameplay mechanics called 'charged light shooter'. With it, you can turn switches or call elevators on distance, however you must reach given switch or elevator by shooting the 'light bullet'. And here's the catch. Most of the time, it's not straightforward how to reach an elevator you need to call or a switch you need to switch.

'Light bullet' after shooting is bouncing from all walls, floors, ceilings, boxes, etc.. You can point your shot and set its initial shoot velocity. There's some dampening, so it will not fly and bounce to infinity. You'll have to check environment around you and most of the time you'll have to also modify it, so you'll be able to reach your target by shooting.

So, there's puzzle element to it (how to reach that damn switch?) but also semi-arcade element, as with all that bouncing, it's like playing a pool game (or maybe some weird ray-traced version of Angry birds ), so you'll need to be precise at aiming and setting the right speed for your bullet.

Apart of that, quite a big chunk of levels built around that mechanics is done (8 levels in total from the last update). Finally, I guess it's better to see the new mechanics in action, rather than reading long texts, so here it is.

Note1: actions of actor in those animations are almost non-sensical to not spoil any important solutions
Note2: animations here are MP4 converted to WEBP which quite lowered quality of the source. You can find higher quality version of animations on RTG Gamejolt page.

That's all folks!

Cheers.

Calling the elevator



Switching switches

[Alain]

So great you're back with an update! The charged light shooter looks nice. Everytime you implement a new mechanic my heads starts spinning with all the cool puzzles it enables. I'm sure you're having a lot of fun playing around with the possibilities.

[oahda]

Hello again! Very cool, looks like a lot of fun to play around with, and it's really neat that it glows like that too

[vdapps]

Thank you both! Yes, this mechanics was designed with two things in mind. Open new puzzle design possibilities and at the same time showcase ray-tracing algorithm strengths (flying light seemed ideal to me to achieve that).

[JobLeonard]

Looks fantastic! Maybe add some broken mirrors and lenses into the scenery for maximum show-off?

[els]

Is this all still software-rendered? Amazing

[vdapps]

@JobLeonard: Thx! It means a lot to me! I just very hope, it will not take again 6 months for my next devlog. I'll try to slice my progress into smaller (but still distinguishable) steps. Regarding mirrors, you're totally right! I should add at least 1-2 'light shooter' levels with mirrors in background. Regarding lenses, I not have it coded yet (even if it should not be a big deal as it's easy to integrate it into ray-tracing algorithm). Good idea for future coding.

@els: yep, pure pure software. Direct3D, I'm using just to copy memory texture with rendered scene (which I'm generating in software way in C++) to on-screen quad. Plus any 2D drawing (e.g. texts, menu buttons), for that I'm using Direct3D as well (I wanted to focus on ray-tracing algorithm, so I skipped any software 2D drawing). But of course, pure software has its consequences. In animations you can see, framebuffer resolution into which I'm rendering is just 352x198. And levels are really low-poly. Like 1000 max 2000 quads per level. On the other side it's still not ideally optimized. I have one-two good optimizations in mind regarding algorithm itself, plus currently I'm just single threaded, but ray-tracing is perfectly suited for multi-threading. This everything I have in backlog. With that implemented, I hope it'll run 60fps with acceptable resolution even on potato computers.

[els]

Ah, very fascinating and very awesome I actually just use single-threaded rendering too but don't plan to change it, because I also test & use it on a PinePhone (Linux phone) and I wanted the challenge of not burning to ash mobile devices like that too badly. And one way to help with that is to keep the main load on just one core. It is very interesting what strategies people choose, and why! I do however run audio playback & decoding on one separate thread each at least.

For what it's worth I have a relatively potato laptop CPU, so if you need testing some day I would be interested. It runs Linux, but I imagine wine the Windows translation layer is good enough for the 2d activity you do, so hopefully that shouldn't be in the way.

[assemblerbot]

Wow, that looks great! I'm glad to hear that you've resumed the development. RTG is very unique and I'm really curious about the real gameplay.

I can't tell you how to develop your side project in your free time. It's hard. I've found out that I'm able to work on my game between 20pm and 21pm, sometimes shorter, sometimes longer. Depends on how hard was my day. But that fixed time is very important.

So, good luck. I'm looking forward to next update! 

[vdapps]

@els : I'll let you know, when I'll reach some beta-testing stage. I don't know much regarding Linux/Wine, but as far as it can emulate some basic DirectX (for fore-mentioned 2D drawing) and XAudio for sound, it'll be ok. And yeah, for high-level engine (scripting, game logic, etc..) I use C# (.NET Framework 4.6.1 currently, but I use just very small subset of .NET, I'm sure it can theoretically compile against older .NET versions). But I guess, Wine should emulate that without problems as DirectX/.NET Framework are integral parts of Windows. Btw, I'm also developing on quite potato laptop (15W 2C/4T Skylake-U), so I'm sure if it will run fine on mine, it'll run fine on 95+% of what's out there between players.

@assemblerbot: Thx! I'm happy about your words. Mainly this unique look is something which I tried to achieve, so I'm happy that I'm successful in that. Regarding gameplay, it's real question-mark. I'll want to run some focus/beta test later with some limited level set. I have literally no idea if my puzzles are boringly easy, or infernally hard, as from point of view of creator, my estimation for puzzles difficulty is really vague. And yeah, developing side project is hard if one is tied by "main" job. I'm developing normally between 5:30pm-7:30pm, so normally it's better than yours and as you said, sometime less, sometime more. My development breakers were mostly due to my life situation (Spain vs Slovakia). Because of that we were long in Slovakia this summer (dev breaks) and then vice-versa, in autumn, we had lot of family visits here, and it's harder for me to be assertive and close myself in my room and develop when we have family visit. I still try to play games (sometime after 9-10pm when my son go to sleep), but if I have unfinished work from day which bites me, I try to finish it first at night and then play a game.

[baftis]

What I see in your game takes me back to the "good old days" when I would play games with a software renderer, because I did not have a graphics card at the time ('97-'99). And it also reminded me how hopeful I was about future games and how they would look. If 12-year-old me would have seen your devlog, especially the first tests, he would've been drooling all over the keyboard.   

Gameplay looks really cool, fascinating and full of possibilities puzzle wise. I could see myself playing with the charged light shooter for hours on end, trying to discover secrets.

[vdapps]

Thanks baftis! Your words are much appreciated. Right now I'm working on another gameplay mechanics which I hopefully showcase soon.

[bayersglassey]

This looks awesome! I love when a game's underlying tech isn't hidden behind a ton of art design. (Like how in N64-era games you could see, and generally interact with, every polygon.)

Some of your earlier animations in this thread were "more 3d", like the one here: https://forums.tigsource.com/index.php?topic=70041.msg1423838#msg1423838

..."more 3d" in the sense that the world's objects aren't just placed in the 2d plane on which the sidescrolling gameplay is taking place.

It would be cool to somehow get "more 3d" spaces like that into this game. Maybe by curving the 2d platformer's plane, or adding forking paths to it, etc? Somewhat like Kirby 64.

Anyway, whatever you choose to do seems like it'll turn out great.

[vdapps]

Hi @bayersglassey! Thank you very much, this is really heartwarming!

You're right that ray-trace engine itself is fully 3D. It can chew any arbitrary geometry. The reason why I went with this style (side camera to simulate 2D platformer) is purely for time saving. I don't use any 3rd party engine/editors, everything is done by myself. I already have 2D based engine/editor written in C# from my previous game, with support for scripting / serialization, etc.. so it was relatively fast to wrap existing C# code around ray-tracing algo (which I have written in C++).

Even with this time-saving approach it takes quite a time to finalize game (originally I wanted up-to 1 year, but that was without chance). Making things more "3D" also on game logic side, would mean even more development time (refactor existing C# engine/editor completely, more complicated collision system, physics, etc..). I don't want to be overly ambitious, better to deliver smaller but consistent package, rather than not deliver anything because of unfinished game.

But for any future game based on my software RT, I can make another step forward and make it more 3D. This is yet to see. 

[vdapps]

-= Devlog #18 =-

(RTG is in version 0.3.2)

'Gravity inverter' showcase

Hi All!

New devlog for RTG is here. This time, I'm not going to explain very much as I guess that short animation will show more than long text in this case. New game mechanics/element is called 'gravity inverter' and I'm sure that it's self-explaining.

This is just test level, level design and my actions there are non-sensical, it's just to showcase new feature. And yet again, sorry for lower quality of WEBP animation posted here. On my GameJolt page, there's higher quality MP4 uploaded (which can be 'fullscreened' there), in case you'll want to see nicer version of the same animation.

Cheers.

Upside-down, downside-up

[assemblerbot]

I love that gravity switch. I've just noticed that the player "character" is perfectly fine from both gravity directions.

[Alain]

Another interesting mechanic! You could add another spin or two to your zoom effect for through the roof stylishness