#0030: Game review: Princess Remedy In a World of Hurt
Preamble
I wanted to feature this game here as I think it is rather interesting, and I have a few comments I’d like to make about it. The game is called “Princess Remedy In a World of Hurt”. It is a bullet hell game created for the PC platform. However interestingly, it was made with the design limitations of a game targeted for the Nintendo Game Boy Color portable games console; as least it appears that way superficially. This article will feature a review and discussion of the game as well as a play-through or two to demonstrate the gameplay, visuals, sounds, and general game mechanics on offer.
Screenshots
Pixel art samples
- Sprite size: 16×16 pixels
- Grid cell size: 16×16 pixels
- Grid size: 10×8 cells
- Status bar size: 160×12 pixels
Game Review
Before I begin it is important to get a bit of context on the circumstances of this game’s creation. According to the read-me file that I found within the Steam version of this game’s directory (‘remedy.txt’): ‘Princess Remedy In a World of Hurt’ was originally created in 2014 during a livestreamed four day charity game jam by a group of four people. This initial completion constituted their version 1.0.
Although this version lacked certain additional features present in the latest 1.5 version that I have played. Features such as: gamepad support, options menu, multiple difficulties, and additional endings. The version 1.0: although undoubtedly rough – established a set scope of gameplay mechanics, narrative, and player experience; that was then subsequently refined and improved upon.
With the exception of the ‘Jealous Chest’ mechanic and extra endings: the additional refinements were mostly quality of life features, and in my opinion do not necessarily constitute raw additional game content. Like a new area, or new enemies would for example. As such the final version still feels like a game that could arguably be created within a short amount of time.
I only mention the game’s humble origins because it is apparent by the restricted scope of mechanics present, story, and short playtime: that not much in terms of resources actually went into the game’s creation. By resources I mean time taken to either plan a deeper narrative, create additional gameplay mechanics, or create more materials (i.e. media like image sprites and sound effects). Add to that the necessary programming time taken to implement and test every additional element.
Although it may come across as a criticism, I do not mean it as such. Rather it is by virtue of it’s spartan nature that I am attracted to this game to begin with. I wish to emulate it in my own way, and create a similar title as a practice game for a larger project I have in mind. Also I rather like the minimalist approach to game design presented here, a design that discards all but the essential components needed for a viable gameplay loop. As a hobbyist game designer who has discarded games mid-development due to feature creep (and the frustration that it incurs): I actually admire an approach that respects the limitations of available resources and deadlines, and operates with a more prosaic ‘get it done’ attitude as a consequence of that.
Now onto the game itself. The core gameplay experience consists of walking around and exploring a classic 2D RPG world like the one of ‘Final Fantasy I’ (FFI). Here you find people to talk to, to then enter a battle instance with. This battle instance consists of a unique bullet hell mini-game; as every NPC has their own custom setup of enemies and terrain layout to contend with. Winning these battles provides rewards that come in the form of a stat boost called ‘Hearts’. Hearts are the most important stat booster in the game. This is because in addition to marginally boosting the characters health (or hit) points, a set number of them are also needed to open the specific gates that lead to other map areas, and thus progress the game.
The game has a simple and concise gameplay loop. It may superficially look like a classic RPG title such as FFI, however all the extraneous RPG mechanics from a game like FFI are not present here. There are no items (beyond gate-keys), status effects, nor any character abilities, or levelling. There is however a basic system of stat progression that involves collecting stat tokens.
The full list of stat tokens include: the aforementioned ‘Hearts’ which marginally improve HP, ‘Power’ which increases shot damage, ‘Multi’ which increases the number of shots fired at a time, ‘Regen’ which increases the HP regeneration rate, and finally ‘Flasks’, which increases the number of uses of the special attack action during combat. In addition to Hearts, all of the other stat boosts are exclusively found in chests dotted around the various towns and caves.
The actual game world itself consists of a simple world map, which links together a series of higher fidelity maps. These higher fidelity maps primarily come in two forms: towns and caves, but also includes a few castles, a pond, and several other unique areas. The world map only contains heart-gates and key-gates. It is the higher fidelity maps that contain all other interact-able objects. These come in two formats: NPCs and chests. Each NPC only offers a quick dialogue on interaction. This dialogue either contains game hints, or instigates that specific NPC’s bullet hell mini-game. Whereas the chests contain either stat upgrades, or keys for opening shortcuts.
I should mention that the higher fidelity maps also contain a puzzle element. Some chests are set up in a way to resemble secrets from other visually similar RPG games. Specifically, in order to get to them they require the player to walk off of the displayed tile area, by passing through normally impassible terrain tiles (like walls): into the black space in and around the map that traditionally denote impassable terrain. Links to secret paths like this are marked by a slight imperfection on the terrain tile that connects to them. Thus marking it as passible terrain.
That’s it. That’s the game. Talk to people, then win the bullet hell battles they offer to get hearts; find chests, get stats, and more hearts; then open the heart-gate to get to the next area. Rinse and repeat until you get to the final boss. Where you play an extended bullet hell battle. Done.
The only real deviation from this formula that this game offers is via the ‘Jealous chest’ mechanic. Within an advanced area of the game – one that is gated by three separate heart-gates, and hidden within the town map there: exists the Jealous chest. This is a special chest that will give the player a shot power boost, but only if the player has not opened any other chests before it. Meaning that in order to acquire that shot boost, the player will have to win (nearly) every battle up to that point in the game without any of the stat boosts that the other chests offer.
This challenge adds significant difficulty to game and I personally found it rather engaging. However there is a down side to this. The problem comes in when you actually get the Jealous chest. Shortly after opening the chest and getting the extra power boost contained within, the player gets the contents of all the normal chests in previous areas, even the ones hidden by secret passageways that may otherwise be missed.
This gives the player a very sudden and dramatic power boost. Which on one hand feels great, due to the fact that up until this point the player has been surviving the battles with mere base stats. ‘Surviving’ being the operative word here for the experience. Then all of a sudden you gain all the stat boosters from three zones, giving you the power to nuke previously troublesome enemies like the Ghosts.
The problem with this sudden dramatic power gain is that it causes an inversely dramatic drop off in game difficulty. Even though technically the enemies fought in the later game after this point are stronger than the previous enemies, the same level of planning and skill required to survive up to this point and win battles is no longer necessary due to the raw power output the player now has.
This phenomenon causes the player to experience a significant spike in difficulty in the mid game levels just before acquiring the Jealous chest. Which is then not surpassed by any of the other following levels, including the final boss fight. This is due to the smaller disparity of power between the enemies and the player. In other words once you get the Jealous chest, you can essentially coast the rest of the game, even though you’ll technically be fighting stronger enemies. It will not feel like it.
Luckily the Jealous chest is an add-on mechanic, and is only really necessary if you wish to get the full 101% completion rate. If you don’t care about that, then you’ll likely experience a far more gradual and balanced difficulty curve as you progress through the game the normal way: haphazardly collecting (and missing) chests as you go.
Moving on. As for the bullet hell battles themselves, they are also very simple. They consist of manoeuvring an auto-firing character around, and occasionally using the catch-all action button to throw a flask; which functions as a grenade: doing AOE damage across a three-by-three (nine square) grid. The standard shots fire automatically from the character as is standard fare in bullet hell games.
What isn’t standard is the fact that the character can change which direction she is facing; meaning that in Princess Remedy you can fire in all four directions. This is due to this game taking place in a sandboxed square area. Unlike more traditional arcade shooter bullet-hell games, which tend to play out within either a vertical or horizontal scrolling stage. In which the player character’s firing direction is fixed to face in the direction that the stage scrolls into frame from. As that’s where the enemies are coming from. The most typical example of this, is that of a spaceship themed vertical arcade-style scroller like ‘Ikaruga’.
The enemies in this game are rather varied. There is a mixed bag of enemies with differing movement patterns, health points, and who emit different shot types, in different numbers and frequencies from each other. There are enemies such as the Spike-ball which just moves towards the player when within it’s line-of-sight, as well as the Ghost which follows the player whilst also intermittently disappearing and shooting a terrain piercing shot toward the player. There are a handful of iterative enemies like this Ghost, i.e. harder versions of previous enemies. They utilize the behaviour patterns of the previous lower tier enemy, but then with a little extra mechanic added on.
I should also note that enemy behaviour actually changes across the difficulty levels. To me it is always a pleasant surprise when the actual enemy AI is tweaked to be more difficult on harder levels. In my experience playing video-games in general: it is far more common to see developers simply tweak stats like shot damage and hit points, then call it a day. All whilst maintaining the exact same enemy patterns of behaviour. This game probably does buff the stats of enemies in the harder modes, although I haven’t played enough to verify enough to the point that I could confidently state so here. Its not important either way. What is important is the fact that the enemy AI is tweaked and geared for the difficulty.
An example of this would be with Bat enemies. Bats are enemies that move in a random direction at a set time interval. They damage the player by colliding with it. In normal mode when a Bat dies, it simply dies. In hard mode, Bats shoot out three regular bullets in the direction of the player upon death, and in master mode the Bats move considerably faster whist also doing everything from the lower difficulties.
Moving on, now let’s discuss the more technical specifications of this title. This game was made using the Game Maker engine and targeted the PC platform. However more interestingly the game was visually designed to imitate a Game Boy Color game. It has the same resolution as GBC games (160×140 pixels), as well as similar colour pallets, and sprite types (8-bit era 16×16 pixel sprites).
It also uses a severely limited range of player inputs for interacting with the game. Although it maps multiple buttons/keys to each input type. For example the ‘action’ input is mapped to multiple keys including Enter and Spacebar. This is where my first real criticism of the game comes in. The ‘action’ key, the in-game results of pressing this key are highly contextual.
If pressed next to an NPC, it will engage them in dialogue; if pressed whilst moving, the player character will start running in the same direction; and if pressed whilst stationary and not facing an adjacent NPC, it’ll pop up the menu screen. Needless to say it has caused me to misclick a couple of times. Mostly by throwing up a menu when I intended to run. But that could just as easily be an issue with me and my keyboard. Although I found this catch-all action key to be a rather clunky method of input, it is ultimately a relatively trivial matter.
The main thing that I have encountered within this game that is actually worthy of criticism is it’s pixel scaling methods. At higher resolutions than the base times one (‘x1’) or 160×140 pixel screen size, it looks absolutely awful. The sharp clean pixels at the base size get blurry even at the times two (320×280) screen size.
Honestly, I am not sure about the technology being used here to resize the window and rescale the display assets within it. If I were to guess, I’d say that it is the functionality of one of Game Makers image manipulation libraries. Judging from what I can observe: I assume the image is actually being scaled using a form of on-the-fly interpolation. Such as linear or cubic interpolation.
Essentially algorithms (used within this application that are) designed to guess at what colour the pixels should be within the newly created empty regions, between the separated pixels of an upscaled image. Unfortunately, they do not have the context that they are dealing with a pixel art that requires clean lines, and consequently blurs edges in a bid to establish some kind of smooth colour gradient. At least that’s my guess as to what is going on here.
I think the window and asset scaling in this game was something of an after-thought honestly. Especially since the ‘options’ menu containing it was introduced to the game in it’s 1.1 patch. After the conclusion of the game jam. Meaning that the 1.0 game jam version was only made with the fixed Game Boy Color screen size in mind, and with all assets specifically scaled for it.
Only afterwards did the programmer who is maintaining the game decide to add additional resolutions. Unfortunately they did not recreate the art assets to be more scalable. For example by using large images designed for a modern full-screen display (e.g. 1920×1080) then scaling them down.
Although this has it’s own issues such as image artifacts being created by aggressively compressing image dimensions. However in my opinion, a little artifacting is considerably more palatable then the horrendous blurring incurred by the current solution of upscaling tiny images to large resolutions. This is most comically apparent when in full-screen mode. Imagine what happens when you upscale (essentially stretch) a screen with a height of 140 pixels to 1080 pixels. Needless to say it is virtually unplayable.
Now upon hearing this, you may think to yourself: why don’t they do that? I mean it won’t take long to use an image manipulation software (like GIMP) to upscale each image asset by raw pixel doubling; and without introducing blurring via interpolation techniques. Well, another reason why the current maintainer of this may not want to use upscaled images may include the related image code itself.
Considering that this game was initially made in a span of four days for a competition, then things like proper planning and future proofing of code goes out the window. It it very likely that this game has been hardcoded with strong references to the current image dimensions throughout the codebase. If so it will also explain this slapdash box-ticking approach to getting higher resolutions, as it likely avoids having to deal with the technical debt incurred by hard coding the image dimensions into the game logic in this manner.
What do I mean by this? Let me illustrate the problem here: imagine if you had a line of code that moved the Bat enemy for example. This enemy moves every other time tick in a random direction the full length of it’s size (16 pixels). Assuming that the code for this is hardcoded (i.e. code containing asset dimensions, or verbose inflexible instruction sets). Then the code for moving the Bat across the vertical axis may look something like: ‘moveBatY(){bat.posY+=16; updateSpritePos();}’.
Now, let’s say you want this game to also work at a times two scale (or at 320×280) resolution. This instruction set will have to be modified to allow the bat to move it’s full length. Which is now 32 pixels and not 16. If the code is left as is, then the Bat will no longer function as intended/expected. This is a form of technical debt, i.e. creating your codebase in way that will require reformatting/rewriting before significant additions can be made to the feature set; by in this case adding additional game resolutions. And considering the volume of image interactions going on in this game, likely having to reformat the entire codebase will not be a trivial matter. After a basic cost-benefit analysis, the programmer here probably deemed it not worth pursing at the time. Instead opting for the sub-optimal (yet viable) solution that is currently implemented.
Resolution scaling screenshots
Manually scaled examples
I’d like to leave this review on a positive note. As I was doing a final check after writing this review I found out that the main developer, namely Remar has very recently updated this game. The latest version at the time of writing is 1.6; however this version (at lest currently) is only available on Remar’s personal website. The update included a few things: most notably a dedicated run button. Which addressed some of my criticisms I had made prior. So discount those if you play version 1.6.
The real cool thing about this situation is that you have a developer here who decides to update a now 6-7 year old game; that they made available to the public for free. That’s a developer that cares about their craft, and cares about their legacy. At least I’d like to think so, I mean they sure as shit aren’t making any money off of it. And as a guy who is currently trying to port his old garbage flash games to HTML5 – love for the craft and posterity is the only real reason I can see for a person to go out of their way and tweak/improve something like this.
If you want to play ‘Princess Remedy In a World of hurt’ it is available on the Steam PC platform and also on the Developer’s personal website with no Steam DRM. Download link: ‘https://remar.se/daniel/remedy.php’. It is a free game so give it try. If you really like it you may even want to purchase it’s paid sequel: ‘Princess Remedy In a Heap of trouble’.
Video Play-throughs
- Difficulty: NORMAL
- Completion: 101% (jealous chest run)
- Time: 42 minutes 5 seconds
- Game version: 1.5 (Steam)
- Difficulty: HARD
- Completion: 101% (jealous chest run)
- Time: 52 minutes 41 seconds
- game version: 1.5 (Steam)
Game credits
Game copyright Remar Games and Ludosity 2014
Design, script, code, SFX edit: Daniel Remar
Design, graphics: Anton Nilsson
Music, SFX: Mattias Hakulinen
Final boss songs: Stefan Hurtig
Nintendo Game Boy Color reference images
image taken from wikipedia.org 
image taken from nintendo.co.uk 
image taken from nintendo.co.uk
Closing thoughts
This is the first actual game review that I have done on this site. I hope that it proved to be insightful and useful to you. Whether you wish to simply play the game (and you really should as its free on Steam), or whether you are simply interested in a hearing about a game’s systems and the interplay of mechanics within it. I hope that I at least entertained you if nothing else.
The main reason why I covered this particular game is because I intend to create a clone of this title. I like the very limited nature of it, and genuinely think that I could make a copy in order to sharpen my skill-set. I needed a small but genuine gaming project to try out my tools, and to practice my pixel art and music creation. So look out for that game when it is out. I’ll pop a link here for it when available.
It’s sort of funny when when certain coincidences happen, and one gets that feeling of living in a small world. The name ‘Ludosity’ came up a couple off times while I was reading up on this game. I just thought ‘huh, that rings a bell’ and moved on. Its only once the review was almost finished and I decided to actually visit the website links within the readme files, did I find out who it was. They were the people that made ‘Card City Nights’, a game that I really enjoyed years ago. I even 100% the game, blue Steam ribbon in all. I remember it was also a game of limited scope, being just a series of card battles attached to something almost akin to a visual novel, with a simple collectable card game or deck builder core. It also had a simple but very compelling gameplay loop, and lovely art…
On that final nostalgic note, I’d like to say:
Thanks for reading.
Glossary of terms
2D – 2 Dimensional
AI – Artificial Intelligence. Although in this context it doesn’t refer to real AI, but rather patterns of situational behaviour that non-player controlled entities engage in or act out.
AOE – Area of Effect.
NPC – Non Playable Character
RPG – Role Playing Game
Sprite – Simple low resolution image of an entity. E.g. NPC.
Links, references, further reading
https://store.steampowered.com/app/407900/Princess_Remedy_in_a_World_of_Hurt/
https://steamcommunity.com/sharedfiles/filedetails/?id=716757641
https://www.nintendo.co.uk/Corporate/Nintendo-History/Game-Boy-Color/Game-Boy-Color-627137.html
https://remar.se/daniel/misc/themegaupdate.txt
https://www.remar.se/daniel
https://www.ludosity.com
Game text files: