Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles

Yal

114
Posts
3
Topics
428
Followers
20
Following
A member registered Aug 12, 2015 · View creator page →

Creator of

Recent community posts

No, it relies too much on GM8-isms. Tried messing around a bit in it and it has issues importing the file because of illegal names, and weird "undefined value" crashes when run because globalvar variables don't default to 0 when declared anymore (?)

I don't remember anymore, but it's a pretty basic engine made for a game jam, so probably less than 7 days. (Depends a bit on how much I cheated by reusing code from my old projects... which I wouldn't disclose even if I remembered :P) I tried importing it into GMS2 right now, it works just fine for me (I'm on IDE v.2.2.0.343, runtime v.2.2.0.258).

Pretty great stuff, made me laugh a few times (especially at "this time it's a guy that's a furry!"). Also got a bunch of feedback on stuff that could be better telegraphed, I guess my playtesters are too good to find some of the confusing/hard bits... x3

Some hints that could be useful if you're gonna keep working on the series and didn't already record all the footage you're gonna use:

  • Enemies stop moving right before they shoot, that's your cue to get out of the way.
  • There's an easier area if you head left  from the entrance of the cave (aka above the first shop, go to the left instead of to the right), there's an easier boss and a bunch of upgrades there.
  • The ammo of the guns with limited ammo is refilled each time you save, but it won't refill automatically over time.
  • You do get to use the motorcycle later.

Not really, I'm kinda busy and my schedule for doing indie programming stuff is very erratic. And I'm not a particularly good teacher either, for that matter :P I'd recommend just going to the GameMaker Community forum, there's plenty of tutorials and the programming questions board is still very active. (You can find me there as well, even if I'm not exactly active every day)

Not really. I'm not using GMS2 a lot and I don't really see the point in having two separate codebases to support and doing all development/bugfixing twice.

Awesome, glad to hear that! I suppose I'll go hide the outdated versions now so they don't trip any more people up...

Uploaded a new "Source Code (GMS2) (v1.2)" file which is freshly imported from the GMS1 source in the latest GMS2 runtime, please try that out and see if it solves the problem (it compiles and runs just fine for me, but then again so did all of the other versions...).

Yeah, that's an actual syntax error... the correct version would be this:

var i;
for( i=0; i<len; ++i ) {

But yeah, this is weird... if we're using the exact same runtime to load the exact same file, we should get the same results. (You're using the v1.1 version of the GMS2 source, right?). Maybe it's time to contact Yoyo support about it...

There's one more thing we could try first, though... I'll try importing the GMS1 1.1 source file in the latest version of GMS2 and upload that as a GMS2 1.2 source file, and if there's any issues with the compatibility scripts that should hopefully be resolved by that.

The issue mentioned in the GMC topic refers to an issue with for loops whose first statement isn't a variable assignment causing this error, I went through all for loops in the engine and none of them has it... only suspect thing is compatibility script __global_object_depths() having a "var i = 0" assignment, not sure if that would be a candidate with vars behaving different from ordinary variables? (The solution if this is the case would be moving the "var i" part outside the loop and then do a normal "i = 0" inside the for loop).

Geez, GMS2 still kinda feels like it's in beta sometimes :/

I did some more investigations and found a thing in the GMS2 release notes: (this post). Seems to be broken in runtime 2.1.4.218, worked in runtime 2.1.5.246, and it works for me in runtime 2.2.0.258... what's your GMS2 runtime version?

From what I gather there's an issue where valid GML becomes invalid C++/JavaScript code sometimes when a single GML statement becomes multiple instructions when parsed, which sounds like a nightmare to track down :/

(Since 2.0.3.56 there's also an option to carry on and collect all errors that's possible before ending a compilation, it might be helpful in finding the resource that causes this to happen... perhaps?)

Aw :/

Could you post the entire error message? Maybe there's some other clues in it (like WHICH array is out of bounds)

Also, did you try updating the player_score script? When investigating I found an error where it uses the wrong variables in two places, it worked in previous versions. You could try updating that and see if it solves the problem (it's a really small change)

Instead of this:

effect_spawn_textpopup(x,y,        ....

It should be this:

effect_spawn_textpopup(argument0,argument1,   ...

Tried importing the GMS2 version in GMS2.2.0.343 and it had one error, there's a mistake in player_score (Scripts-->Gameplay-->Player-->Score Lives Etc) where it uses the calling instance's x/y instead of argument0/argument1. The body of the script should look like this, then it compiled fine for me:

if(argument3 && argument2 > 8000){
    global.playerlives++
    effect_spawn_textpopup(argument0,argument1,"1UP",c_lime,c_teal,font_retro)
}
else{
    global.playerscore += argument2
    effect_spawn_textpopup(argument0,argument1,string(argument2),c_white,c_black,font_narrow)
}
(Alternatively you could use argument[2] instead of argument2 and so on for the other arguments, this might be why you get an array index error)


If this doesn't solve the problem for you, could you please copypaste the entire error message? Usually it hints at where the error occurs.

I'll check it out and see if I can narrow it down. Did you use the GMS2 source file or import the GMS1 source? I've seen a similar case for another project where import changes made the GMS2 source break but importing the GMS1 source solved the problem.

Fair enough, an engine that's 100% made for what you're trying to do is always gonna give better results.

I don't really like the idea of any of my assets being resold as assets somewhere else, because it's using my own stuff to directly compete with me (and potentially without putting in as much effort into creating them as I did - not gonna say you wouldn't), makes the copyright situation messy since the asset technically was created by multiple independent people, and a bunch of other reasons.... so I'd have to say no to this. (Having a derivative version of the engine available for free and as a fan project that could get into some IP law issues doesn't sound like a super tempting prospect either.)

Also, if you're planning to rework everything from scratch anyway, it might be less effort to try to make what you want from the start instead of retrofitting it into an engine that might not support it very well. I found a whole bunch of other tactics RPG stuff by just doing a Youtube search, so there's a bunch of it out there:


Technically Itchio's creators are customers, too... itchio is a service that lets people buy and sell stuff, it's not a company that hires developers to make stuff. Only people that are on Itch's payroll directly counts towards its size.

These laws do set a dangerous precedent though, since if they were expanded then it could only enable the larger platforms to continue operating with their capital and block out smaller platforms from ever starting
Wouldn't an expansion like that conflict with laws to prevent monopolies / unfair competition / cartels, though, just because it would make it unfeasible for small companies to keep up? Wouldn't be surprised if the regulations only applying for big companies is exactly for that reason, and I wouldn't be surprised to see a class-action lawsuit coming up if they tried pushing the regulations in a direction that would make it unfeasible to run small enterprises period... several countries have umbrella organizations that keep an eye on things like this on behalf of small enterprises.

It's still a worrying development, though... GDPR was kinda grounded in reality and was addressing a real problem that people were having, and then the EU drops something like this less than a year later.

(1 edit)

I just set up a Halloween sale after getting the reminder mail, and noticed it doesn't appear to be possible to reorder the items on the sale page (they're sorted by creation date, ascending). Would it be possible to add a feature to allow the creator to reorder the listing on sale pages (or at least add an option to list them in ascending or descending order)? I feel like some of my more recent stuff is more relevant to customers than things I created years ago, and having it at the bottom of the page is both doing them and me a disservice.

How about this workaround? From the site, go to Dashboard --> the game's little box --> More --> Distribute --> Download Keys, generate a download key, and use it.

I kinda had the impression that it's been an intentional decision not to add this, because very few developers use microtransactions/lootboxes properly, and even standard DLCs can be really cash-grabby, not-adding-a-lot-of-value-y, so the overall quality of games posted to Itchio will be higher if people can't monetize their games using them... usually the logic between using micro-monetization models is to have a ton of really small trickles of income, and it pairs really well with a "upload tons of similar, small games using the same system" model.

Also, apart from making DLCs as separate games, there's already a system where you can have files that are only available if the customer pays more than the minimum required price for your game. This would let you have a "complete edition" with added DLCs as a separate download. Won't really work if you want to have multiple separate DLCs (e.g. "buy every character separately") but it could work if you plan to make an "expansion pack" later that contains a bunch of random extra content.

Glad you like it, I hope you find it useful down the line! :3

All of us good coders learned coding by copying existing stuff at first before we realized what it did, so don't fret too much about not doing everything yourself. Do it when you're ready for it, when you feel like you NEED to make everything from scratch to get it exactly the way you want it. Code doesn't rust or rot, you can reuse it as long as you feel it does what you need it to do.

Thanks, I'll look into it... arguments checking is a relatively new thing compared to how long the YaruFPS code base has been around. I don't remember exactly how the script works, it might be that it uses the same argument signature as the other collide scripts but doesn't actually USE all the arguments.

Then it's one of the most un-informative error messages so far... Yoyo pls <__<
And yeah, from my experiences GMS2 is so buggy it should still be in beta... glad you could still import some of the code, at least!

You could try using the "add existing <resource type>" right-click option (or dragging scripts/sprites into the GM window) to speed up the process, or try re-importing the project files to an empty project, in case there's some version compatibility issue (it might even help importing the GMS1 project instead of the GMS2 project)... but if you've already set it up to work the way you want I guess there's no point in trying to figure out what the problem is. The fact that the error claims the asset compiler is failing makes this seem very weird...

(1 edit)

Sounds like a problem with GM, but I could be wrong. What version are you using, GMS1 or GMS2? Does it tell you WHAT index is out of range? The free version (of both GMS1 and GMS2) also has a limitation on the number of assets you can use (something like 25 of each type), so if you use that it might not be able to compile the game.

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

Oooh~

*watches*

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.

(2 edits)

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)
(1 edit)

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~