Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Joobalee

12
Posts
1
Followers
1
Following
A member registered Jun 15, 2020 · View creator page →

Creator of

Recent community posts

The larger enemies deal significantly more damage than the smaller enemies (6x higher than smallest enemy) to compensate for their lack of speed, and as you mentioned you do still need to shoot them for fuel. You could preserve fuel by choosing to limit your movement while only large enemies are on the screen, and pick off one at a time to prevent getting swarmed by the little guys. As an aside, they still split into smaller enemies if they run out of fuel. I realise this is counter intuitive, and had considered making this not the case, but just didnt get around to it by the time the deadline was close!

Thank you for your feedback! Love the idea of non-enemy units. Perhaps the enemies could also target them and try to grab the fuel so its a bit of a race. Could be fun.

Cute game. As others mentioned the resolution has some issues. I noticed that zooming in lets you see more of the UI, which tells me it was probably made on a laptop with a smaller resolution. Zooming in a lot shows 2 buttons which appear to be unused. An inventory button on the top right and an "upgrade luck" button to the right.

I would also suggest that with text inputs you look into adding RegEx (Regular Expressions) to prevent invalid characters from being input by the player. This is a lot cleaner than just telling the player not to use them. It was particularly an issue with "new line" characters. I, at some point, accidentally pressed enter, which caused a new line element to appear. At first I thought my initial input was deleted, and so I just reinput the offer, but no matter what I was putting as the offer was being rejected, whether it be the same or even substantially higher than the asking price. Came to find out later that it was because of the New Line character.

(1 edit)

they arent health bars! They're fuel bars :). The enemies have fuel the same as the player. The more they have when they die, the more you can collect from them. Unlike the player though they dont lose fuel when they get hit

Hey I'd be interested with working with you if you're still up for having a second programmer. Sent you a request on discord.

I'm a Unity programmer with a decent amount of experience (albeit not a very extensive portfolio). I've only participated in a couple jams as this is a fairly new hobby for me, but aside from that I've written a couple AStar pathfinding scripts which was good fun

Thanks! Fun fact is that the enemies and players use the exact same script for dashing! Fuel cost included (they stop dashing if doing so would empty them completely) :)

Im pretty proud of how modular I made everything even if I wasnt able to make much use of the architecture due to the limited timeframe. The shooting enemy also uses the same script as the player for equipping the weapon, which means they can be swapped out on the fly for whatever weapons I design in the future assuming I do add more stuff. I hadnt given it much consideration and was mostly in it for the jam

Similar concept to my submission! Not sure if it's the movement or the checkerboard pattern, but the background is a little hard on the eyes. Would also have been nice if shooting was optional to make it feel more like a cost being payed as opposed to a timer. Lastly, the game froze and stopped working when I reached 240 score.

I respect giving a new engine a try. I can't imagine it was very easy!

Agreed. I probably only spent an hour of time actually balancing with the rest dedicated to development. Had to gut a good amount of stuff from the initial scope but thats the nature of game jams with this limited time frame I suppose

Yeah balancing the rate at which fuel disappeared was a little tricky. Initially they did stick around for longer, but the problem was it made the dash less useful since there was ample time to kill all the enemies and then collect it before the next ones spawn, so I decreased it from 10s to 7s. I should have revisited it though because after that I updated the spawning script to double the rate at which the director gained credits (spent on enemy spawns) when there are no enemies active.

Glad you liked them! It took a while to get the momentum of the splitting enemies to work properly, but Im very happy with how it turned out in the end

Yeah unfortunately Im pretty hopeless when it comes to creative stuff. Im much more interested in the technical side of game creation. Both the player and enemy are just logic gate symbols haha

Thanks for the comment! Yeah I wanted to make more in depth spawning with an area around the player being off limits to prevent this kind of thing but I wasnt confident in the time I had to accomplish this so I just left it as is. An unfortunate sacrifice, but Im pleased you were able to win in the end!

While knowing how to code does provide an advantage to solo developers in the form of custom scripts which provide flexibility, doing so requires time and effort just like any other discipline, and in my opinion doesn't provide anything more valuable to a game than any other custom made asset, be it art, sound, game design or balance.

As you mentioned there are options out there for people that don't know how to code, just as there are options for someone like me who doesn't know how to make art. It's all about give and take, finding your strengths and passions and putting whatever they may be into the game that you produce, while doing your best to cover for whatever parts you're less skilled at.

I'm also not a jam admin, just a programmer who's passionate about their work.