Very fun demo! Ridin' a dinosaur is always cool 😎
Eli Vazquez
Creator of
Recent community posts
Very cute concept! Trying to weave around golf balls to get to the golfer was exciting. Being able to eat golf balls right before they explode offers a cool risk/reward twist. It also rewards you for getting to the golfer quickly before they pick up their ball, adding another layer of strategy.
I did feel like it got repetitive after a while. Wish it had some sort of escalation, like a different enemy type (different club types, sand traps popping up, caddied driving by in golf carts, lots of thematic possibilities). Maybe there is more and I just didn't make it that far? IDK. Regardless, a clever and fun little game.
Really great game! I'll admit I was frustrated into almost quitting at first, but I'm glad I stuck with it. Runs where the luck just doesn't go your way were frustrating, but it just makes getting on a good run that much more tense. The ability to control your randomness via rerolling and replacing faces of your dice gives the game a different kind of strategy, more about hedging your bets than devising the perfect plan. I also really like how you could abuse encounters to farm health if you knew what you were doing.
I will admit that I was only able to beat the game by abusing what I assume was a bug where you could reroll your number by pressing the button really quickly after the initial roll before it switches to the other die. However, I actually really like the bug and think it would make a good mechanic; it forces your to make a split second decision about whether the number is good enough, and you can potentially screw yourself over by getting a lower number.
Also, for those curious, my final winning loadout was two defends, one attack, one attack all, one double attack, and the shield which gives you +3 to your defend rolls (no sword upgrades used)
Really great art and sound! The sonic-like spin attack when jumping on enemies was also cool. My main gripe is that the controls felt a bit slugish. The fact that you don't change your facing direction when turning around until your momentum has completely stopped makes it kinda frustrating to aim when there are enemies on either side of you. But, overall, a pretty fun game!
Thanks for playing! I'm glad you enjoyed the game. You can find the devlogs on the game's store page just under the download section, though they're mostly just patch notes with some design discussion.
MonoGame is great in terms of the amount of freedom it gives you to make what you want from scratch, but that also means you have to deal with some annoying technical stuff most engines would take care of for you. The default audio API in particular isn't very good, so it's recommended that you use some type of audio middleware.
If you need help getting started, I used GameFromScratch's tutorial series on YouTube. There's also plenty of documentation of the MonoGame website.
Sorry for the late response!
I'm glad to hear it! Thanks for being patient as I fixed the game; most players wouldn't be so kinds as to submit multiple detailed bug reports. This experience has also been really enlightening. I never considered how foreign language computer settings could affect my game. I suppose this is what I get for using a custom game engine. Thanks again for your help!
Sure thing! Here's how it works:
- The environment is stored as a 2D array of pixel object, which each stores its current color (black pixels are just null, with no pixel object).
- When a blood drop hits a wall or passes over a pixel object in the background, the addColor(Color c) function is called on the pixel at that (x, y) coordinate.
- If the pixel's current color is not c, then its color gets changed to c, thus coloring it in.
- If the pixel's current color is already c, then addColor(Color c) gets called on all adjacent pixels, thus spreading the color.
- (Make sure to use a set of pixels to keep track of the ones you've already visited so you don't visit the same pixels multiple times).
- (You may also want to add a range to the maximum spread distance, or prevent color from spreading upwards depending on your needs).
That's the basic version of how it works. It gets more complicated if you want to add in color mixing like I have in Blood Pressure, but I'll leave that up to you to figure out. I should also mention that this system works well in Blood Pressure because of the simple, monochrome artstyle with a lot of negative space. IDK how well it would work with other artstyles, but feel free to experiment.
I made the engine myself using the MonoGame framework: https://www.monogame.net/
I find that having a custom engine gives me a greater degree of control, and I don't have to hunt down documentation when something goes wrong since it's all my own code. However, it can be pretty difficult building everything from scratch, so it isn't something I'd recommend for everyone.
You're right! This should be fixed in the version I just uploaded. Sorry for the hassle; I didn't realize that foreign language settings would mess with the in-game text like this.
(BTW, the "controls" menu will still display "?"s for some characters, but it shouldn't crash the game).
Hopefully that's the last of the crashes!
Okay, I figured it out. It's not the Turkish keyboard but rather the Turkish language setting. Apparently, the Turkish language setting on Windows autocorrects all of the lowercase i characters to Turkish ı characters which the game doesn't know how to handle. Since the game displays all text as uppercase anyway, I just manually changed all the text in the game to uppercase. The game shouldn't crash anymore in the version I just uploaded. Thanks for helping me fix this bug!
Thanks for the bug report! The Turkish keyboard is definitely the problem; I imagine it has characters not present in the game's font, hence it getting replaced by a "?". I hadn't considered international keyboards. The new version I just uploaded should stop the game from crashing when this happens. Although the character will still be displayed as "?", the game should function as normal. Let me know if it still doesn't work.
Thanks again for your helpful comment!
Thanks for the bug report! After reading your comment, I was finally able to fix the bug! As it turns out, it was being caused by the menu explosion effect when starting the game. If you assign jump to a button with lower case letters like "Space", the explosion effect isn't programmed to handle it. A simple one line fix. The fixed version will up shortly.
Also, thanks for suggesting an easy mode. That's definitely something I'll be looking at for the full version.
Thanks for your help!
Sorry to hear that. I haven't run into this issue myself, so I don't 100% know what's causing it. My guess is that an error is occurring when the game attempts to save, since hitting new game creates a new save file.
Try playing the new version I just uploaded. If I'm right, it should no longer crash, though saving won't work.
Sorry to hear about the save file. I've heard some other people having problems with that, but I'm not sure what causes the issue. I cannot reproduce the bug on my end, which makes it difficult to fix.
When you go to the game folder, is there a "savedata" file? If so, what does it say inside when you open it with notepad?
Sure thing! Here's how it works:
- The environment is stored as a 2D array of pixel object, which each stores its current color (black pixels are just null, with no pixel object).
- When a blood drop hits a wall or passes over a pixel object in the background, the addColor(Color c) function is called on the pixel at that (x, y) coordinate.
- If the pixel's current color is not c, then its color gets changed to c, thus coloring it in.
- If the pixel's current color is already c, then addColor(Color c) gets called on all adjacent pixels, thus spreading the color.
- (Make sure to use a set of pixels to keep track of the ones you've already visited so you don't visit the same pixels multiple times).
- (You may also want to add a range to the maximum spread distance, or prevent color from spreading upwards depending on your needs).
That's the basic version of how it works. It gets more complicated if you want to add in color mixing like I have in Blood Pressure, but I'll leave that up to you to figure out. I should also mention that this system works well in Blood Pressure because of the simple, monochrome artstyle with a lot of negative space. IDK how well it would work with other artstyles, but feel free to experiment.
Thanks for the question! The game is made with MonoGame. It's not an engine, but rather a framework which handles assets, inputs, etc. The rest is really just written by me from the ground up. I like it because it gives me a lot of freedom with how I program the game, although it does mean I have to program most of it from scratch.
I actually uploaded one a little while ago on Twitter: https://twitter.com/RedOshal/status/1321617751530635264
Thanks for the feedback! I noticed that bug, but I can't consistently reproduce it or figure out the cause. Fortunately, the game auto saves, so you can just close and re-load if you get stuck. Also, the wall will eventually break if you keep shooting at it from different angles. Sorry for the inconvenience! Hopefully I can figure out the solution soon.
Thanks for the question! Each paintable pixel in the environment is actually its own object. I'm able to optimize it because it's all on a fixed grid, so lookup is really quick. I don't need to update the pixels outside of when they get colored in, and I only draw the pixels that are actually on screen, so it's all O(1). Paintable pixels on moving objects like platforms and thwomp are a bit more complicated, but follow the same general principal. It also helps that the art style leaves a lot of negative space, meaning there are fewer pixels to keep track of.
A few bugs/issues to report:
During my first playthrough, the game crashed the first time I tried to warp (screenshot with error message below). The gauge on the left of the HUD was in the red zone, so I assume the game just doesn't have a response to trying to warp with a broken engine at that point in the game. The only other thing I did was manually realign the ram scoop at some point as I was messing around with the controls, so that might have something to do with it.
After resetting and playing for about an hour, I ran into another crash which occurred when I tried to place an item to the north of the power generator in my ship. My only theory is that I somehow managed to place the item inside of the generator, causing the game to crash since that isn't a valid location. Upon trying to load my save, I'm greeted with this crash:
I started a new save, played for a little while, then manually quit to desktop. Coming back later, I received the below crash when trying to load that save. So far, I have not been able to actually load a save outside of the very start of the game:
I also ran into a bug with control rebinding. I rebound the pause button from Esc to Shift so that I could pause the game without moving my hand from the default position. However, this prevents me from capitalizing letters in text fields, as pressing shift immediately exits the text entry.
I also ran into issues with the key rebinding menu. The function a key is bound to would be performed as I am trying to rebind a key, preventing the menu from functioning properly. For instance, let's say I want to rebind move left to the L key. When I press Space to select move left, instead of waiting for my next input, move left is immediately bound to Space. In other words, using the interact key to select the function I want to rebind immediately binds that function to the interact key I just pressed. This means that the only way for me to use the key rebinding menu is with the mouse. Also, when rebinding the pause function, as soon as I press the new key I want to rebind to, the menu is immediately closed since I just pressed the key which is now bound to pause. Similarly, when rebinding the move left key, the menu selection immediately moves to the left since I just pressed the left button when I rebound the key.
I'm sure others have mentioned this already, but mouse controls are utterly broken on the select save file menu. After selecting a file, the mouse cursor is still able to change files by mousing over them. Also, clicking on the confirm/go back buttons do nothing; you have to use the keyboard to select (although you can still highlight them with the mouse). There also doesn't seem to be a delete save file function.
Also, I found a strange behavior with menu mouse control when entering text. If you have one text field selected and use the mouse to select another text field, the text will be transferred from the first text field to the second. Maybe that's the intended behavior, but it was super unintuitive; I expected selecting the next text field to simply confirm my selection and move onto the next one. You also can't deselect the text field by clicking outside of it with the mouse. Unless I'm missing something, it seems like the only way to deselect a text field is using the keyboard.
This next one isn't a bug, but still an issue. The first time I went to an uninhabited planet, I didn't realize that the layout was randomized every time you go back to your ship. As I was using my oniris device, I ran low on stamina, so I decided to leave it on the surface and go back on my ship to sleep and recover my stamina. It was a bit of a nasty surprise finding that my device had disappeared when I went back down, especially since items are persistent on inhabited planets.
I also wound up missing the deadline for the first cargo shipment of mundanium. I didn't realized what had happened at the time, as the dialog didn't acknowledge that the shipment was late, but the boxes weren't being taken. Having a popup to notify the player of a missed shipment would have helped. You may also want to not have a time limit for the first delivery so that players have some leeway to figure out the systems.
On a related note, I wasn't sure if cycles were passing in real time, or if it only happened when I went to sleep since that's the only time there's obvious feedback for cycles passing. I'm sure I could figure it out by staring at the delivery timer for long enough, but it wasn't clear to me as I was playing for the first time. (Overall, the delivery timer UI a bit hard to gauge, since it doesn't seem to tell you the exact number of cycles remaining).
Finally, as I was writing this comment, I noticed that the game still takes input even when the window isn't focused. Even with the game minimized and my computer focused on my internet browser, I somehow managed to open up a new save file and begin the tutorial as I typed.
Anyway, I really enjoyed what I got to play of the game, especially when I got the warp drive and unlocked the multi-start-system deliveries. I especially enjoyed the item lifting/placing mechanic; moving things around in that sort of embodied way is really satisfying. I hope this issue report helps you create a more polished experience!