GameMaker:Studio, and there's both a GMS1.x and a GMS2.x source file included :3
Recent community posts
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
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.
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).
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.
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 zheight, movespeedmax 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 :)
Scripts-->Initialization-->init_characters, it's a tabbed script with init_character_maria as the only alternate tab at the moment. At the bottom you'll see the lines of code that initializes sprites. To fully add a new character, I guess what you should do is...
- Make a new constant for the character's ID (must have a different value from char_MARIA)... you could use the existing constants char_LOUISE, char_PRINCE, char_FROG and char_SUNSHINE if you'd like to, of course.
- Make a copy of init_character_maria (create a new tab and copypaste init_character_maria's code text into it) and use the search-replace feature to replace "char_MARIA" with the new character constant
- Change the sprite assignments to the new character's sprites (they're at the bottom of the script).
- Don't forget to call the script from init_characters, just how it calls init_character_maria.
- To change the active character, just assign the character ID to the variable global.playerchar based on what the player selects - it's always assigned char_MARIA by default since the demo only has 1 character. You can make the menu any way you want~
I think that's all you need to do, hopefully I didn't forget anything :) Just hit me up with more comments if there's any problems~
Good catch, I can't believe I've let this slip through. Replace x and y with argument0 and argument1 respectively (in the script) and it should work as intended. I'll get an updated version with this fixed uploaded.
I'm pretty sure the only stuff available in the Water Tower after it's destroyed is the Lore that was inside it while it was whole, to make sure you can't permanently miss any. The fake floor you found probably lead to one of those spots.
And as for the key-gun-passable-blockade... derp. This is what happens when you keep adding new areas at random places in the old areas, I guess :P
Knowing me, the reason the blockade is Keygun-based is because the upgrade station in that dungeon is for the Keygun, to ensure you have it in order to enter. And if that's the case, it being unescapable is unintentional.
The missing 5% is a secret area, a secret final boss and an ending tied to that, btw.
As for the stuff that actually is finished: every gun has a secret upgrade, some has two (one gun has two tiers of upgrades, another has two alternate upgrade paths, and another has two complimentary upgrades that can be obtained in any order). There used to be a secret developers' level hidden at one place, I'm not sure it's still accessible and it had some of the most frustrating level design I've ever made so it's probably for the better if it isn't :P And to make things even more confusing, there's a bunch of "fake" areas you can see but aren't meant to access, just to explain how everyone else gets around. (I had plans to let you play as other characters later to let you see the story unfold from a different perspective, but ended up scrapping the idea because it was too much work. The sequence where you play as Emily and all cutscenes you see from someone else's perspective than Mario's are remnants from this)
Hmm... I was pretty sure there's a blockade early on in the desert that you can't pass without being able to do the wing flaps. Maybe I've messed it up... you're referring to the desert west of the truck, right?
It's pretty unlikely I'll ever fix things like this since Game Maker 8 is discontinued and doesn't run properly in Windows 10, and the engine uses functionality deprecated in Game Maker Studio, but thanks for pointing them out anyway! I'll make sure to have a look on them if I ever get around to making a 'finished' version.
The fake walls and stuff are in other places as well, anyway. I don't remember everything by heart anymore since I haven't touched the game actively in like 2 years, but from the top of my head, written in riddle form to reduce spoilers:
- The grass is green, but not all green is grass, might be something new where you've already been.
- The longest road is mostly flat, but there's something above your hat.
- An arrow of barrels, hard to see, still guides you to a mystery.
- Near the canal, your feet may burn; still there's a reason to not instantly return.
- In the sky, all's not what it looks; moreso than usual, think outside the box.
There's some other places I can remember, but I don't remember WHERE they are, so I can't really offer hints for those yet :P
Nope, the wallrun is just mentioned to explain how Cain can reach certain places without being able to fly.
There's a bunch of tricks, though:
- Flapping rapidly makes the vertical distance you can cover greater.
- One area has invisible blocks you can trigger by jumping into them from above (it's an outdoors area so it might not be the place you're in).
- Some areas has fake walls, so there might be an alternate path. All of these are indicated in some way if you're on a lookout for details in the environment.
- There should be an easter egg that gives you infinite wing flaps, but it was added pretty late in development, is very obscure to find, and isn't required for anything.
There also used to be a bug where if you get hit by an enemy instantly after jumping, the momentum of the knockback and the momentum of the jump would stack together and you'd be sent flying very far.
I thought my e-mail address was visible on my profile, but it appears I was wrong. Thanks for alerting me to this, I will look into it. But I like general questions being asked at the corresponding itchio communities like this, though... easier to find if someone else has the same questions and stuff, and less risk that it gets lost in all my other mail.
If I remember correctly, the only thing that affects the game ending is your Lore completion percentage - if you get all 50, you get the good ending, and there should be one bad and one neutral ending. (Note that the final lore is on the table during the fight with Smith after Heart of The City and that you have a limited time to scan it). All other optional stuff should be more or less self-contained.
At least it shouldn't be too hard to relearn Studio, it's basically GM8 with some stuff removed (execute_string() being the most important loss, a lot of people used that, and also sleep() and screen_redraw())... and some stuff added, like room/image editors where you can scroll and pan with the mouse wheel. Also, you can resize instances in the room editor now, which is wonderful for a lot of cases.
...oh, wait, you were talking about Studio 2. Derp. How do I forget things like this so easily x3
Studio 2 definitely is a bigger step up since it's based on the new stuff in Studio 1 more than it's based on its GM8 roots, but it's still mostly the same core loop. All the changes done from GM8--->GMS1 still apply, but on top of that:
- Layers is a pretty major feature, and can be used in various ways... there's functions to only check a particular layer for instances/tiles, so you can have layers for each floor of a building etc.
- Views has been generalized to cameras, which basically is the d3d_set_perspective() function except it now can view 2D planes as well. You can have more cameras than you have views and switch what cameras are displayed in which view on the fly, letting you make dramatic camera movements and stuff more easily.
- Tiles has been revamped to allow autotiles and animated tiles, but this is mostly an editor thing.
- Backgrounds and sprites have been merged into one resource.
- Sprite editor supports layers for each subimage and you can draw while a sprite is animated, which lets you do some animations much easier.
I'm pretty new to GMS2 myself, but hopefully this helped you in some way :P
It should work in theory (since there's compatibility scripts converting the old 3D functionality into new), but I've had some issues converting other 3D engines to GMS2 so I can't say with certainty it will. (For instance, there's a bug with drawing transformed models with <1 scaling factors that causes massive slowdowns). Still a bit torn whether it'd be better to make a GMS2 version from scratch of all my engines or convert them and try to deal with version differences.
Deleting the shader itself should be enough (the help scripts won't do anything as long as you don't call them), and then just make sure you remove/comment-out any script calls that would use the system (e.g. shader_set()/shader_reset() pairs in the draw event of map & battle units)... it's never a good idea to leave in references to a resource that doesn't exist anymore.