Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Aug 12, 2015 · View creator page →

Creator of

Recent community posts

Updated it to version 2b! 8-directional shooting, it changes just a few lines of code in the player's create and step events. I had to change the size of the sprite to rotate it in 8 directions, so the value bullets are created had to be changed in every shooting script as well.

Hiya! Sorry for taking so long to reply.

It sounds like there's an issue with the depth sorting between obj_skyboxcontrol and the other objects... drawing has a bunch of odd quirks in GMS2 compared to previous versions, e.g. depth sorting doesn't work in Draw GUI event. Looks like ortho and perspective drawing are drawn in separate passes so ortho always is drawn last. To just get the track to draw properly, you could try commenting out the code in the Draw event of the obj_skyboxcontrol object. (You might wanna set up a background color in the room instead as a placeholder so that the window gets cleared each draw frame).

Not sure what the best way to solve the problem is, depends a bit on what graphical style you wanna go for in your game. If you want a stylish celshaded look you could keep a solid background color, for a more realistic style you could add some code in e.g. stage_model_create() so that it creates a skybox as well (the simplest approach would be to just add walls at the X and Y boundaries but it might look a bit flat). You can make texture atlases bigger than 2x2 (to add in some new sky textures etc), just don't forget to update the atlas-size arguments to stage_model_create() so that it gets the correct size - there's no info in the graphic asset that can be used for this so it needs to be provided off-band.

I'll see what I can do~

When I saw the "physical games" option I just kinda assumed you'd be required to have physical goods to ship if you picked that, so I can see why people misfile their PDFs.

You can have multiple versions of a game at different price points, so you could have base game with all DLC disabled + base game with all DLC installed available as different options. (For instance either including the expansion files in the full-package version, or compiling two different versions of the executable with DLC checks hardcoded to either "no" or "yes") There's no itchio-intrinsic way to make it more granular than that at the moment, though. (You can have any number of tiers but it doesn't really make sense for DLC that don't have ordering dependencies, like character packs)

I looked into the code a bit (was so long since I did this project I've forgotten how it works :P). The panels used for movement actually are objects, that's probably since it's mouse-controlled and I wanted an easy way to let you click on them. Enemies use them too, they're just deleting them right afterwards so they're not shown to the player. I do use queues and priority queues to order stuff, though, so if you absolutely don't wanna touch data structures this is a bit of a no go.

Depends a bit depending on which object, but most block-type objects are 4 d3d_draw_wall and 2 d3d_draw_floor calls (so the top, bottom and sides can have different textures).

Apology accepted... it's been like half a year, I'd forgotten all about the thing by now, don't worry :P Just learn from it and be careful about saying too harsh stuff in someone's face next time, I guess.

Sharing with a team would be acceptable, also it's in the EULA (the human-readable TLDR is something like "If one team member has a copy, everyone in the team can use it without having to buy their own copy"). There's a human-readable summary at the top, you could just read that if you wanna know about the rules, the legal text is mostly there  to legally protect me. It has to be there even if nobody is gonna bother reading it, that's the rules of this day and age...

(2 edits)

No idea, I've never tried. The engine is quite a performance hog and the HTML5 version of GM doesn't have super good performance since it's doubly interpreted, and you'd lose out on both hardware-accelerated 3D rendering and hardware lights. Also I'm pretty sure the way the mouse position is read to let you aim with the mouse just wouldn't work in HTML5 (since you can't control the mouse position other than on the desktop ports, and the code is based on resetting the mouse to the center of the screen all the time so you get motion from its absolute position).

(2 edits)

Cool, always a joy to see you guys play my games! :)

I think the AI rubberbanding needs some work, I think the "I'm constantly stuck in last place" situation is because the AI adapts to whichever player has the best position... maybe I should experiment a bit with having them adapt for the average player position or something, all of them trying to match whoever's in 1st place makes it kinda empty at the far back of the pack... Didn't really get to try out multiplayer a lot during development, since I don't have any friends ;w; (Mostly just set up 4 players using spare controllers to check the game didn't spontaneously combust, and then called it a day)

(You lose speed driving uphill and gain speed driving downhill, but I think you mostly saw the AI boost/slow down and not the effects of your actual speed change)

That sounds cool too! I guess with individual glyphs you have more freedom to try out unique combinations the font maker might not have thought of (that's how the traditional smiley was born, after all :P) but there's probably a bigger potential to make professional-looking symbols if they're handmade because you can make sure they look good. Decisions, decisions... actually, you could always include the radicals used to build the dingbats as separate characters to bump up the character count without additional effort :P (Assuming you make stuff like "=w=" which makes sense to break up like that, of course)

I see sprite sizes more as recommendations than requirements ;) NES games still did this even with all their limitations, mostly by using more than one sprite, with the sword in one sprite and the character in the other... this also let the designers use a different color palette for the sword as a bonus effect. Check out the sword powerup in Kirby's Adventure, for an example of this... but Zelda 1 and Castlevania 1-3 all did this approach as well. (In modern days, you can of course have it all in the same sprite for convenience)

The attack doesn't look super natural since just the sword is moving, you ideally want the character's entire body to move a little bit to show the weight of the attack. For the second attack, you'd want the sword to start BEHIND the character, that gives you a much more impressive arc to swing it over. First attack also could benefit from that, I guess, the knight moving the sword back to charge up as much power as possible before stabbing with it.


Notice how the character leans backward in the first frame and leans forward in the frames during and after the slashing motion.

I'd recommend drawing in a 16x16 grid size, it's the smallest possible size you can make stuff look actually GOOD and a lot of classic games were made with it :P Don't worry too much about restricting character sizes to 16x16, use the grid size as a recommendation. Having a base size makes it easier to make things fit together.

Some feedback on your art:

  • For a beginner, you're better than average! Don't get discouraged, you've got talent. Doesn't mean you don't need more practice though :P
  • Misty's outline style doesn't match the tiles. You should settle on either black outlines or no outlines, and use it consistently for everything. Having both just looks weird. Outlines makes things "pop out" more, so usually you'd have stronger oulines for characters than background tiles (since you want stuff like enemies and items to be easy to distinguish from background objects that don't do anything)
  • Having random irregular pixels makes things look more natural and less like perfect rectangles and circles. All real objects are subject to wear and tear and stop being perfectly shaped pretty easily. Almost all of your examples lack that, so they look kinda flat and unnatural as a result.
  • You're pillowshading, which means "have darker stuff around the entire outside of everything". This makes stuff look unnatural and not good.  Mostly the stairs suffer from this. Try to put the light shade in the top left corner, the dark stuff in the bottom and on the right, so the shading isn't symmetrical, and things will instantly look much better.

One thing that irks me a ton with fonts I otherwise like is when characters/sequences like "~". ":3" and "<3" don't look good in text... I might not be a VN creator, but I still write a lot of dialogue in my games, and being robbed of an easy way to put emotes is  a pretty nasty surprise. Having special heart characters, symmetrical 3s that look great in smileys, long curly tildes, perhaps even the small omega or a curlier w for OwO and its ilk... you get my drift, providing nice characters that can be used for smileys and verticons would be a big plus in my book~

In almost every example of this I can come up with, amnesiac characters almost always becomes opposed to whatever they were doing before they lost their memory. I think it's a nice symbol for how we all have deep regrets, and chore-y things we do because we have to (e.g. being stuck in a job we hate because it's a reliable source of being able to eat). Losing all your memories means you get to start from a blank slate, free of all that.

I've done like ONE tutorial and skimmed through the docs, I don't even know how to use it myself yet :P

One of the guys that have written some of the official tutorials is making youtube tutorials, though, might wanna check his channel out:

First of all, Undertale was made in Game Maker... main issue with GM is that the code is interpreted, so it's slow. (Unity and Godot compiles stuff into C++/C#) But you can definitely make complex stuff in Game Maker, especially if you're doing a 2D game (GM's 3D in particular is notoriously slow, and it has no innate 3D model editor or even WYSIWYG level editor)

I can vouch for Godot too, it's specifically made to be easy to use for people that aren't programmers, and after sifting through some basic tutorials I can kinda agree with that. Unity is getting a bad reputation for creating asset flips these days, and they recently did an out-of-nowhere EULA change that screwed over a lot of people. I'd avoid that if I were you, even if it's got a lot of support.

Well, I passed the interview, so that means it answered enough, right? I'm not even an US citizen in the first place.

You forgot "admins actually caring about quality control", that's a pretty huge good thing with Itch in my book :)

Also, having tried a few venues, Itch definitely has the most streamlined flow for releasing projects... pretty nice when most of the stuff you release are jam games and you don't feel like making a million images of weird sizes and go through 20 steps of paperwork just to make a sloppy 72-hour project available to the general public.

If you go into the settings for a game you've published, there's a tool that lets you generate HTML code to embed it in other webpages, I think it even has the option to let users buy the game directly there instead of having to go to the Itchio page.

1,7 GB is pretty huge... you might wanna be aware that on 32-bit systems, you physically can't use more than 2GB of memory at once, including what the OS is using. I hope you're dynamically loading and unloading resources during the game rather than loading all 1,7 gig at once at startup, otherwise chances are your game will have lots of random crashes on players with low-end hardware.

(For instance, GameMaker:Studio does this by default, and the GMS1 runner is 32-bit, so it will have this issue for big games even on a 64-bit system)

(1 edit)

The only thing I had issues with personally (after doing some Google Translate of the most legalese words) was one of the last fields, "capacity in which acting"... which was a freeform field instead of a dropdown menu. I just winged it and wrote "individual" (since I'm planning to file my indie game income as "hobby" when doing my swedish taxes next year, which seems to be the most appropriate given my circumstances), but it really was the final straw in my impression of that thing's UX. I mean, if there's only a set number of possible capacities in which you can act, why NOT have those be the only you can choose from? Being forced to guess whether what you're writing is a valid answer or not is pretty frustrating.

I've heard that there's a big industry in the US that exclusively makes tax form support software, and which are lobbying a lot to keep the paperwork as convoluted as possible so they can keep making money... not sure if it's true or just a conspiracy theory, though.

Cool stuff, always a joy to watch your videos :3

I'm also curious about this, so I'll subscribe to the topic and see what the answer is~

There's a lot of bad antivirus programs out there, and even a bunch of malware that claims it's antivirus (PC Optimizer Pro, anyone?). I remember the infamous case of Norton Antivirus deleting itself thinking it was a virus. It's good to stay vigilant, and make sure good programs STAY good :P

The models all are created from paths, I have no experience with "proper" 3D modelling (Blender etc) so I wouldn't really know how to import new ones.

  • Path0, 1 and 2 respectively are the silhouette of the car at the center, a bit outside the center, and at the left/right sides.
  • PxLengthFactor is the downscaling factor from path coordinates to model coordinates (the paths are pretty big thanks to how the grid is defaulted).
  • W0, W1, W2 and W3 are how far left/right from the center the paths are placed when used as a guide for the model. These are raw model coordinates, they don't use the PxLengthFactor. So for instance having a higher W0 means the cockpit is wider, having a W3 much higher than W2 makes the car have bigger wings, and so on.
  • W3 must always be greater than W2, W2 greater than W1, and so on. (You don't NEED them to be greater, but the model will clip into itself if not).
  • The texture is mapped like this: every horizontal 25% of the texture is used for the section between two W*s. So the first 25% of the texture are used for the section between -W0 and +W0, the next 25% are used for the section between W0 and W1 on both sides, and so on. It's stretched evenly from the front of the vehicle to the back (the top of the texture maps to the start of the path, the bottom to the end of the path)
  • Currently the model doesn't affect the collision mask at all, the cars all use the car sprite as a mask. You could extract the car's length from the modelling script by storing the "xx" variable of the first and last iteration (first iteration's lower value + last iteration's higher value, it's an array) and the W3 (outermost width)... those will give you the bounds of the car's model's bounding box, and then if you used an ellipsoid collision you'd get an okayish result. Probably would be the easiest to make a circle-shaped sprite for collision masks (with Ellipse collision mask settings, sprites default to "rectangle") and then scale image_xscale / image_yscale based on the bounding box size so the sprite covers the same region (e.g. if W3 is 8 and the sprite is 32x32, image_yscale should be 0.5 because (8*2)/32 = 0.5)

Hope this helps :)

Fixed version is uploaded! It's just a change of like 3 lines, so it might be easier to just manually apply the git diff to your existing project:

diff --git a/ b/
index 622e83f..59e20a7 100644
--- a/
+++ b/
@@ -105 +105 @@
-  <constants number="8">
+  <constants number="9">
@@ -108,0 +109 @@
+    <constant name="TRACK_U_PRECISION">10000</constant>
diff --git a/ b/
index 3073c84..0d4bd06 100644
--- a/
+++ b/
@@ -36,0 +37 @@ u = 1.00//Forward coordinate
diff --git a/ b/
index c55c5c8..c8882e3 100644
--- a/
+++ b/
@@ -73 +73,2 @@ global.ufactor      = 1/global.tracklength
+global.uufactor     = TRACK_U_PRECISION/global.tracklength
@@ -105,0 +107 @@ for(car = 0; car < global.cars_total; car++){
+    n.uu= n.u*TRACK_U_PRECISION
diff --git a/ b/
index 3e6cf06..3f204c1 100644
--- a/
+++ b/
@@ -16 +16,2 @@ alpha       = angle_difference(trackdir,argument0)
-u          += lengthdir_x(argument1*global.ufactor,alpha)
+uu         += lengthdir_x(argument1*global.uufactor,alpha)

Okay, I think I've figured it out! It's GM's float numbers being too imprecise, essentially. I added a bit of a hack to make the track position bigger to have more decimals around, and that solved the problem.

Here's the changes you need to do:

  • In obj_trackcontrol's create event, below the line that sets "global.ufactor", add something like global.uufactor     = 1000/global.tracklength
  • When trackcontrol creates cars, below the line "n.u = u", add the line n.uu= n.u*1000
  • In player_apply_movement, remove the line that sets u and replace it with the following two lines:
    • uu         += lengthdir_x(argument1*global.uufactor,alpha)
      u = uu/1000

You could substitute the 1000 for any number you want, I'll do that with a macro and then export an updated version of the engine file.

I think I've figured out what's happening, but not WHY... the U position (how far you're along the track) seems to only update in increments of a set size, so at small speeds it get snapped back after updating. The W position (sidewaysness) isn't affected by this, so you can move sideways just fine.

Thanks, managed to get a 100% reproduction method working now... angle slightly, stand still, then tap 'accelerate'. I'll see i I can figure out what causes it.

I definitely could, it's not impossible. You're welcome~

I agree 100% with @mattornb about people not wanting to buy stuff because they're uncertain about quality - the main reason I hesitate to buy things is because I'm uncertain of the quality, and even if it's a monetary loss I could live with even if it's so crap I won't ever play/use it, I still feel really uncomfortable buying something I know nothing at all about. When I'm on the fence to buy a game, I don't check out reviews. I check out Let's Plays or trailers that show gameplay footage (preferably the former), because I want to judge if it's good or not by myself.

The description makes me think of "Air Control", could that be it?

It'd be helpful if you described the game a bit so we don't need to actually check it out to come with suggestions :P (That's a pretty transparent way to try to get easy traffic, I'm not gonna fall for that).

Some generic stuff that always makes a game better:

  • Screenshake and explosions. A little visual juice makes anything feel more polished.
  • More playable characters that have unique mechanics. Forget "he jumps higher but runs more slowly", you want stuff like "can't attack, but can deflect enemy bullets back at them" or "flips gravity upside-down instead of jumping". Characters like this that makes a game play entirely differently can essentially make all the old stuff feel like new again.
  • More levels. If they have unique gimmicks like glowy fireballs or slippery ice you can make levels feel more distinct from each other, even if you don't even get that much gameplay differences from them.
  • Funny writing. You don't need to force cutscenes down players' throats, but ads for "PIZZA BURGER: THE BURGER WITH A PIZZA INSIDE" off in the background and funny flavor text for all the upgrades you can unlock can help setting the mood for a game.

Daemon Detective Gaiden 2

This is a really good topic! One thing I'd like to add is "make backups". I've lost a good chunk of old projects because I didn't have them properly backed up over the years, but since I figured out how to use Git it's not happened again for quite some time. And having a Git repo and doing commits regularly can get you out of a lot of trouble in case something goes awry - e.g. if you introduce a breaking change without realizing and now EVERYTHING stopped working. Or if you wanna try something out, realize it didn't work, and want to quickly get rid of it.

After 4 years of development, it's finally completed. My magnum opus, the sequel nobody knew they wanted. Or perhaps the sequel nobody wanted, can't quite really tell where to put myself on the optimism versus modesty scale. The only thing I know for sure is that it's a relief to finally be able to hit that big red "release the game now" button after all this time! There's probably a few bugs left to squash and I've been terrible at building hype, but I can't stall forever. It's time to finally do this. The world might not be ready, I might not be ready, but the game is.

So... a madman's ramblings aside, what is all the fuss about?

Daemon Detective Gaiden 2 is a retro action platformer!

Nobody has done that before, right?

...yeah, I know everyone does that. But! It's not just any ol' boring platformer...


  • Local co-op for up to 4 players! Also comes with a VS mode!
  • 12 playable characters with unique skills! Find your favorite and put an unique spin to your platforming adventure!
  • Over 70 hand-crafted levels to explore and a dozen bosses to overcome!
  • Non-linear progression where worlds can be completed in any order and you can skip almost half of the collectibles!
  • Tons of different powerups to mess around with!
  • Quality hand-made 16-bit visuals and music!
  • Assist mode that lets you dial down various aspects of the game difficulty as you see fit for a smoother experience, or dial them up past the normal max values to turn DDG2 into a proper rage-game!
  • Fully customizable controls! Use Xinput gamepads straight outta the box, cram four players around a single keyboard, or anything in between!
  • Lots of unlockable secrets!
  • Speedrunner-friendly automatic timekeeping that bookmarks the time you first beat the game, and the time you 100%-ed it!

Itchio page



(2 edits)

Ver. 1.0.4

  • Fixed the visual issues with shields in the museum by moving NPC positions around a bit.
  • Fixed a potential audio issue.

Ver. 1.0.3

  • First public release.
  • Added special case collision checking to Gaping Abyss to prevent the floor from getting stuck in players when it's opening and closing.
  • Fixed a Spark going inside the walls in Outer Wall.
  • Changed the way shields are drawn to make them look less glitchy on the world map and museum map. (This necessitated duct taping up the entire world-map drawing code a bit)
  • Dragon Fireballs now dissipate after a set time even if they're still on-screen. (This time is generous enough that they'd normally leave the screen before the timer runs out, but short enough that Gaping Abyss will be less frustrating if you keep missing the weak point)

Ver 1.0.2, 1.0.1, 1.0.0

  • Fixed various bugs based on test-player feedback.