GMC Jam Discussion GMC Jam 40 - 10 YEAR ANNIVERSARY SPECIAL πŸŽ‰

Status
Not open for further replies.

Mightyjor

Member
Hey everyone! I just did a small stream today for a few games. Keep in mind I'm making some pretty detailed reviews this jam so you can get a little insight on how I rate games. I probably won't do another stream this jam, but I think I'm getting a feel for how Twitch works and I'll probably use it mostly for timed game jams and writing music in the future.

Here are the games I played:

7:13 - Apocalypse Party
21:41 - Party Mountain
31:00 - Keyboard Hero
44:00 - Jenka Dungeon



Here is a link to the stream:
Stream
 

Evanski

Raccoon Lord
Forum Staff
Moderator
twitchtv/evanskistudios

STREAM TODAY! 12pm EST / 5pm UTC
LAST CHANCE
to see me play jam games or to see me play your jam game live!
If you're here for the stream I will play your game even if I already have!

If you want me to play your game early let me know
First spot has already been claimed but those who dont show for the stream will be skipped
 
Hey folks. If I get the chance I plan to do written reviews for all the games. However, my schedule is looking very packed for the entire month of March so It looks unlikely. I will do my best to get to them if I have free time though.
 

GameDevDan

Former Jam Host
Moderator
GMC Elder
@GameDevDan It doesn't really matter when you play the game because there will have been someone before you who set the meta. You're not missing out by playing early, or late for that matter.

By the way, you can see how many players have come before you (and who beat the game) on the stone tablet in-game. If you called yourself Dan, there seem to have been 20 people before you :)
Fair enough! I did play it for a little while and there didn't seem to be many items laying around or anything - so I'll still try to get back and play again before I write my proper review.
 

The M

Member
There are four in the hub and one at the end of each branch (but due to a bug you unfortunately can't reach all of them). Since you can only carry three at a time you'll have to swap if you come across a different one.
 

GameDevDan

Former Jam Host
Moderator
GMC Elder
21/76 reviews done so far (2nd batch added)

Some great entries this time around!

Two points I wanna make in a broad sense so far, to improve all future jam entries:
  • It's not currently against the jam rules to have offensive things in your game, but it probably is against the forum rules (of which interpretation is at YYG's discretion). Since the jam host does not have time to play all games before making the zip it's probably wise to at least provide a warning at the start of your game for offensive content, or just not enter offensive things at all.
  • Less serious than the first one but a good tip which I have raised before (including last jam!) - Do not make the failure conditions in your game too punishing. Reviewers have 70+ games to play and limited time to do so. If getting hurt in your game costs the player upwards of 5 minutes of play time they're probably going to just quit (I certainly do).
 

Yal

🐧 *penguin noises*
GMC Elder
Less serious than the first one but a good tip which I have raised before (including last jam!) - Do not make the failure conditions in your game too punishing. Reviewers have 70+ games to play and limited time to do so. If getting hurt in your game costs the player upwards of 5 minutes of play time they're probably going to just quit (I certainly do).
This goes for win conditions as well. If your first level is a maze that takes 15 minutes to beat with no guidance or sub-goals, chances are players will drop out before they beat it. (I watched some streams of my entries and noticed people quitting before they hit the "interesting" part because the start was too slow, so I guess I borked this despite actively trying to work against it)
 

Alice

Darts addict
Forum Staff
Moderator
This goes for win conditions as well. If your first level is a maze that takes 15 minutes to beat with no guidance or sub-goals, chances are players will drop out before they beat it. (I watched some streams of my entries and noticed people quitting before they hit the "interesting" part because the start was too slow, so I guess I borked this despite actively trying to work against it)
Maybe "progress conditions" more precisely? For example, if I have a platformer with 10 levels and I complete each in 3 minutes, I spend 30 minutes total and yet it (hopefully) doesn't feel like time wasted.
Sometimes the progress doesn't even need to be as much about hard game mechanics (e.g. "you are at this level now") and more about the general feeling of becoming better at the game. That's how I got S rank on Keyboard Hero, at least. ;)

By the way, if you speak about the balloon game: I think it would be a mighty fine walking simulator if the fog wasn't so thick and the game had graphics that can run on potato (see how 3 Mice in a Trenchcoat do that). The game lagged for me a lot and it took me quite a perseverance to complete it.
 

Yal

🐧 *penguin noises*
GMC Elder
Maybe "progress conditions" more precisely? For example, if I have a platformer with 10 levels and I complete each in 3 minutes, I spend 30 minutes total and yet it (hopefully) doesn't feel like time wasted.
Sometimes the progress doesn't even need to be as much about hard game mechanics (e.g. "you are at this level now") and more about the general feeling of becoming better at the game. That's how I got S rank on Keyboard Hero, at least. ;)

By the way, if you speak about the balloon game: I think it would be a mighty fine walking simulator if the fog wasn't so thick and the game had graphics that can run on potato (see how 3 Mice in a Trenchcoat do that). The game lagged for me a lot and it took me quite a perseverance to complete it.
Yeah, "progress conditions" is probably a better term (I meant short-term victories, not "beating the entire game" win). If it takes 30 minutes to beat the first level, jam players will drop out unless it's a really good level. Getting that dopamine kick early so you can tell what you're supposed to do helps a lot in quelling frustration.

Lag as in dropping below 30 fps? The physics are intended to run at 60 fps but I changed it last second to 30 so it'd be more likely to reach it on jammers' computers, and then just doubled the player's max movement speed to compensate. It kinda feels like it's constantly lagging as a result (especially since I didn't mess with acceleration/inertia so momentum response is kinda bleh) so it might not have been the right call... but if it's not even able to maintain 30 fps there's a bigger issue at play somewhere.
 

Alice

Darts addict
Forum Staff
Moderator
Lag as in dropping below 30 fps? The physics are intended to run at 60 fps but I changed it last second to 30 so it'd be more likely to reach it on jammers' computers, and then just doubled the player's max movement speed to compensate. It kinda feels like it's constantly lagging as a result (especially since I didn't mess with acceleration/inertia so momentum response is kinda bleh) so it might not have been the right call... but if it's not even able to maintain 30 fps there's a bigger issue at play somewhere.
I'd need to check again, but I'm pretty sure on Evan's stream the game ran smoother than on my laptop. Mind that this laptop has no dedicated GPU, so it may also play part for GPU-reliant shaders?

Maybe if you made a build with debug overlay enabled, I could actually see whether the game performs on intended 30 FPS, or is it lagging below that?
 

Yal

🐧 *penguin noises*
GMC Elder
I'd need to check again, but I'm pretty sure on Evan's stream the game ran smoother than on my laptop. Mind that this laptop has no dedicated GPU, so it may also play part for GPU-reliant shaders?
Oh yeah, that could also explain it. The level model is pretty big (in my testing it still takes the same amount of time to draw as a single sprite, but I've got a decent GPU) and all the visual effects require ~6 full screen's worth of surfaces to be drawn with different shaders. If that's run on a dinky "spreadsheets and mail" built-in GPU (or worse, a "virtualized GPU" run in the CPU) it's probably not going to have the same level of performance.
 

Evanski

Raccoon Lord
Forum Staff
Moderator
Oh yeah, that could also explain it. The level model is pretty big (in my testing it still takes the same amount of time to draw as a single sprite, but I've got a decent GPU) and all the visual effects require ~6 full screen's worth of surfaces to be drawn with different shaders. If that's run on a dinky "spreadsheets and mail" built-in GPU (or worse, a "virtualized GPU" run in the CPU) it's probably not going to have the same level of performance.
its like with three mice in a trenchcoat
@Xor must have one hell of a pc, as mine chugged trying to push good qaulity
i had the stream running also so that didn't help
but i had to play in windowed mode with the graphics on normal

otherwise potato worked until i touched walls


Moral of the story is plan your game around people not your pc specs, might run fine on your pc but not on someone else's toaster ;)
 

Gizmo199

Member
its like with three mice in a trenchcoat
@Xor must have one hell of a pc, as mine chugged trying to push good qaulity
i had the stream running also so that didn't help
but i had to play in windowed mode with the graphics on normal

otherwise potato worked until i touched walls


Moral of the story is plan your game around people not your pc specs, might run fine on your pc but not on someone else's toaster ;)
Yeah we had a similar issue. We didn't think about baking the shadows into the surface on the creation and instead had it set up to just blur the surface every frame which caused some MASSIVE slowdowns. Ended up getting it fixed now but it's definitely a learning curve. The one downside to GM3D is getting that optimization down. For us, it was the least suspect candidate that chugged our game. :/ Live and learn!
 

Evanski

Raccoon Lord
Forum Staff
Moderator
Yeah we had a similar issue. We didn't think about baking the shadows into the surface on the creation and instead had it set up to just blur the surface every frame which caused some MASSIVE slowdowns. Ended up getting it fixed now but it's definitely a learning curve. The one downside to GM3D is getting that optimization down. For us, it was the least suspect candidate that chugged our game. :/ Live and learn!
But see a Jam is also really good for testing out new ideas, as you have load of playtesters the best being people who record there playthroughs!
Jams are a playtesting gold mine!
 

Gizmo199

Member
But see a Jam is also really good for testing out new ideas, as you have load of playtesters the best being people who record there playthroughs!
Jams are a playtesting gold mine!
Exactly! I always tell people jams are the best place to get playtesting on systems you've designed to yourself 1000+ times. That way you can refine your ideas and the systems you already know how to make like the back of your hand. :p
 

kburkhart84

Firehammer Games
You guys talking about Jams being good for concept playtesting...100% agree here. I very much had that thought when deciding what game to make. And the feedback has been quite valuable so far as well. It shows that the concept has a commercial viability(even if as a casual game), and serves as a prototype to know how to best implement the thing once I do.
 

Yal

🐧 *penguin noises*
GMC Elder
You guys talking about Jams being good for concept playtesting...100% agree here. I very much had that thought when deciding what game to make. And the feedback has been quite valuable so far as well. It shows that the concept has a commercial viability(even if as a casual game), and serves as a prototype to know how to best implement the thing once I do.
My long-time recurring jam issue is making a too safe concept instead of trying something completely new... can't tell if I've gotten my creativity damaged through soul-crushing school / work or if it's my general hate of new things, because even being aware of it doesn't help me get around it :/
 

curato

Member
My long-time recurring jam issue is making a too safe concept instead of trying something completely new... can't tell if I've gotten my creativity damaged through soul-crushing school / work or if it's my general hate of new things, because even being aware of it doesn't help me get around it :/
It is hard to find that sweet spot between abitious and easy to find that idea that pushes you but is doing able in the time frame.
 

Xor

@XorDev
its like with three mice in a trenchcoat
@Xor must have one hell of a pc, as mine chugged trying to push good qaulity
i had the stream running also so that didn't help
but i had to play in windowed mode with the graphics on normal

otherwise potato worked until i touched walls


Moral of the story is plan your game around people not your pc specs, might run fine on your pc but not on someone else's toaster ;)
I'm using an RTX 2060 and Ryzen 5 2600.
One of my goals was to pack in as many graphical effects as I could and to push the limits. I wanted to make something that's never been done in a GMC Jam before and the performance was more of an afterthought.
During testing, I stress-tested all the settings beyond what was in the release version. Snidr and Bart also tested and the CPU systems were a greater bottleneck than the GPU effects.

I had actually planned to work on the graphics more with general tuning and optimizing, but we were behind schedule halfway through, so I shifted gears to the other game mechanics.
In retrospect, I should have focused on making the game fun first and added polish after. But there were many things I learned during the jam. With a new team you never quite know how your role will fit in and in my case I was learning some new systems for the collisions and animations.

All-in-all I'm quite happy with the result considering how ambitious the concept was. I'm even happier with the post-jam version which wrapped things up further.

EDIT: Oh and what do you mean by "otherwise potato worked until i touched walls"?
 

Gizmo199

Member
you can see it in my stream
the moment I got close to a wall the fps tanked
Yeah, I think it could have something to do with colmesh (I'm assuming that's what was used for collisions in their game). I've noticed in testing that meshes with alot of vertices will tank the fps (ie the inside of an archway). Just depends on the model(s).
 

Xor

@XorDev
Yeah, I think it could have something to do with colmesh (I'm assuming that's what was used for collisions in their game). I've noticed in testing that meshes with alot of vertices will tank the fps (ie the inside of an archway). Just depends on the model(s).
Yeah, that'd be ColMesh. Hmm, I thought we sorted most of the performance issues with it
 

Gizmo199

Member
Yeah, that'd be ColMesh. Hmm, I thought we sorted most of the performance issues with it
Maybe. I ran into that issue when I was playing with ColMesh just before the jam. Could be some hidden vertices in the models or something that didn't get cleaned up maybe? πŸ€·β€β™‚οΈ

Edit: Either way it's less on colmesh and more on the models I think. As far as my understanding goes it basically adds each vertex triangle to a hash map and accesses only the data near where collisions should be calculated. The only thing that maybe colmesh could optimize would be possibly building the collision meshes only based on outward-facing vertices? That might get rid of concave fixtures but would definitely fix the fps drops. Again though, I don't really know *exactly* what is going on behind the scenes in colmesh. :p
 
Last edited:

Xor

@XorDev
Maybe. I ran into that issue when I was playing with ColMesh just before the jam. Could be some hidden vertices in the models or something that didn't get cleaned up maybe? πŸ€·β€β™‚οΈ
Early one we were using the .OBJs for the collision meshes, just for easy testing, but it was slow so we switched to simple geometric colliders like cuboids. So that shouldn't be an issue, not sure
@TheSnidr any ideas? When EvanSki got close to the walls the game slowed a lot
 

Gizmo199

Member
Early one we were using the .OBJs for the collision meshes, just for easy testing, but it was slow so we switched to simple geometric colliders like cuboids. So that shouldn't be an issue, not sure
@TheSnidr any ideas? When EvanSki got close to the walls the game slowed a lot
Oh I see. Well in that case do you think it could be something with the SSAO processing? Evanski got hit hard with ours but mainly only when the blur shaders were involved. Baking them into the scene fixed a lot of it. Maybe only using that SSAO shader for non-static objects instead, and just pre-baking AO into the textures before? IDK. haha.

EDIT: I only say it might be the SSAO since it might be processing a lot of stuff when objects get close to walls to produce the shadowing effect. But that's your wheelhouse so idk. haha

EDIT2: I also don't think it could be colmesh since its only walls that slow it down. I would assume floors would too if it was something going on with ColMesh's processing.
 

Xor

@XorDev
Oh I see. Well in that case do you think it could be something with the SSAO processing? Evanski got hit hard with ours but mainly only when the blur shaders were involved. Baking them into the scene fixed a lot of it. Maybe only using that SSAO shader for non-static objects instead, and just pre-baking AO into the textures before? IDK. haha.

EDIT: I only say it might be the SSAO since it might be processing a lot of stuff when objects get close to walls to produce the shadowing effect. But that's your wheelhouse so idk. haha

EDIT2: I also don't think it could be colmesh since its only walls that slow it down. I would assume floors would too if it was something going on with ColMesh's processing.
Well, firstly, the SSAO and blur are applied with the same number of samples every frame so there's no reason for performance to change when close to a wall. It's the same number of steps up close or far away.
Secondly, the SSAO, shadow mapping, and blur are disabled in the "Potato" mode so it can't be from those shaders in that mode.
 

Evanski

Raccoon Lord
Forum Staff
Moderator
Yeah, I think it could have something to do with colmesh (I'm assuming that's what was used for collisions in their game). I've noticed in testing that meshes with alot of vertices will tank the fps (ie the inside of an archway). Just depends on the model(s).
Yeah, that'd be ColMesh. Hmm, I thought we sorted most of the performance issues with it
Maybe. I ran into that issue when I was playing with ColMesh just before the jam. Could be some hidden vertices in the models or something that didn't get cleaned up maybe? πŸ€·β€β™‚οΈ

Edit: Either way it's less on colmesh and more on the models I think. As far as my understanding goes it basically adds each vertex triangle to a hash map and accesses only the data near where collisions should be calculated. The only thing that maybe colmesh could optimize would be possibly building the collision meshes only based on outward-facing vertices? That might get rid of concave fixtures but would definitely fix the fps drops. Again though, I don't really know *exactly* what is going on behind the scenes in colmesh. :p
Oh I see. Well in that case do you think it could be something with the SSAO processing? Evanski got hit hard with ours but mainly only when the blur shaders were involved. Baking them into the scene fixed a lot of it. Maybe only using that SSAO shader for non-static objects instead, and just pre-baking AO into the textures before? IDK. haha.

EDIT: I only say it might be the SSAO since it might be processing a lot of stuff when objects get close to walls to produce the shadowing effect. But that's your wheelhouse so idk. haha

EDIT2: I also don't think it could be colmesh since its only walls that slow it down. I would assume floors would too if it was something going on with ColMesh's processing.
Well, firstly, the SSAO and blur are applied with the same number of samples every frame so there's no reason for performance to change when close to a wall. It's the same number of steps up close or far away.
Secondly, the SSAO, shadow mapping, and blur are disabled in the "Potato" mode so it can't be from those shaders in that mode.
 

Gizmo199

Member
Well, firstly, the SSAO and blur are applied with the same number of samples every frame so there's no reason for performance to change when close to a wall. It's the same number of steps up close or far away.
Secondly, the SSAO, shadow mapping, and blur are disabled in the "Potato" mode so it can't be from those shaders in that mode.
Ah okay, Yeah, that makes sense. hmm. Weird. So yeah, it must be something with colmesh then unless there are still passes being processed and just not rendered. Just seems weird that it's only walls. Unless there is something weird going on with the wall-to-floor intersections maybe? Anywho, sorry for my arm-chair analysis. haha. I should probably actually look at the project you all released before trying to interject my theories. haha. ;P
 

TheSnidr

Heavy metal viking dentist
GMC Elder
Interesting! Will have to look into it. The ColMesh is subdivided into smaller regions so that only nearby primitives are processed. I'd expect the collisions to be super fast since I ended up optimizing the hell out of it by using primitives instead of triangles. For me, the player's step event seems to take the same amount of time regardless of whether I'm close to a wall or not.
Fun fact: We nearly submitted the game without subdividing the ColMesh at all. I randomly tested it before going to work monday morning and realized that it ran rather slowly. Turned out the player was checking for collisions against over 600 primitives instead of just the nearest 4-6 xD

So yeah, I have no good explanation as to why it runs slower near walls right now, but thanks for telling us!
 

Gizmo199

Member
You can look at the source code if you wish. I might investigate this later.
Interesting! Will have to look into it. The ColMesh is subdivided into smaller regions so that only nearby primitives are processed. I'd expect the collisions to be super fast since I ended up optimizing the hell out of it by using primitives instead of triangles. For me, the player's step event seems to take the same amount of time regardless of whether I'm close to a wall or not.
Fun fact: We nearly submitted the game without subdividing the ColMesh at all. I randomly tested it before going to work monday morning and realized that it ran rather slowly. Turned out the player was checking for collisions against over 600 primitives instead of just the nearest 4-6 xD

So yeah, I have no good explanation as to why it runs slower near walls right now, but thanks for telling us!
Just grabbed it. Thanks! Ran it with a GPU check in the best mode and was getting nearly 100% use consistently but that's to be expected I think. I did notice about a 100 FPS drop when colliding with the walls and @EvanSki commented that his CPU could be an issue in our vid but honestly I dont think it's that. Gotta work now but if I personally come across anything I will let ya know! :p

Thanks again for you all's hard work and especially for releasing it! So cool to see under the curtain!! Haha.
 

kburkhart84

Firehammer Games
Hi, I'm sorry I noticed several people had problems running my entry, Keyboard Hero.
I realized it's because I packaged it as 32-bit compatible only (the external dll's were 32-bit).

Here is a link to both 32/64-bit versions if anyone else is having issues: https://tadashibashi.itch.io/keyboard-hero
I don't think the issue is what you think it is. I'm on 64-bit Windows and your 32-bit external dlls are working fine(which makes sense because the GM runner is 32-bit, and because 64-bit systems can generally run 32-bit executables just fine). I was able to play and review your entry just fine(though I'm not posting the reviews until I'm done with all of them).
 
I don't think the issue is what you think it is. I'm on 64-bit Windows and your 32-bit external dlls are working fine(which makes sense because the GM runner is 32-bit, and because 64-bit systems can generally run 32-bit executables just fine). I was able to play and review your entry just fine(though I'm not posting the reviews until I'm done with all of them).
Hi, it's the same for me as well, but I got a DM from someone who was having issues with it.
Once they switched the config to 64-bit mode it started running (but then crashed once a function call to the dll was made)
I also just read one of vote posts that they couldn't get it working from the jam player either so it got ranked #78 πŸ˜…
 

kburkhart84

Firehammer Games
Hi, it's the same for me as well, but I got a DM from someone who was having issues with it.
Once they switched the config to 64-bit mode it started running (but then crashed once a function call to the dll was made)
I also just read one of vote posts that they couldn't get it working from the jam player either so it got ranked #78 πŸ˜…
That's strange...I feel like it is something with their systems then, though I wouldn't really know where to start, since it works fine on my system. I do know that generally, 64-bit Windows can run 32-bit executables. I remember in the earlier days there were some compatibility issues but I rarely ran across them, and they were fixed pretty fast. It is also strange that very likely 95% of the entries are using the 32-bit runner, and we don't have issues with them. And though not all of them are using external DLLs, a couple of them are. Furthermore, the Jam Player is using an external DLL, and I haven't seen anybody with issues running it(besides the bug with the popup at the beginning that affects nothing).
 

Evanski

Raccoon Lord
Forum Staff
Moderator
Hi, it's the same for me as well, but I got a DM from someone who was having issues with it.
Once they switched the config to 64-bit mode it started running (but then crashed once a function call to the dll was made)
I also just read one of vote posts that they couldn't get it working from the jam player either so it got ranked #78 πŸ˜…
Game worked fine for me on 64x windows
if you made the post game 64 bit and the dll crashes, you need to also update the .dll's source to work on x64 as well
 
That's strange...I feel like it is something with their systems then, though I wouldn't really know where to start, since it works fine on my system. I do know that generally, 64-bit Windows can run 32-bit executables. I remember in the earlier days there were some compatibility issues but I rarely ran across them, and they were fixed pretty fast. It is also strange that very likely 95% of the entries are using the 32-bit runner, and we don't have issues with them. And though not all of them are using external DLLs, a couple of them are. Furthermore, the Jam Player is using an external DLL, and I haven't seen anybody with issues running it(besides the bug with the popup at the beginning that affects nothing).
I agree it's strange... Since I don't know much about computer architecture besides the difference in type sizes, I just figured compiling to work for 64-bit would be the easiest solution.

Game worked fine for me on 64x windows
if you made the post game 64 bit and the dll crashes, you need to also update the .dll's source to work on x64 as well
Glad to hear it worked, but yes I expected it should've worked just like that for everyone. It's not a post-jam version, but rather support for native 64-bit to address the issue the user I mentioned was having (and I suspect several others), which I've recompiled for that architecture.
 

Evanski

Raccoon Lord
Forum Staff
Moderator
Probably a good idea to post in here instead of just status updates, but I'm going to stream the jam entries myself very soon.
Looking at Sunday UTC 5-6pm. Let me know if you can make it and I'll hold off playing your game.
I'll likely attempt doing a stream the same time each day until I get through them all.

www.twitch.tv/siolforthejackal
make sure to send a message to the jam discord as well
 

curato

Member
Hi, it's the same for me as well, but I got a DM from someone who was having issues with it.
Once they switched the config to 64-bit mode it started running (but then crashed once a function call to the dll was made)
I also just read one of vote posts that they couldn't get it working from the jam player either so it got ranked #78 πŸ˜…
I know I had and issue with one entry that turned out to be the player was doing a remote run of windows from his linux station and that made the shaders crash for some reason. Running straight from windows seemed fine. Not sure if there is a way to find out if they are trying to do something similarly unique.
 

Toque

Member
Liar! Burn the witch!
We are a commonwealth country but honestly could not care of the workings of the royals. Certainly not going to pick sides for that nonsense. Does Europe still burn witches? I thought that a lost art? Perhaps a new trend? A lockdown thing. Get a dog. Long walks. Burn witches. Whats old is new again. Like ripped jeans..... Nose rings....... Im old and hard to keep track of these new trends......
 

Poizen

Member
matoset by Poizen

Game crashes even when I added globalstatsio.dat to matoparty local appdata...

After I downloaded the fixed version and removed apparently broken globalstatsio.dat file the game started working properly. It's a nice concept, but it requires tweaking. For example, worms turn way too fast, and the game has no minimap or zoomed out view which would make it easier to decide which fruit to jump to next. Also, the worms make it seem like there's some rivalry for resources going on, when in fact these worms seem to be ghosts of earlier scorers? Would be nice if they were semi-transparent so that they wouldn't take too much focus.

I like the character customisation options, but it would be really nice if I didn't have to type out the name every time.

Ranking it last, because the original Jam version crashes, whether with or without provided globalstatsio file.
The game still crashes? That's interesting - and sucky. There must be some kind of a compatibility issue I didn't realize was there. Hm.

A lot of good criticism and suggestions. True, it can be hard to navigate the stage. A minimap is a great idea though. I wish I did that. And yeah, the idea is that the other worms are ghosts of the top 10 players (though their movement is random). Would've made sense to make them translucent.

Ah, the name and the other options should save automatically. Looks like another thing that went wrong. 😬

Thanks for the review in any case!
 
Status
Not open for further replies.
Top