Thanks! I based some of this game on a tutorial for a twine rpg. I found it to be a good way to get started making rpgs!
Recent community posts
Glad to hear! I'm still tweaking the customer's spawn rate to balance overwhelming versus the brief respite, so feedback on that is always appreciated!
I was considering local multiplayer options for a future version, the game is so small could fit 4 split screen kitchens or a larger shared kitchen.
Thanks! There's a "mute music" option if you press enter. I'll try to extend the track for post jam version. Is the white square is misaligned with what is picked up or are you unable to pick up? Being unable to pick up was a bug with this version that will be fixed. Cool video!
Thanks! 64x64 is honestly the perfect resolution so was super excited for the jam! Thought about making the book easier to use with the arrow keys flip pages and exit, will change for post-jam version.
That's a good point on the poop! Could make it they will just up and leave if they see it.
Thanks! I'm trying to address both issues in the next version for lowrezjam. I've added a highlight so you will be able to tell where you will drop/pickup from the belt. For sound... well... I have some of suspect quality!
(also completely with you on the music)
Thanks, glad the recipe additions were working well! I'm still shaky with pico8's music editor, if I continue development will certainly spend some more time with it.
I have not heard of it, I'll take a look!
Totally agree it needs one. The game had to be playable, so I disabled the quarter-finished AI and focused on local multiplayer. If I continued development of this project, single-player would a priority. (my next game won't need another human! :) )
Thanks for the comment (and bugs report!), we are going to be working on the visual and audio feedback for the next version. There is no "move" for the player, but you do push the tile your on. We'll try to make more devious levels too!
A tutorial would certainly help a lot I agree! I'll try to improve the tooltips and general UI so it will clearer. Your designing the internals of your robot (think Bender's cabinet) but it's abstracted. I agree something retro would be good!
Thank you! That's good to know about the tooltip, I'm using this game to improve my understanding of UI so feedback like that is really helpful! I'll try adding a transparency and lower it's size in the next version.
I can agree with the Amiga, they do have a mechanical feel!
Game Title/URL: Boilerplate link
Pitch/Information: Steampunk old school dungeon crawler pipe puzzler hybrid. This is a system prototype, there is currently only enemies and chests in the first level.
I'd like feedback on: What is the most confusing part? Would you prefer this to be a turn based or real-time game? Anything really!
I need help on: Would love some music recommendations to the set the game to or cool sound effects for robots!
- Messed around with the steam calculations again. Also tried out color changing instead of filling for representing steam levels, I like it. Still not found a equation that does exactly what I want
- Up top is an example of two equations I tried out: First method is an older but simpler one. It equalizes out mostly but does have problems with buildup in the pipe immediately after the boilers. Second method is as close a copy to Factorio liquid system as I could fathom. It instead has buildup in the boiler itself and a rapid change in dead-ends but it takes into account pipe volume, so larger spaces will need more steam to fill (also inertia). I think i'll go with the first method until it becomes an apparent problem.
- I found that increasing the volume makes it a lot smoother so everything will be at a 100.
- Chests are now implemented, complete with inventories that persist as well as loot from defeated enemies.
- Added a shutoff valve so you can control the flow of steam.
- Reworked enemy health a bit.
- Changed 3D colliders over to using purely 2D colliders. This game is not going to be a FPS, so there's no reason to use box colliders over 2D ones. Also I understand 2D collisions a bit better.
- Bullets now have a map icon when fired.
- Added enemy health and basic AI copied from Roguelike tutorial. They aren't smart enough to get around walls yet. If they try to move unto the same tile as you, you take damage.
- Added player firing bullets which deal damage to enemies and can destroy them. They're actually 3D models fired at a slight angle and are high caliber!
- Extended node scripting to limit you from firing if you don't have enough steam power.
First one was a recreation of Castpixel's dungeon crawler method which is basically fake 3D where you take a 2d grid and map out different 2d sprites that correspond to it's position on the screen to display. It's a hack to get 3D in 2D., something I realized I didn't need to after spending a couple of hours jurryrigging a 1D array of sprites since Unity already has full 3D support.
Second method is a 3D camera with cubes, which correspond to a 2D grid of objects in the code. The camera uses a render texture at a lower resolution to give it the pixelation and then I use a raw image with the texture to display on the ui canvas. If you have a 3D engine there really doesn't seem like a lot of benefits to using the former method. The 2D sprite of the robot has a bit of code that changes it's rotation to face the camera at all times. Hope that helps.
Here's an image of second method in the editor.
- Got a basic one point first person perspective of the game working. Currently the player only has a range of three tiles, plus the ones their on and any tiles adjacent to that line. It is really cool though! Also found an easy gif maker- so expect some gifs every now and then.
- Then I woke up the next day and realized I over complicating everything and had no idea how to do rotation for the player. So I redid it all in 3d. Much simpler.
- Can you tell the difference? I don't really feel like redrawing all the sprites for every facing so they're just going to always face towards you. It's also just compressing at different distances, which I could do smaller versions but again, lots of work! I could also render the screen at higher res even though that's a bit cheating. I might justify it by making all the sprites still conform to the general sizing.
- Started to sketch out the combat system, worked a bit on a range system.
- Moved json data to streaming assets. I was terrified when the project wasn't working in the browser, luckily it was an easy enough fix. For PC. Then had to figure out some networking stuff for the webgl version... ugh, learning! Was working on a multiplayer Westrado-like networked game before this but the art-programming was becoming too lopsided for my taste. May revisit after the jam.
- Also had a weird bug where all my publicly assigned variables got emptied out, something had to constantly deal with when making Sushi Inspector Extraordinaire! *shiver* Really taught me to resource loading and game managers though!
- Rant about aspect ratios: So the art is all for 256x144. Obviously I'm not one of those monsters that makes you read tiny fonts (actually I totally am- I even created a custom font that's only 3x3 pixels wide muahaha! please use to annoy for all your games). So I thought that since 1920x1080 is also 16:9 all is good right? Unfortunately due to .5 in the rounding it all gets wonky. I had to redo the UI to conform to a base of 1024x576, 4x the pixel count. Which looks fine in the browser but also means that when you download the game it will look a bit jank. Letter-boxing might be the best option as the highest perfect ratio is 1792x1008, 7x the size.
- Implemented a simple health and on move onto the same tile take damage. You can't destroy anything yet though!
- Also found an embarrassing old list of names in the vein of Pacific Rim- may still use them for the enemies cause they're so dumb. Here's a couple of favorites:
- Lupine Nuclear
- Massive Cosmos
- Cruel Peninsula
- Overall everything is working the browser as it should and on the pc, progressing along nicely.
Crabby bot wants to show off his guns! (may be more literal in-game)
Tomorrow's update will be to the combat system. I keep trying to find this little example game someone made comparing the player being able to wait, not being able to wait, and the enemies being able to wait. The moral of the story is that having to offset your moves is way more interesting than just being able to wait until the enemy moves next to you. Sill haven't decided whether my game should be real-time, turn based, or a hybrid. Likely will go with turn based but I do want to experiment with turn ticks that go on without your input (Crypt of the Necrodancer style). Obviously not at that game's speed, I don't want to stress players out with real time puzzling. Roguelites are often turn based so it might make the most sense in the end.
Alright lets begin!
- Read a whole bunch about rogue like level generation. I think the most informative was Bob Nystrom article with playable generators about how he designed one. Still don't understand it all well enough to implement so for now just going with a modified Unity Roguelike tutorial style generator. May try to learn how to implement perfect maze algorithm tomorrow. It's an 11x11 grid with walls on the edges so whatever code I use has to make pretty small spaces look great.
Side by side comparison of in-game (left) currently vs mock-up (right). I think the generator is trying to say hi!
- Implemented exits which regenerate the level.
- Modified the steam code so it priorities lower pressure pipes in order. Also added a local variable that stores how much steam it's already spent not tied to the global gain it gets that turn (otherwise pipes would be giving away steam they are supposed to get that turn and go into the negative- the selfless dummies!)
Think I'm going to limit myself to one robot per devlog (otherwise I'll spend all my time drawing them and not making the game!)
Thanks! It's a game I've been wanting to make in one form or another for a while now- Sockets is basically a non-playable demo made in Construct 2. I use game visuals to get invested before working on a project (and as a cooling off from coding... and because it's fun). Having a mock-up image of what the game could look like as a point of reference really helps me focus.
I'd love to join the play-testing session, so I'll try to get everything working on a fundamental level. Also excited to try other people's stuff!