Leaderboard

Hey friends! It's been a minute since anything has been posted on the dev blog proper, but I've got something to share. Today I received an email containing a video and a photo of the contents of an envelope had been sent to me. I can't seem to embed the video itself, so I'll have to describe what's going on with that. It's rather interesting though—it was a doorbell video. Weirdly enough, the person recorded on it seems to be... The SPU Delivery Guy? Y'know, the one who delivered those packages from the Puppet Master way back. He's talking to someone inaudible off-camera, but more importantly, what is he doing here? Hang on, let me transcribe it for you... "Yo! Is anybody home? I've got a rush delivery for P̸͡L̸AY̴͢E̢͘R̷̸! ...Oh, they're not home again? Man, I always seem to miss them whenever they've got a package to receive huh? Sure, it's been a while since I've last been here, but it's kind of a weird coincidence that they're never around whenever I am. Kind of a shame too, as I probably won't see be able to meet them for real in the future. Either way, there's an envelope that's addressed to them, so if you would be so kind to hand it to them when you next see 'em, that'd be fantastic. ...What? What do I mean I won't be able to meet them? Well, I'm leaving the city, actually. This is my last day at work y'see, and I'm leavin' for greener pastures in two days. My boss didn't want to extend the duration of my contract, and I decided enough is enough. Too much freaky stuff happening 'round these parts anyways, what with the freak accidents at Axis High 'n all... I don't want any part in it, so I'm headin' to Galar. I've found some work there instead. ...Yeah, thanks man. I'll do my best out there. You take care, too. You better stay safe out there." ...And that's it. The second thing that was included in the email is the package itself—the envelope that the guy delivered. Inside the envelope was... Tickets for a farewell concert for Risa Raider...? But... That shouldn't be possible. As we all know, she's... ... Oh, the mail that contained the video and photo had a bit to say about the ticket. "The tickets seem legit, but there's something off about them. When you hold one up, it looks as if the image of Risa on the front of the card glitches out ever so slightly, as if she's opening her eyes to smile at you. I'm not sure if I hallucinated it or if it's real, but the tickets give me the creeps." Finally, the email described a date was listed on the back of the ticket. July 13th. Strangely enough, there was no venue location included... But instead, it lists that a promotional video for the concert shall be released that day. Perhaps the place where the concert will be held will be announced in that video? Something shifty is going on with this whole thing, that's for sure. Perhaps it's best that we keep an eye on the situation for now. We'll keep you posted! o7

(Disclaimer: This post will probably be updated as time goes on today if there's anything I missed or realize I want to add later. Or maybe not!) Hey there! It's finally time again! This is not the release post. This is a quick post to help make your save file transition from v13.5 to v14 is as smooth as possible. First, let's start with this: PLACES THAT ARE NOT SAFE TO SAVE/LOAD UP IN: DISCORD INTEGRATION: Rejuvenation is now officially supported on Discord! No more Poker game or Age of War or whatever it's called in your activity sidebar. GEN 9 + ZA Megas: Gen 9 is now included! This includes numerous moveset updates. I said we weren't including ZA Megas and that's somewhat true. All sprites and stones have been implemented, but only those with official abilities are actually included in game. Go nuts trying to find some of them! JOIPLAY/KIRIN: We do have builds for Joiplay, but calling it official support may be a bit of stretch. These are highly experimental builds and maintaining overarching support is something we aren't putting at a high priority right now. There ARE some issues that we already know about that CANNOT be fixed by our side. The developers of these will have to take care of them. Same goes for Kirin. THE PROLOGUE + NG+: The prologue got some big changes if you weren't aware. It has an extended story if you have a completed v14 save. NG+ Is actually quite extensive this time around. So once you're done playing v14, there's more adventures to be had if you so wish to experience them! Some of them are very... very interesting. And I reward you handsomely for taking the time to play again :). I'll leave it at that. CHAPTER PASSWORDS: V13.5 brought in a Terajuma Password that allowed you to skip directly to Terajuma. v14 Brings in a new password that skips you directly to Act 2, Chapter 9. I really wanted to get a Karma Files password ready for release, but this password is already very experimental. I expect there to be some unforeseen issues with this one. Tread carefully with this one, but it should work okay. In the future I hope to have the Karma Files password skip ready as well, but ACT 2 is so extensive that it takes a lot of time and testing. I hope you all understand! RANDOMIZER SUPPORT: Unfortunately due to all the major systems changes we've had, having this in time for release was not feasible, but we are working on support later down the line! HOW TO START CHAPTER 16: But first, I have to mention something. I know a lot of you Renegade fans are itching to jump into Renegade first. I highly, highly do not recommend that you do this. Renegade acts without regard to spoilers in Paragon. And some things in Renegade will flat out NOT MAKE SENSE without context from Paragon. I HIGHLY recommend that you play and complete Chapter 16 in Paragon FIRST.

No turning back. It all ends here. With or without you. ...But where are you? When are you? Instructions on what to do before and after loading can be found HERE. DOWNLOAD THE GAME HERE OR HERE Patch Notes (V14.0.0):

Greetings, you probably don’t know who I am. I’m Falirion, one of the Programmers for Rejuvenation. So if I work on Rejuvenation what am I doing on Reborn’s devblog? Well since Reborn, Rejuvenation and Desolation all share our primary codebase I was asked (yes, asked, please ignore the banging on the barricaded door in the background) to talk a bit about one of the more major code reworks that have been done during 19.6’s development, the rework of the move resolution in battle, a part of the Code that was essentially rewritten from scratch. I will give the warning right now, this is going to get technical. So let’s start with the obvious first question. Why? Why fully rewrite a section of the code that was already working fine? Well, because while in the grand scheme of things it was working correctly, about 95% of cases or so, there were several existing bugs that were ultimately deeply rooted in how we actually handle the resolution of moves. We had a collection of bugs that all ultimately boil down to a certain older bug that has plagued the codebase since before I was even part of this community and probably even since the start of Reborn’s development. Our older Players may remember the so-called “spread damage bug”, a bug in which, when using a damaging move that affected multiple opponents, the second affected target would take more damage than it should, if the first affected target fainted to the attack. This was due to the double battle spread damage reduction not applying to the second target because, due to the first target fainting, the game didn’t recognize anymore that it should reduce this damage for being spread damage. Now of course this bug has been fixed for a while so why is this relevant? The fix to this bug is what a programmer colloquially refers to as “duct tape”, a more or less sloppy fix that resolves the issue but doesn’t really address the root cause, like using duct tape to try and keep your headphones from falling apart instead of replacing them. In the earlier mentioned bug collection almost all of them were a variation of this: something happened when dealing damage to target 1, and this would then affect how the move interacts on target 2 (typically the damage) when it in fact shouldn’t do this. Some examples are Moxie, Beast Boost, Soul-Heart and Water Spout or Eruption vs Rowap Berry. And the root cause is the same we were for all these years doing move resolution wrong, simple as that. The issues can be boiled down to 3 key points: Timing, Referentiality and Structure. Before explaining these, a quick aside. When explaining these I am going to refer to 2 Moves in particular Stomping Tantrum and Dragon Darts. This is because the functionality of these 2 moves taught me a fair bit about how the move execution needs to be to work correctly. And while I assume that most people reading this are familiar with Pokémon mechanics, for clarity a quick rundown: Stomping Tantrum is a damaging ground type move which doubles in power if the previous move the attacker used has failed… for most reasons, hitting protect for example does not activate this power boost. Dragon Darts in single battles is just a 2 hit attack, kinda like dragon type double hit. In double battles however this move has a quality we will call smart targeting, it will attempt to hit both opponents once each, if however the move would fail against one of the targets, it will ignore that target and instead hit the remaining target twice. So since we are now on the same page... Of the primary issues Structure is by far the most important one, but I will keep it for last so let’s start with Timing. Now, in the old move execution the general order of things isn’t inherently wrong; first check that the move doesn’t fail, then calculate and apply the damage and then handle the effects. It’s just the logical order of things. However the failure check was happening way too late, in particular for dragon darts, by the time the failure check was happening we had already determined which targets we are hitting and how often. Which is a problem for Dragon Darts because it needs to know whether it would fail or not to determine who to hit and how often in the first place. As such we had to move failure checks a lot earlier and while doing so we noticed, a lot of specific failure conditions were checking at the wrong time entirely, in fact type immunities and primal weathers were part of the damage calculation which is just wrong on so many levels. So let’s talk real quick about failure conditions, in Reborn 19.5 code they are generally in 2 places, at the start of move execution in a method called “pbTryUseMove”, which covers things like being asleep, paralyzed and other things that prevent the move from happening and as such not using PP, and “pbSuccessCheck” which covers just about all the rest just before the move would deal damage. If only it was so easy… After the rework we categorize them into 4 categories (numbered 0 to 3 because we are programmers so we start counting at 0). category 0 is “pbTryUseMove” and is largely the same as before so moving right along. category 1 is new entirely, timing wise it happens after subtracting PP, but before the activation of protean for example. This includes things like primal weathers and queenly majesty, the move is canceled in its entirety, usually irrespective of the explicit target (queenly majesty is a side effect ability, who actually has the ability is irrelevant). Only exceptions here are sucker punch and poltergeist, which directly check for the target here. category 2 and category 3 are both equivalent to “pbSuccessCheck” and are still in this method. Why are these categories separate if they are in the same place? Well I personally also call Category 3 "the group of random move specific failure conditions that exists because Pokémon code always has to be weird and wacky" but that’s a mouthful. The difference between Category 2 and 3 is that Category 2 conditions are checked before checking Accuracy while Category 3 conditions are checked afterwards. To be frank I was tempted to ignore this but there is a quirk about this that is relevant to Stomping Tantrum. Which leads us to Referentiality, an issue largely specific to Stomping Tantrum, as mentioned earlier not all failure conditions actually activate Stomping Tantrum’s power boost. Hitting into a target’s Protect (or equivalent) for example. Another group of failure conditions which don’t count for Stomping Tantrum are in fact all Category 3 failures. Any Failure condition that happens after the accuracy check will not activate the damage boost. Which brings us to the key problem, how do we even recognize why a move failed? Can we even? In the old move execution, we could not, the move failed and there was no reference as to why. Additionally in the Timing category I mentioned that we are checking move failure before determining who and how often we hit them. There is a problem with this, when we check whether a move fails against a certain target now, we are before the point where we handle anything, so we have to delay the effects and player feedback for these failures. Which means we need to know why a move failed after the check is finished. As such we are using what we call hit flags. In the above screenshot you see a bit of the failure handling, along with a lot of examples of these hit flags. They are kept for each target the move targets and make note of what happens to the move against that target. For Stomping Tantrum’s case we can check against these hit flags and make the effect not activate if any of the ones that shouldn’t trigger it are included. So lastly Structure. The primary problem was that when handling moves damaging multiple targets, we were handling targets sequentially, which is to say one after the other. We were checking failure conditions, calculating damage, applying damage, applying effects and so on for one target fully before moving on to the next. Which is the root cause for most of the bugs I mentioned at the start. So if that is wrong what is actually correct? The targets in canon are handled in parallel so we first check for move failure for all targets before then handling those failures for all relevant targets, before calculating damage on all targets, before applying… you get the idea. This approach prevents what happens to the first target affecting what happens to the second, because the damage you are dealing to the second target has already been calculated. This also lets us remove the Duct tape fixes and have overall cleaner code. So how do we actually know that canon works this way? Dragon Darts is a big hint. Not only do we need to know whether the move fails against all targets before calculating damage, we can also tell that failure checking works similarly in parallel based on how Dragon Darts acts when it fails against both targets. When Dragon Darts fails against both targets the player will only receive the feedback for one of those targets, the other target being ignored entirely. The feedback received relates to the target whose failure condition has the least priority when checking failure conditions Let’s look at the reworked pbSuccessCheck real quick. What we see here is that first it creates an Array of hit flags, one hit flag for every target the move targets. Initially the hit flag is on “:Success”, indicating a move that connects with the target. Then it checks each possible failure condition, in order for all targets before checking the next one, in order on this screenshot, whether the target is hidden via the effect of the ability Commander (gen 9 ability jumpscare!), whether the target is in a semi-invulnerability turn (like Fly or Phantom Force), whether a priority move is blocked by psychic terrain and whether the move is blocked by Wide Guard. Between each of these it runs a method called “successCheckFinished?” which ends the check when it detects that the move would fail against all targets at this point and also does some filtering for Dragon Darts to remove the first target that failed. The point here is that the failure condition check also runs in parallel and has a very specific order it checks these conditions for and this order matters. Structure was also significant in a different way, fixing this required a ton of work. Depicted here is the method "pbEffect" as it is in 19.5 Reborn the primary method of move handling, each move with an effect subclasses (overwrite it with their own modified version which can still call into this higher level version of the method) this method. The issue is this method bundles together, everything; damage calculation, damage application, move animation, move effects, literally everything. And to make the previously mentioned fixes to the structure we had to untangle this method, separate the components so we can do each step separately for all targets instead of doing it all for one target. Which due to the subclassing meant, we had to rewrite every single move, all the several hundred moves that exist in the game, we had to fully rewrite in a new structure. I have to give a shoutout to the Community Cooperation Initiative, modders that signed up to work directly on the codebase without being part of the dev teams, maybe even canonize their mods and such things. Without the help of all of them, rewriting all these moves in the new structure would have taken much longer than it did. Thank you for your help in this and everything else since. Now there is more I could talk about here, but I have probably already been rambling way too much. As a TLDR: we rewrote the entirety of the move execution because the rebornian games had some key things wrong here for several years if not more than a decade, which allowed us to fix some long standing bugs which were not fixable otherwise. So why should you, the player, care? Under the hood it changed completely but for gameplay it remained essentially the same except we fixed some bugs, right? Essentially yes, but all this also allowed us to streamline things, for example this: Nice, right? enu asked me to ensure when rewriting the move execution that we can implement simultaneous damage dealing and health bar movement. Doesn’t just look nice but also speeds up move execution a fair bit. Uhh… looks like the door barricade isn’t gonna hold much longer, so I gotta bounce, hope you found this interesting, I know I can get way too much into details, so excuse the long explanation. Have a nice day! Sounds of a door breaking open You will never take me alive!

Hello hello, you might be wondering why I, Ruby, am posting this devblog? Well… someone decided to go to Japan again! The audacity of that man… I haven’t even been to Japan once! :/ oh well… Besides all that, the rest of this devblog was mostly handled by him. So, take it from here, Posty of the past! --------------------------------------------------------------------------------------------------------------------------- Howdy folks! Hope everyone is doing well, me? Well as of this post going out I will once again be touching down in Tokyo, Japan. Loved it so much that I’ve already returned to spend even more of my life savings on silly pieces of shiny cardboard. Anyway, enough about that, today’s blog will highlight some of the work that our newest members have been producing since joining the team, but speaking about new members, we had one more join us in recent months! For those who don’t already know… I’m pleased to welcome Twoslashes to the Desolation development team! He has joined us in the mapping and spriting department and has already hit the ground running in producing some high quality content for the game. His work I will be looking to share in a future development blog, so keep an eye out! But for now, I’m going to pass it to Mags as he walks through some of the sidequest content he has been whipping up. SPOILER ALERT, it contains frogs. --------------------------------------------------------------------------------------------------------------------------- Hey there, I’m Mags! I joined the team recently as an Eventer. I’ve been mostly working on sidequests, which is perfect because when left to my own devices I tend to add flavor text - sidequests, in my opinion, are very elaborate flavor text. Indeed, some may argue the point of the humble sidequest is to elaborate upon the world in small ways, to make it feel more lived in and fleshed out…. And some may argue its point is to give you new Pokemon. Both can be true. Also I talk a lot so be prepared for a lot of yapping. I’ll be going over the process of making a sidequest I’ve been working on that you’ll be able to find down in Blackview. To start with… that new Pokemon thing. As you all probably know, Gen 9 ‘mons are getting added to EP 7. Yay! I’m quite a big fan of Arboliva, myself. Anyway, new ‘mons means new sidequests, and new sidequests means new NPCs… Now, I could’ve been normal about it. Could’ve just had some random nameless guy be like “hey can i get your help with something” and you just get a normal Pokemon out of it. But unfortunately, I was left to my devices, and now we’ve got a whole new sidequest-exclusive NPC. Enter: Ribbert. Ribbert is an NPC with a long and storied development history, the history being that I wanted to make a frog pun and then I portmanteau’d Robert and Ribbit together. But why Ribbert? Why… him? He fulfills a few roles. His first role is that he acts as the main sidequest giver, of course. Interacting with him and hearing his spiel about frog Pokemon begins the quest “Hop To It!”, which is the sidequest that lets you catch Tadbulb. This is also the 2nd role he fulfills: everything about Ribbert is designed to make you go “okay, I see why this guy knows about Tadbulb”. His character is, first and foremost, an explanation as to how you could find Tadbulb in-universe. Tadbulb, for those who don’t read Pokedex entries for fun like I do, aren’t actually found underwater or in traditionally swamp-y places. No, their dex entries say they actually just chill mid-air. Like in the sky. Specifically when there’s thunderclouds… so they’re probably high up in a rainy place like Blackview. Obviously, for optimization and gameplay reasons, SV just has them hover above the ground, but the wonders of [ sparkling effect ] locked camera perspective [ sparkling effect ] means that we can just say Tadbulb are in the sky and have it be true without having to render dozens of frog lightbulbs mid-air whenever the player looks up. That leads to the next problem, though: if we wanna make it feel like the Tadbulb are doing what their dex entries say they do, how does the player acquire one? How many trainers DOES it take to catch a Tadbulb? The answer is two, because you’ll need help from a real FROG EXPERT. Ribbert! Ribbert just needs your help in prepping a special maneuver to get some Tadbulb down from the sky. It’s a fairly simple fetch quest, since it’s… like, I love Tadbulb, Bellibolt is really cool, but it’s not a game breaking ‘mon, so I didn’t want actually getting it to be a real chore. So a lot of the quest’s fun just comes from the stuff Ribbert says to you unprompted. Incidentally, ignore the lack of accents over the es. Bad habit of mine, I’ll put ‘em in the game later. Anyway, that’s how I got to making this Blackview sidequest. I try to think in the bounds of the world of Pokemon, especially if it’s a sidequest ABOUT a ‘mon. How does that ‘mon work, and if it’s not just milling about in the local foliage, how WOULD you get it? Then I work my sidequest around that central idea. The sidequest has to explain how you got your hands on this ‘mon. Additionally, the challenge of the sidequest should probably be proportional to the reward - in a game like Pokemon, there’s really little risk, since losing usually just sends you back to the Pokemon center. But even so, you gotta think about what the player is going to get in return for spending however much time on a specific fight or objective for a quest. If it’s not equivalent or better, then chances are they’ll just abandon it by the wayside. And of course, I love to use sidequests and flavor text to just build out the world. Even if it’s minor, the implication there’s some guy running around Aryith who just… REALLY likes frogs and is going on his own little adventures to find and catch them makes it feel like, y’know, the player isn’t the center of the universe. And it helps that mono-runs that aren’t just about Pokemon type are very common and popular in the Pokemon fan space, so an in-universe character who exclusively uses frogs felt like both a realistic thing to happen, and I felt it would be a nice nod to that type of run in Pokemon circles. Ribbert’s sidequest will be available as soon as you get to Blackview, so feel free to drop by and do his froggy bidding when Ep7 comes out! Ah, by the way… I’m not a big fan of introducing a named character just for one sidequest. While I like expanding and fleshing out the world, I also like using those fleshed out elements more than once to at least keep it from feeling like there’s too much going on all at once and also tying things together a bit neater. So… This Tadbulb quest isn’t the last you’ll see of Ribbert, I’m sure. (And here, some additional memes, as a treat…) --------------------------------------------------------------------------------------------------------------------------- Ribbert, Frogs, and even some memes, Mags really gave us the goods for this. Hope this has got you excited for the new sidequest content coming to EP7. One of the reasons behind picking up a new Eventer for the team was so we can deliver on some new sidequest content, and with my time being a bit more limited than it once was, this was an area I really want to not fall behind while I focus on the rest of the project. We have been discussing some really cool ideas and concepts for sidequests, and Mags really played a part in providing some creative direction for these. Now let me pass it over to Wire, for a brief look into a major update coming to our shops. --------------------------------------------------------------------------------------------------------------------------- Hello, I'm super excited to join Desolation's dev team! Ironic, considering I hadn't finished Desolation when I joined - E6 is unstable on Mac, so I only got most of the way through before getting too frustrated. That's been rectified, of course! I'll be acting as a general scripts developer, helping out with whatever is needed. I've also got some features of my own that have been introduced - for example, from my rejuvenation modpack, Complex Shops! All shops have been changed to use this system. This system was originally created in my modpack for Rejuvenation's Cairo, who sells things in bulk as well as for different currencies. It allows us to make any such shop interfaces, including in the future, all navigated similarly, and with far less effort on the development side. No more long menus for buying evolution stones, Pokemon, or TMs... No more trying to remember which TMs you bought... it's all just regular shop interfaces now! --------------------------------------------------------------------------------------------------------------------------- Short and sweet, sometimes that’s the best way to go about it. You don’t know how much I have been hoping for something like this for our Credit Shops, comparing what we originally had, this is a night and day difference. No longer will you have to double check the amount of credits you have in your bag as they now appear while you’re browsing the shop. And to even show the Pocket Monsters there as well, chefs kiss. This is just one of the many things Wire has been already working on and optimising for the game, which alongside Yumil, have been crushing it with the scripts. There will be more to come in terms of optimisations… and maybe new passwords? Got to wait to find out! --------------------------------------------------------------------------------------------------------------------------- As we proceed with development and through 2026, I’m going to be looking to drop some more EP7 story teasers as a little taster for what you can look to expect once we finally get round to being ready to release. Here, I offer you all some crumbs :) There’s a lot more I would like to do/experiment with Desolation as we progress forward with development, ways we can look to expand upon and develop our story telling to allow you, the player, to feel more immersed with the story. This comes from playing through some other fangames (Rejuvenation) and giving me a ton of inspiration about how we can improve our storytelling, especially without Caz at the helm. I will continue to keep you all updated on development. Desolation’s development team has really undergone a lot of change over the last 4 months, and I’m excited to continue to share more of all the amazing work they have been producing! And with that, I’ll see you all next time. Posty (and Ruby...)