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.
Recent community posts
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 startingWouldn'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.
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.
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...
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.
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.
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)
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?
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.
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
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 randomize()
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
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.
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.