πŸ€‘ Indie game storeπŸ™Œ Free gamesπŸ˜‚ Fun games😨 Horror games
πŸ‘· Game development🎨 AssetsπŸ“š Comics
πŸŽ‰ Sales🎁 Bundles


A member registered Aug 12, 2015 · View creator page β†’

Creator of

Recent community posts

I've been around this whole time, I just never finished a lot of games  :3



Sorry about that part where you loop back to a previous room if you fail the jump, it probably was a little bit mean putting it in.... ^^'

You've got really good production values for a tiny channel, btw.... clearly defined visual identity/style, good audio/visual quality, proper editing, and the ability to come up with witty things to say without stuttering or going "eeeeeeh" all the time! You've earned yourself a new subscriber :)

There's a bunch of things that might cause it...

  • Do you have DirectX installed? I think the game uses Dx9, and Dx11 should be backwards-compatible, but I'm not sure.
  • Do you have enough RAM and VRAM? I assume you do, since the typical GM requirements aren't that high, but if you try running the game on an office-level computer it might have the bare minimum.
  • Do you have an audio device? There was a bug that caused the GM runner to crash if no audio device was found; most systems will set up a dummy software audio device even if you don't have any speakers connected but not all of them will.
  • It might be a 32-bit vs 64-bit architecture issue, Windows doesn't handle that very well.

(The standalone is a GM8.1 game, so it's a bit archaic, but it really shouldn't crash)

Some things you could try is running the game in compatibility mode for an earlier windows version (and try both with and without the flag for 32-bit emulation if you're on a 64-bit machine), and run it from the command line to see if its exit status is something like "out of memory" or "segmentation fault" which could help troubleshooting the problem.

(Edited 2 times)

Did you increase the size of the active region as well? (Lighting is controlled by objects, so it won't happen until they load in)

If you did that and it still doesn't work, there's a few things you could try...

  • Have lighting objects always be active, it shouldn't add too much of a performance penalty and it'll prevent them from popping into existence too abruptly. (But it WILL add a bit of performance penalty, so be careful about not having hundreds of lighting objects in the same room)
  • Try to avoid clustering too many lighting objects together, since only the 8 nearest ones are used (since there's a hard limit to how many lights the rendering system can handle) and which are the nearest ones can change suddenly.
  • It could be worth messing around with lighting sources' radius so they light stuff up less when they're far away (e.g. some code like radius = min(normalradius,<big number> - <number smaller than 1>*point_distance(x,y,player.x,player.y) ), but it could be a bit of work to fine-tune it. (The small number is the factor light radius changes with compared to distance, something like 0.25 should work well, and the big number should be the distance the light radius is fully restored, divided with the small number... if I didn't get the maths wrong, at least x3)
(Edited 1 time)

Shouldn't be impossible, I'll see what I can do!

The main idea is that you make the level in "layers" corresponding to different Z layers, then the engine puts them together when the room loads (moving everything to the first layer, and adapting their Z values accordingly). It's mainly there to make it easier to design 3D levels in GM's room editor and doesn't have any benefits other than that.

(There's a bunch of backgrounds that add a grid to the Room Editor; those backgrounds are used to figure out the size of the Z-slices, so it gets a bit more WYSIWYG than if you had to keep track of a "slice_width" variable or somesuch)

There's also the terrain/ceiling-terrain (which is probably what I named "Level Grid" originally... was a while since I touched the source code last!), which is essentially support for less rectangular ground, and which can be randomly generated. Its purpose is to make the ground in outdoors / cave areas look less like it's made out of cubes, but I couldn't figure out good ways to CONTROL it from within the editor, so it's a bit of an experimental feature. There's special objects that will generate (and draw) terrain if you place them in a room, TERRAINCONTROL and TERRAINCEILCONTROL, look into the init_terrain() script (which has a commented-out block of code that randomly generates terrain) and the "field" room for an example of how to use it.

The "layers that get stacked on top of each other" and polygonal terrain features aren't mutually exclusive, either, so this could be used for levels like a tower in the middle of a forest, or such. (In Dearelict, the trees are actually just very tall cylinders with a bark texture, players just ASSUMES they're trees that stretch so far into the darkness they can't see any of their leaves. Tricks like this can be useful to save CPU power for enemies and stuff like that, GM and 3D rendering isn't really a match made in heaven...)

No, Jam Tactics Engine is its own thing (and much more basic - Shattered World's source file is full of special cases and a bunch of design decisions that made things a bit messy, and I feel like it might not be the optimal learning aid, nor very easy to adapt into a very different game. Jam Tactics Engine is meant to be a simple framework that can be expanded into more or less anything).

This is the second time I've seen this thing appear, so I did a bit of research. Found this GMC topic that suggests that you should call d3d_set_identity() every 10,000 draws, when you're using an integrated graphics card you have less VRAM and that puts a hard-cap on how much 3D drawing you can do. (And I use a dedicated graphics card, so I never ran into this issue myself while developing the engine)

One way to see if it works is to just add a d3d_transform_set_identity() to the first line of the drawing code of the terrain blocks (e.g. the obj_wall_sandstone_block64 and perhaps a couple of its relatives) so that it flushes the vertex buffers occasionally... it's going to be overkill to do it before you draw EVERY piece of terrain, and it could have a performance impact, but it should solve the problem. If it solves the problem, you're pretty much good to go, and what you'd do is something like this (to reduce the performance impact):

  • Add a script called "flush_the_vertex_buffer" and set up a global counter variable
  • Reset it to 0 every step in the controller object
  • add the flush_the_vertex_buffer script to every terrain block's draw event
  • The script should increment the global counter, and if it's above a certain value (e.g. 10,000), set it to 0 and call d3d_transform_set_identity().

If you can confirm adding in some d3d_transform_set_identity() calls solves the problem for you, I'll get a fix for this into the source file ASAP.

Hmm, weird... *scratches head*

Then my two educated guesses would be that you either don't have DirectX9 installed (since DirectX11 is standard nowadays) or that your screen is plugged into the integrated graphics port instead of the graphics card's port. The game is pretty badly optimized (GMS isn't really the best tool to do 3D with) but I've been able to run it on my 2011 potato laptop.

From what I can tell, that error message means that you don't have enough VRAM (graphics card memory). Not sure if there's much I can do about that. Are you having a lots of other stuff running when you try to play the game, and/or do you know if your graphics card is old?

What is the error and when does it occur? Unless I know what it is, I can't really fix it :P

Thanks, glad you like it so far! ^__^

To extend the range of sight: obj_titlescreen's Create event, the code block labelled "Init global variables". There's two variables that controls this: global.darkness (which controls how far you can see) and global.activate (which controls when stuff is loaded in). Make sure global.activate is always bigger than global.darkness, or stuff will just visibly load in and it just looks weird.

GameMaker:Studio, and there's both a GMS1.x and a GMS2.x source file included :3

Sounds like a plan... it's always possible to change it later in case you get better at 3D maths later, and working with 3D is a good way to learn about 3D, I guess :P

IMO the hardest part is figuring out how 3D vectors work (which needs linear algebra so you can actually do math with them - but you need to learn visualizing them as well in order to figure out HOW to use them for any given problem), once you've got that part down you can solve more or less any problem by doodling down a few lines on paper and putting variable names at all angles and lengths you'll need to use in the game. Don't underestimate doodling on paper, it helps visualizing stuff MUCH better than the maths formulae on their own :3

No and yes, respectively :P

If you're still around (and have a copy of GameMaker Studio) the source code is available now~

All right, I did some project bookkeeping recently so I actually know where the project is now... I've uploaded the source code as well now :3

The actual implementation is pretty simple:

//at the start
<make 3 lists named list_phrasing, list_genre, list_quirk>
<add idea pieces to them>
//when you press a button
ds_list_shuffle(list_quirk) my_string = list_phrasing[|0]+list_genre[|0]+list_quirk[|0]+"?"

First of all,  the easy thing: the level grid size is based on the width of the background you use for the level grid. (See the script terrain_flat_to_3d for the details). So basically, if you want a grid that's 2560 pixels wide, use a background that's 2560 pixels wide. Any size should work, but unless it's a multiple of your room grid size it's gonna be hard to keep objects from different layers aligned :P

For the second question... the 3D maths is kinda hard... which is why I skipped that part in the engine :P You'll need to find a reference point (e.g. the player's x, y and zbottom), then find the delta X/Y/Z to the tip of the gun, then spawn the bullet there. If you know the length of all the 'moving parts' (e.g. "spine", "shoulders" and "arm+gun"), you could just compute the X/Y/Z vectors of each part individually and then the tip of the gun should be there.

For each thing...

  • X coordinate should be lengthdir_x(1,angle against 'forwards')*lengthdir_x(1,angle against 'up')*(length of thing along X axis)
  • Y coordinate should be lengthdir_y(1,angle against 'forwards')*lengthdir_x(1,angle against 'up')*(length of thing along Y axis)
  • Z coordinate should be lengthdir_y(1,angle against 'up')*(length of thing along Z axis)

And since the spine is always just Z coordinate and shoulders are always just XY coordinates, this should be possible to simplify a bit. But yeah, it won't really get any easier than this, so guess why games like Wolfenstein and Doom had the gun in the middle so you didn't need to keep track of anything other than the Z coordinate :P

Yeah, the object has no code and there's no graphics for it either. I probably planned to add enemies at some point, then scrapped those plans but forgot to remove the object.

Not built-in, but you could always just add in code that automatically controls the camera angle and remove the WASD camera control code. It's a really difficult subject to tackle and it's very game-dependent, so there's no universal way to do this and it felt out of scope for this engine.

I'll recommend checking out this GDC talk on the subject, it's really helpful (they go through algorithms and stuff for things like camera whiskers):

It uses a hardcoded array of text (or rather 3, for different parts of the text) ...so it's not that customizable, I guess. I could always upload the source code for maximal customizability, but that'd just be of use if you have GMS. (Or maybe I could consider adding text file support or something... once I find the source code again :P)

Incredibly believable game - watched Vinny's stream of it and even after the glitched guy talking about how everyone's trapped in the system, I still couldn't tell if this was seriously a lost PS1 game or not until I clicked the link and saw the itchio page stating it wasn't :P

Lots of people has said this already, but you've done an amazing job on this!

I more or less only use Game Maker, so I'm kinda biased here... it's not 100% optimal for RPGs, but it's very easy to build point-and-click interfaces with it since there's a WYSIWYG scene editor and several click events (which get translated to touchscreen events on mobile ports). It's also basically single-click cross-platform once you've set up developer accounts for the Play Store and the App Store (and so on) but I don't have a lot of experience with that at the moment.

You can currently (ends in 9 days from when I'm posting this) get GMS 1.x very cheaply on the Humble Bundle, so I'd recommend looking into that: https://www.humblebundle.com/gamemaker-rebundle

$1 gets you the PC license, and for $15 you get the mobile ports as well plus some other aux stuff like source code.

Getting the HB version also makes you eligible for the 40% GMS 2.x discount when you upgrade your 1.x license, so it's definitely a nice deal if you think it's interesting. 2.x still is basically in beta and not super-stable, so I'd stick around with 1.x for now and just keep an eye on when the upgrade discount will end.

If you DO get Game Maker, I recommend getting a GMC account as well so you can discuss stuff and find tutorials and learning resources easily: https://forum.yoyogames.com/index.php

It's never too late to learn :P

A good first step might be brushing up on your english skills... you can not just write more convincing advertising material the more fluent you get, you also end up writing more professional-looking material. A lot of people can be really strict with typos and grammar errors and that can really hurt your first impression.

(I'm personally not a native english speaker either, and I still do some basic mistakes like mixing up 'was' and 'were', but I'm actively trying to improve all the time)

Wouldn't really say I'm hugely successful or anything, but here's what I've learned from 10 years of making games:

Join game jams, and always do something you've uncomfortable with as your entry. It's good to try out new ideas to widen your skillset and views in general, and jam games are either forgotten instantly (if they're bad) by everyone including their maker, or they're a good prototype for making a "real" game later. It's the dev equivalent of throwing stuff onto the wall and seeing what sticks, basically. You also get experience at prioritizing in a stressful situation, which you WILL go through both as a hobby developer and an industry developer... might as well try to grind for some stat points in that right away, right?

Be careful about "publishers". I signed a contract with one once, and ended up having to do all the media-attention work myself in the end anyway. So I basically signed a contract that gave me less money and some exclusivity clauses to be aware of that did absolutely nothing towards getting me that big breakthrough I was dreaming about.

You'll need to work for your attention. I started off searching for the '#indiedev' and '#gamedev' hashtags on Twitter each day, following 10-20 people that seemed legit, and hoping they'd follow back (and then unfollow them later if they didn't). It's not really the best or most ethical way of getting networking done, I realized later (right now I'm posting witty comments and actually talking to people there instead) but when you're completely new it doesn't hurt to get your numbers up in any way you can. But actually networking with people gives you more attention in the long run, it's just a slower process. Probably doesn't hurt to use both a little bit of pure-advertisement spamminess on the side, just don't overdo it to the point where people get fed up on you or it'll actually hurt you in the long run.

Write to-do lists on actual paper. Sounds a bit silly, but I find it has plenty of uses. It's incredibly satisfying to crumble up a fully done to-do list in your hand and crushing it with your raw power and stuff, for a start, and it gives you a reason to look away from the screen regularly (which help reduce eye strain). It also means you can jot down ideas even when you're doing something else, like cooking or sleeping, which helps you from forgetting spark-of-the-moment ideas. It's also faster to doodle up diagrams and sketches on paper than using a CAD program, and doing those things more often on your todo lists can make some things much easier to do (e.g. coming up with level design ideas), increasing your overall productivity.

Ideas are cheap, execution is expensive. Always look for ways to cut corners. A typical example of this is the AI design maxim: "An AI isn't smart, it just appears smart in the situations the players see it in". Trying to make things perfect not only is impossible to truly succeed at, because you can always find ways to make something incrementally better, it takes a lot less time and effort than making the minimal viable product and just polish the rough edges a bit. And most players won't even notice the extra effort, either. So if it ain't broke, don't fix it. The last thing you need is unnecessary work nobody will care about in the long run. Also, on a related note, beware of feature creep. You'll never get games complete if you keep deciding to add new stuff to them when they're almost complete - several of my biggest project failed in the end because I kept adding new stuff instead of finishing them, and I either ended up making the engine so convoluted the game broke down into buggy messes, or I got bored at the projects and wanted to try new stuff. Don't do that.

I'd say trying to make something that's not a direct clone of an existing game is a pretty good idea, since you stand out more... especially considering a lot of phone games has been cloned literal hundreds of times.

One thing I'd suggest, if you're able to code a fun-enough system, would be to make an RPG game. JRPG content is relatively bite-sized (you can cram a few random battles into your bus ride, etc) and it's also MUCH faster to make than to consume once you've got the engine going - you can just plop down a few encounters in various settings in less than 5 minutes and you've created an hour of gameplay. Games like Fire Emblem and Disgaea can offer completely different experiences with the same enemies depending on how they're placed on the map, what obstacles and other terrain is around, and so on, and the player feels like they're making tangible progress whenever their numbers goes up. The market for infinite runners and other casual games is pretty much flooded, but RPGs are much rarer... there's definitely a chance to make a break there.

Also, if you're planning to have ads in your game, having a Tactics game means the player will spend a lot of time staring into a map screen coming up with strategies... which is perfect for static/banner ads.

Hmm, you neglected to mention what I personally think is the most important difference... GameJolt is 100% about games, Itchio lets you sell stuff like game assets, digital books, and even physical goods. So itchio basically is a marketplace for everything, so all kinds of indies can use it, not just indie game developers. AFAIK it's pretty much the first place that does this in the west, which is really cool~

(and yeah, I'm a bit biased here since I do game assets more than I do games nowadays... sorry about that :P)

Also, having used both: Itchio is much easier to use - it feels like every workflow and menu in GameJolt has a few extraneous steps added for no apparent reason, and you basically need to have a guide open in another tab to get ANYTHING done because a lot of stuff is so obtuse. Itchio not only has easier steps for everything, most of them are optional.

Good, I've been curious about how the date is set (I have a bunch of backburner projects that's been drafts for ages) and this answers my questions about it. I agree that projects' publish date being set when they're restricted-access might not be the best rule, since this will just hurt projects that are legitimately trying to polish and test their stuff properly... it's better to base it on when the project first goes public.

Maybe having a page where you can browse "recent devlogs" could fill the purpose of having a 'recently changed' category for games while being slightly harder to game as a system? (since it's hopefully relatively easy for people to see when someone posts shallow devlogs with no real value, especially if they do it constantly, while you lose that nuance if you'd sort games based on when a file or page was last changed... it's a much more incremental thing that's harder to judge). Just my 2 cents.

Wouldn't really be good customer support if I let someone wait several weeks for a mistake this simple, now would it? :P

Glad you got it working~

(Edited 1 time)

I dug into this a bit and I believe I've found what causes it... Z-coordinates are stored in a grid based around 32x32 blocks, so if you accidentally place a slope or a block off this grid, the slopes will get the wrong Z value because the correct cell might not be set (or the slopes access the next cell rather than the appropriate cell). Either make sure your room grid is set to 32x32 when placing terrain, or change the value of the GRIDSIZE_PX macro to 16.

Glad I could help out! Even helping out a single person like this made it worth the effort hosting the program :3

Everything is still placed in a single GM room... the view scrolling effect is just there because the generator is inspired by Binding of Isaac, if you remove it and have the view follow the player normally it becomes a single cohesive room.

This engine uses predefined room layouts, room maps are stored in bitmaps so you can quickly draw new rooms using Game Maker's sprite editor. There's also separate sprites for normal rooms, boss rooms, player start rooms and treasure rooms, so you can easily have some layouts only be used in some contexts, and this system probably wouldn't be too hard to extend either (e.g. you could randomly change some rooms' layouts to layouts from your "SPECIAL STICK ROOM" if you want 2-3 stick rooms in the middle of all the normal ones).

Sure. First of all, what exactly is a "stick room"? Is it related to tree data structures in some way?

If this error is displayed, it means your computer doesn't support shaders. One possibility could be that you don't have the DirectX 9 runtime installed, you should be able to get it from here: https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=35

If that fails, the problem is probably that your GPU doesn't support OpenGL, and you'll need to remove the shader from the game (and remove the code in parent_enemy that sets and resets the shader before drawing, so you don't have a reference to a nonexistent resource).

There isn't a Linux version of the game itself. The source code is cross-platform, however, since it doesn't use any OS-specific functionality, and that's probably what makes this show up as a Linux app for you. (I don't have a GMS1 Linux license and haven't really prioritized converting all my games to GMS2 yet due to how little traffic most of them get)

Glad to hear it's resolved!

Yeah, Chrome can be a bit overprotective when it comes to downloading stuff, especially from indie sources. I personally use Firefox... but that's mostly because Chrome uses so much system resources it lags some of my other programs :P

Tried logging out and downloading them anonymously just to make sure it's not just because I'm the file owner, and I could download and run both the EXE version and the ZIP version.

If you can't run the EXE properly, try downloading the ZIP version, it's a bit more compatible.

Just checked, it should still be up... it's at the bottom of the page, after the "buy now" button you should see a "download demo" button.

I'd probably go about it this way, editing obj_player a bit:

  • Add a new variable iscrouching which defaults to false, is set to true in the step event whenever the crouching key is held (you'll need to edit the get_keys script to add in checks for the new crouch key) and false otherwise.
  • Add in a new code block in the Begin Step event:  when the crouching variable is true, lower zheightmovespeedmax and jumpspeed to something lower than their defaults, when it's false set them back to their default values. zheight in particular influences both the player's collision checking and where the 3D camera is located.
  • If you want the camera position to smoothly move up and down, you could use the lerp function rather than setting the zheight variable directly to the values for crouching/standing.
  • In order to avoid collision issues where the player crouches, gets under something low, and then un-crouches, you'll probably want to only allow switching from crouching to standing when there's enough free space over you that you can stand there with your original zheight. Depending on how you design your levels, though, this might not be a problem (e.g. if the player never crawls under anything and all ceilings are so high you can't bop your head into them, they can't get into a situation where this collision thing becomes an issue)

Let me know if something's unclear, and good luck :)