Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

1988stevenm

26
Posts
252
Followers
4
Following
A member registered Mar 09, 2016 · View creator page →

Creator of

Recent community posts

The "Unique Tile 1's X" and "Y" only take static numerical values. Is there a way to pass variables? I would like to make a game where the player can flip the tile they're standing on, which requires a variable.

Ah delicious, finally a good proper crash. I fixed up and reuploaded the .zip to the page, so that should be the end of that.

As for character movement, you're pretty much expected to kite the ghost since it homes in on your position like a boomerang, and being able to predict where the ghost is going to go is the key to getting rid of enemies. You can also move further from or closer to the ghost to change how far it hurtles past you. 

Are you having trouble with enemies on the first two nights as well, or just 3 and 4 with the actual moving enemies? The non-bouncer enemies are coded to swerve from the player's vicinity, though it's slower to kick in when they're at much higher speeds.

I thought having goals based on collecting icons or hitting enemies in a specific way would encourage moving around the whole screen while also kiting the ghost (whether in circles or not). Are you wanting something different from the movement and dynamic between the player and ghost, and can you elaborate on it? If enough people comment (or hit the feedback button to keep their feedback private) thinking the system should be changed or overhauled, then that's a sign of room for improvement. But so far, this is the kind of mechanic I want to stick to my guns on.

Even though the player is incentivised to run around the whole screen to collect Likes or multipliers or avoid enemies, you're rarely being forced to move to specific spots on top of juggling the ghost movement. It's unfortunate but the levels here are just supposed to ease the player in for later stages down the road with new obstacles to compound the current gameplay (rain, policemen trying to escort you into a car, people with guns, cyclists etc). The general player control will always come down to moving around the screen though, it's a low-scope project so there won't be any plans for mini-games or characters with different genres of gameplay.

Thanks for taking the time out to play the game!

1) Since I've mostly been the only person playing the game before the jam deadline, I've become somewhat accustomed to things in the game that aren't clearly conveyed to a new player. A meter above the B blocks, or even a circle-shaped gauge around the B blocks directly, might be more intuitive to show the amount of time left - whichever obscues the least amount of information about the above/surrounding blocks.

2) With the scrolling background -- is there any chance you can make a screencap of the seams between the repeating tiles? I can't seem to replicate it, or it might not register as a distortion to me (see above, becoming accustomed to certain things).

3) The part with the green blocks is concerning. Do you remember if they were glowing the same as other 'matched' blocks, or if any/many of them had been swapped before trying to clear them? I'm wondering if there's a blind spot in the code where they don't check for matches or receive the wrong information from neighboring blocks, or they were somehow not set to the same state as other instances.  Whatever the case, it's not a good look having a matching-blocks game where you're arbitrarily denied the ability to match.

Thanks for taking the time to test the game out! It's encouraging to get detailed feedback from you and everyone else. I know I'm on the right path with this game.

Thanks for the feedback! There's some stuff it seems I've taken for granted with the game so far, since I've mostly been the only person who played it before now.

1) The three levels aren't balanced to change from easy to hard. I'm intending to put ten levels together, where the first three are Tutorial Town and then the difficulty escalates. The game comes off as borderline braindead without that context, though, I see that now.

2) The multiple ghosts kind of disappear without warning. They need a visual flicker, like how the [placeholder] bouncing debris flickers when you thwomp an enemy. They also use the same code as the 'regular' ghost to follow your position and movement, so at the moment they do just end up following the same movements and end up clumping together. During the last stage of polish I'll work on trying to keep them separate from one another.  (Maybe even add ghost enemies into the game that aren't connected by tether? Give them Pac-Man ghost AI properties, like ambushing you from the side or trying to target outside the room sometimes.) At the moment it's not a big priority though - I'll likely just give the powerup-induced ghosts a colour tint for the time being and focus on future levels, future enemy AI and so on.

3) Alcohol needs a better text tutorial in the game itself. The whole game could do with a real tutorial, rather than having to read the instructions. Alcohol only increases your drunkness meter on the left of the screen and by proxy, your Likes multiplier. (The "Points" icons also need a do-over, to read "Likes" instead, and adding more social-media imagery into the game.) You can earn a couple seconds back on your timer for every 5 times you hit an enemy. That's not mentioned anywhere, on purpose - it's a secret helping hand.

4) I'll boost the text display duration. When I add that tutorial, I'll also add a page giving a better explanation of each power, even though they're generally self-explanatory. I did the same thing for a mobile project of mine called "Spring Action", whose power-ups absolutely weren't self-explanatory.

5) Thanks for the thumbs up! The game was designed with phones in mind, so if the control is intuitive and not cumbersome, that's a blessing to hear.

Yeah, I couldn't think of a compelling game mechanic for the theme that hadn't been done before - there's a YouTube devlog about a jam game called Detective Truth that basically did what I had planned. Then I got stuck on the idea 'dangerous boomerang locked onto player's position' as a mechanic instead, and worked with that instead. It's not a great Halloween-themed game, but it might have more appeal throughout the whole year in general.

Thanks for taking the time to try the game, and thanks for the feedback!

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add.

0) A jam game having an option settings is a lot to ask for, so it's nice to be able to toggle the volume settings for music and sound individually

1) Having the option of character at the start was a nice choice for the player, though it seems to be just cosmetic. I'm assuming in a future version of the game, you want to create different levels and scenarios for each character, so I'm fine if both characters act the same for now

2) Being able to click where the player will walk to with the mouse, and click on characters to walk up to them and interact with them, on top of using the right mouse click to bring up the menu, is quite helpful. It's a nice alternative to using the arrow keys, and would help the game's transition to touchscreen tablets or phones. I think if you're allowed to use the mouse, there should be a button onscreen you can click that stops time, so that the player can mostly navigate through the game with mouse or with keyboard. I don't know how difficult that would be to program in RPG Maker, though

2) The cat told me I could stop time during the tutorial, but not the key to press. I had to check a lot of different keyboard keys to find it. After sneaking a peak at Sun's review, there's apparently a button that changes the state of the flames in the boss fight as well, but I couldn't find it

3) I couldn't advance beyond the boss fight sadly. Interesting I never actually died during the fight, even with my health at 0

Saying all that I had fun with the main level and getting around the obstacles. The presentation was quite charming, it reminded me a little of the French RPG Maker project "OFF". If you are interested in expanding on this game with different boss types, time-related powers, etc etc, I would like to play that

(1 edit)

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add.

1) There should be some transition between beating the boss and bringing up the upgrade system. Fanfare and text may be a lot to ask for, under jam conditions, but a lack of even a pause for the boss to disappear is a little jarring. Because the 'confirm' key is the same as the shoot key ingame, it's feasible a person could pick their upgrade unintentionally if they thought they were supposed to mash the key

1a) The upgrade system giving the player one of three choices, regardless of their performance in the fight, is a nice idea. Other games have shops during/between stages that require collecting coins, and they create a disparity between skilled players (who don't need the endless amount of upgrades they can afford) and beginner/unskilled players (who need support easing into learning the mechanics and can't afford it)

1b) I'm not sure what your sweet/candy-themed power up does because it uses the placeholder text descriptor

2) As above, the branching paths that let the player pick between a challenge for extra kudos or a straight heal is a nice idea, especially in that players aren't relegated to one or the other based on skill - cocky players can still attempt the challenge and get facerolled by it, but that they have the choice to do is the important thing

3) In many bullet hell titles the player moves at a normal speed when tapping/not using the fire button, and shifts to a lower speed when holding the button (often accompanied by a secondary attack pattern). "Focus" mode is an interesting take on the idea, allowing you slower speed and to see your hitbox as well, independent from firing your weapon. Since the nature of the genre is all about methodically weaving through curtains of fire, it's difficult to balance your player speed so that being in slow speed constantly isn't the dominant strategy, and I think there are enough bullet patterns of changing/static speed in your boss fights to warrant switching from regular mode to "Focus" mode

Overall I kept eating shit on the final boss but I had a fun time adapting to the fights. I'd like to see this game expanded with more bosses - maybe expand the number of challenges to pick from between each one, giving it a little Bishi Bashi/Wario Ware flavor of goals to accomplish. As far as sticking to the themes of the jam goes, I can see the 'cute' but I don't fully see where the 'timer' theme fits in beyond the stopclock in the top-right. I'm assuming that comes into play once you beat all the fights proper

In GMS1.4 you were able to export your game as a regular .exe, but in GMS2 the default is a .exe installer. I hadn't realised you could send your game to people in .zip form that kept the standalone format. So I've added that to the page. The .exe and the .zip download contain the same data. If you've already downloaded the .exe, feel free to uninstall it.

"I might have gone a bit overboard with the cat count but I wanted to make the town feel alive." No, I agree with your intentions, it really aids the experience of the game having NPCs around the whole map! If my machine is just an outlier then it shouldn't be a problem, but if it's something several people bring up, the only thing I can suggest is maybe unloading/reloading models that aren't in the immediate view of the player. I think making assets outside of the player's view invisible is something Unity does by default, but it still runs the code for them.

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add.

1) Good to see an options menu, even offers a fullscreen toggle. Game window even allows for resizing it at the user's discretion. I don't love how it can distort the graphics, but then I'm a spriteart resolution purist so this is a minor quibble at best

2) When the player on the menu goes from the title to the level select or to the options, and vice versa, having the blocks all jump off the screen is a very cool presentational decision

3) I have to admit the "RESTART LVL" prompt in the tutorial threw me off, to me it looks like a lowercase 'a' more than a 'Q' key. The size of the keyboard graphics doesn't give you a lot to work with, and I can empathise with that since I've made a bunch of sprite fonts before

4) When the tank-treads robot is active, there is a box represented by trails of 'ants' [like in Photoshop] that shows where the player is supposed to jump on top of the robot. The game seems to treat the width of the box as the width of the invisible "platform" on top of the robot. This is good, as it's more forgiving towards the player positioning themselves on the robot, but it can mean the player is floating above and to the side of the tank-treads robot as it moves around and it looks unintentional (even though the player is technically floating a little above the ground at all times). It's a minor quibble, but it may help if the platform actually drawn above the robot were stretched out to fit the whole invisible box, without stretching the collision detection of the robot itself

5) Still in the tutorial, and I think something needs to be elaborated on. It's clearly conveyed you have to power up the robot, but what I expected to have to do afterwards was get the robot to the wall and jump from the robot to the top of the wall. Which didn't work, the player's jump height didn't reach it. Instead you push the robot to the wall, then push the player towards the wall and it slides up and over onto the top. While I had all the time in the world to figure this out eventually, I don't feel this was the solution conveyed to me in the tutorial (especially with the control explanation for "Jump" next to the wall). The slide also seems to be a one-time check; if I move from the platform to the ground and back on, then push at the wall, I won't slide up. Though, if I simply jump on the robot and move it towards the wall, then the player slides all the way up by themselves

5a) I hadn't realised the robot was capable of pushing its platform upward until the first proper level - the robot isn't allowed to fall down pits, so it floats over them. The platform and its supports can be seen behind the robot, and the supports end shortly before the robot's position. I might have been to blame for not trying out the full "Up, Down, Left, Right" robot control prompts in the tutorial, but a combination of these two things gave me a very "aha, so that's how that works" moment

6) In the second level I can give the walking robot [in the shaft at the bottom of the level] the battery, so it walks through the blocks and then stops again. Then I walk over to the leftmost wall of where I'm in, and slide up the wall, grabbing the battery, and going through the ceiling. This lets me inside the black void at the top of the screen, letting me go right and completing the level. This isn't the intended solution (the actual level path involving the spider robot is pretty cool, I like the wall/ceiling-climbing movement), I just wanted to point out it can be exploited for an easy 3-star rating

7) There doesn't seem to be a reliable way to keep the spinning robot alive in the third level. If I hold the acceleration down too much the battery drains much faster, I understand. But holding back, the robot either makes it up to the two small walls beyond the battery, or the wall jutting out from the ceiling, and runs out at either point. Knowing when each robot has run out of battery is clearly conveyed, but the actual amount could do with a visible meter overhead, or ideally something that keeps with the relative lack of UI

Overall I like the concept, I think there's some potential here. There could see more levels being made between 01 and 02 with the platform/tank-treads robot, doing everything you can with that formula, before moving onto the block-breaking and spider-crawling robots and wringing every level idea you can from those, before moving on from there with even more robot ideas. A football-themed level where you switch from robot to robot as each takes the ball from one to the next?

Thanks for taking the time to play the game and thanks for the feedback! Even with some of the changes made it's still primarily a Match-3 game so there isn't a lot new to say about it, at least for the time being. I want to add different modes or a different framing device for the gameplay in the future that will give people more to talk about.

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add. I'll also try not to repeat points that other people have made that you have responded to.

1) Having both a controls and options button on the main menu, along with a pause feature in the game itself, was very helpful. Allowing the player to set their own time limit and thus their own pace is also a good idea, it fits into the more gentle aesthetic of the game

2) As silly as it sounds, I assumed from the start I had the mail on hand and the "0/10" in the bottom left means I had currently delivered to 0 of the 10 target houses.  I ended up wandering some of the map the first time around, hitting E on different houses, before I saw the post office again and pressing E turned that number into "10/10". Since you even start in front of the building, I'm not sure what to say about my thought process, only that maybe appending "letters in bag" at the end of the /10 would prevent fringe cases like mine. That's probably what the envelope icon is meant to convey, but it was still a little ambiguous on my first run

3) The map isn't too large to make memorising it a problem, if you stick to filling out one side of one street at a time you're normally good to go. It would be more convenient if there were a second post office on the other side of the map that you could replenish your mail at, though, as opposed to running back to the same place each time. Not sure how I would narratively explain the mail you need showing up at that building, but I think it could be handwaved

4) Sometimes the NPC or non-playable cats' pathfinding means they squat in front of houses and refuse to leave, and while it's likely random it still feels a little aggravating

5) Does the game run at a consistent 15fps framerate on most machines? I don't have a frame of reference for everyone else's experience with this game, but the game seemed to run really choppy on my computer

Overall it was a pleasant, mostly relaxing experience and it's not every day I can say I played a game about delivering the post. Outside of the obvious ideas (more maps) I'm not sure what additions or improvements I could suggest. Perhaps a cat-sized van for players who want to further immerse themselves in the role? Or a mouse mode, playing on the same map delivering from a smaller post office to mice villagers, but you're all far shrunk down compared to the cat villagers?

(1 edit)

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add.

0) The alternate skin from walking to the left on the first screen is a nice touch

1) From the tutorial, it seems like the player's exact location ends in relation to the block you hook, but it can vary. You can either end up on the side of it, or buried inside it entirely. I wonder if would help to change the collision code to have the player look for blocks a step ahead of their movement (something like "var inst = instance_place(x+x_movement,y+y_movement, obj_block; if instance_exists(inst) then..." and move the player as close to the centre of the block as possible without overlapping, then stop the horizontal movement)

1a) Hooking a block above you and breaking it with the jump button, to be able to pass through the gap you made, is a great idea. However the player often isn't aligned close to the centre of the block, and will bump their head on a block adjacent to the one that was destroyed instead. It would be a good idea to lerp the player's x position to the block's x position, or y for y position

2) You already have varying jump heights and a good walljump that allows for neutral jumps to bounce away from the wall, the general plaforming movement feels nice. I didn't have any issue with the keyboard controls, but that's because I'm right-handed and used to playing games with Z, X, C etc binded to controls

2a) Would being able to throw the hook diagonally (walking forward and holding up while hitting Z) break the level design?

2b) Not being killed instantly by the ceiling of the room is a nice concession to the player

3) A pause state might seem counterproductive to a game with a time limit, but it would help if the player is caught unawares by IRL matters or wants to take notes on the controls and features

4) I'm not sure of the reason behind it, but occasionally the floating heart's hitbox seems to change and make it impossible to collect unless you approach it from the right side. The graphic itself normally represents the area you need to overlap to collect it, but in these cases it isn't affected that way

5) I was hit by a fishbowl enemy while trying to hook through two rows of blocks below where I was standing. I believe I tried to mash the hook button, and then the game crashed. The hook graphic was visible but the chain and the player weren't (probably due to the temp invincibility).

FATAL ERROR in action number 1 of  Step Event0 for object obj_aGrabber:
Unable to find any instance for object index '106872' name '<undefined>' at gml_Object_obj_aGrabber_Step_0
stack frame is
gml_Object_obj_aGrabber_Step_0 (line -1)

Overall though it's been a fun experience and it's a good start for a game. It sounds like you already have a bunch of ideas for keeping future gameplay loops fresh, but I'll make some suggestions anyways. Penalty icons that handicap the player (inability to jump, extra enemies spawn in, ice terrain, spikes appearing, etc etc) in exchange for a points multiplier. A 'custom settings' option on the pre-game screen that allows the player to change some settings (toggling some penalties to last the whole game or rarely/never appear, reducing/increasing the speed of moving walls, reducing/increasing enemy rate, removing "!" icons, etc) that will in turn add onto or remove from the base points total the player earns through the next game. A competitive co-operative multiplayer where the players can sabotage each other to keep the highest points total before the clock runs down.

(1 edit)

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add, especially given the ambition of the project.

1) Because the tools and seed menus have icons on the user interface, and the mouse can be used to interact with tiles and the main menu, I kept trying to click on the tool menu with the mouse rather than remembering to use the hotkeys. That might be more on me not understanding the layout of the controls, but I made the assumption the mouse would work based on it working with other menu buttons

1a) The game's layout is tile-based, and you can walk around non-orthogonally which gives more freedom of movement. It makes colliding with objects a little more finicky than if you were restricted to the grid, which is the trade-off. It might help in the future to put some code checking the player's position compared to the object they're colliding with, and if they're close to a corner edge of the object while still holding towards it, they'll slide in that direction until they're no longer colliding, possibly moving right around the corner. It sounds strange on paper. But the tile-based Zelda games from LTTP and Link's Awakening onward did it to help smooth the player's movement around the enviroment.

1b) It would be nice if, since you can move diagonally, you could also interact with tiles that are diagonally around you (clicking on the weeds/log that are a tile below and to the left, for example) or even tiles that aren't just in front of the character based on her direction

2) I received a NullReferenceException error at one point, and I think it was based on digging the ground then moving forward during the animation to overlap with a rock - at that point the game froze for a couple seconds

3) Buying seeds and clicking them in the inventory doesn't always seem to make them appear in the "E"-assigned seed menu. I tried tilling a patch of ground twice and pressing "E" and depending on the game, sometimes it didn't drop the seeds. Not sure if it's something I'm doing wrong

3a) Destroying a rock/log/weed also destroys any seeds adjacent to them. Which is something I should have logically realised, but if you're seeding each region you've cleared and move onto clearing the next, it's a bit of a shock

I can see there's a lot of work put into the game, and I don't want to write it off, but I just can't make any headway at the moment. Progress sometimes seems like it's based on whether the game decided it should work on loading up. If you're planning on working further on the project, I'd like to revisit it at a later point and give my proper thoughts on the whole game rather than dismiss it based on what was made to meet a deadline.  My sister is big into farming sims and management games, so this would be up her alley as well.

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add.

1) Your general platforming feels solid. There isn't a lot of skidding when changing direction of movement, you slow down slightly when sliding down walls, and the game checks for inputs when you're about to touch the ground. The limited number of walljumps is a system that's easy to understand after a few goes experimenting with it, maybe not very well conveyed upfront though.

1a) Walljumping by holding the direction the wall is in works fine. Walljumping doesn't work if you're standing alongside the wall, and it doesn't work if you press jump in tandem with holding the opposite direction - so if you try to walljump away from the wall, you end up falling uselessly downward. You have to walljump towards the wall, and then veer back, which can eat away the momentum you need to reach the opposite wall in time. Since there is an input buffer for checking the jump button before touching the floor, there should be a similar buffer when the player is not overlapping a platform/wall, where the player isn't affected by gravity for a few frames, while the game looks for jumping inputs. It would be ideal to have the game detect if the player is pressing jump while they're mid-air up against a wall, and have them automatically jump in the opposite direction, the same result as the player holding the opposite direction from the wall while trying to walljump

1b) Also, I really feel that walljump count should be bumped up to 4 at the very least. Either that or those walljump-restoring gems should respawn in place after a short time. Because of everything mentioned above, it's very finicky doing challenges that use up all the walljumps, even with the gems restoring them

1c) A more forgiving hitbox would be much appreciated, especially on the castle parapets-themed level with spikes lining all the walls. Checkpoints would also be much appreciated. Though, I feel like these are things you wanted to implemented but didn't have time before the deadline

2) The intro level (the hub??) doesn't seem to follow the same rules as the levels do when it comes to the music acting as a timer, so the first level restarting after a quick audio fade-out almost seemed like a bug at first. It caught me off-guard, anyway. It's difficult because I want to suggest something like 'a text prompt explaining the mechanic' but that betrays the point of using the audio, which is to NOT rely on text to convey the timer. Having a game with no HUD can be an artistic choice that pays off if everything is still reworked to be clearly understood. At the very least, I'd like if it the music faded in a little at the beginning when the timer resets the level. It's a sudden audio jump that doesn't really help the presentation

4) As I mentioned above, I do like the audio mechanic! That and the general lack of UI clutter give the game an interesting experience to get immersed into. Since the game would have to lack an options menu, save-file screens etc to keep up the aesthetic, maybe it would be better for a Deluxe version to have a separate .exe for handling saves and resolution/sound settings, control settings and the like

Currently the game feels like it belongs in the 'rage' subgenre of platformers, which really contrasts against the audiovisual presentation. Maybe that's an intentional contrast you can capitalise on? Regardless, it's a good start for a platformer but it really needs to shine and stand out more in some form of fashion. Look at what we have at the moment (narrative, mechanics, level design, etc) and see what can be changed to make it more outstanding, since things like "good graphics" or "good story" or "a levelling system/skill tree" aren't really unique selling points - hundreds of games have them. What makes your game (potentially) one of a kind? What can be iterated upon? Whether that's really working on the UI-less presentation, or finding more ways to integrate audio mechanics

I know how it is to be a game dev on a deadline and have ideas of how to expand on a project, how it can be fixed or added to, etc. So please understand if I mention things you already want to fix or add.

1) Being able to choose the resolution and toggle the audio would have been a nice quality-of-life feature. I don't know if Unity allows for these settings to be toggled by default, or whether they have to be hard-coded in or not. This is just a minor presentation quibble

2) Selecting options with the mouse is easier than a cursor guided by arrow keys/WASD, but switching between keyboard (player control) and mouse (menu control) repeatedly is a bit cumbersome. This is just a minor presentation quibble, though if I had to keep restarting a level or keep going back to the menu to access the next level, in an upgraded version of this game, it would become annoying quickly

3) Either the jump height is a little too low, or the platforms are a little too far apart vertically. I keep knocking into the side of the platform I want to reach, and getting stuck/slowly sliding down. Then I hit 'jump' repeatedly to sort of climb up over the side. It would be a good learning exercise to study things like acceleration and deceleration, holding the jump button for a longer jump, buffering the player's 'jump' input before they touch the ground, etc. There's a good video with a slightly hyperbolic title on this subject.

4) Because I took a while to get used to the platforming, the first level was actually the hardest of the three! I kept falling off the bottom of the screen or not making it before time ran out. When I got used to 'climbing' platforms, all three levels were a breeze, thankfully.

5) Controlling two characters to reach a goal is a good pitch for this genre (the idea would work especially well with a gamepad, dual-stick control scheme) - and making the boy have to take a certain path is also a good idea. You've taken the core decisions the player has to make in platforming and added something to make them interesting but not convoluted. It gives the girl little to do by comparison, though. You've probably already thought of level designs where the platforms for both characters are separated from one another, strictly linear paths. Perhaps you could also make it so that certain platforms can only be landed on by one character or the other? (Platforms could start out as neutral until jumped on, then they change colour to signify who can stand on them.)

Whether you decide to expand on this game or move on to another project, it's a good start for a platformer.

I'd say that's intentional (you have a lot more downtime to setup combos during the slow stages, but you're supposed to be forced to scramble and think on your feet much more as your rank goes up), but I don't doubt the actual timer speed is wildly unbalanced and needs tweaking further down the road.

Thanks for taking the time to play the game and thanks for the feedback!

A game crash was reported to me so I temporarily hid the download while I fixed it. I don't mind people checking the game out of curiosity, but if I decide to work on it again it'll be from scratch with a new engine.

I uploaded the fixed file to the page, just rename it to your current copy of the game and it should read from the same save file and option settings. Let me know if there are other unexpected developments.

(1 edit)

I like the theory behind the multiplier because you capitalise on getting the largest number of enemies on-screen to score points, rather than firing yourself willy-nilly -- I coded a similar multiplier in a previous shmup project (a combo meter for each enemy destroyed, the meter slowly depleting otherwise). But the current scoring mechanic -- with all enemy bullets on-screen turning into coins when an enemy is destroyed -- asks mostly the same thing of the player, to capitalise on the enemy layout and bullet patterns; so it might seem redundant to have both ingame.

That's good to hear it's working. Thanks for looking out for me!

Well that's depressing, the file should be all-inclusive and the spr_level01 resource should definitely be part of the file. I uploaded a new build 1.0.0.3, hopefully that works. Otherwise I don't rightly know what's going on

https://1988stevenm.itch.io/the-big-blow-up-gamejam-build

I'd like feedback on (1.0.0.9.exe/PS4 beta)

XBox 360/One/PS4 controller compatibility - does the game recognise a PS4 controller has been connected natively? Does it accept player input as responsibly as it would a native 360 controller and not crash the game instead? Does the game allow for four players using a combination of PS4 and XBox360/One controllers? Are there any issues when disconnecting/reconnecting controllers inside and outside of matches or during the pause menu?

I need help on (1.0.0.6/1.0.0.9)

Convincing sound effect creation - how would I go about creating convincing sounds, using a process that doesn't involve sfxr? A crunchy compressed sound sample would fit fairly well, an 8-bit soundchip sample would clash aesthetically with the rest of the game

Thanks for the feedback. Versus mode lets you select a stage a play, choosing from the bonus stages as well as the arcade levels - both modes allow up to four players, human or computer.

The paint % idea is interesting and I'll implement that in the final game, I also want to come up with some other fun bonus stages that put all the players on an even playing field. If I do create further modes mixing up the stage layout, it'll be after the arcade and versus modes are finished and polished up (adding items and modifiers, cutscenes, etc).

Thank you for the feedback. Enemy fire should always be clear to the player, so I will work on a new design for them (and the gems/player projectiles) to make them more distinctive.