Cutey Zone
General Category => Cute Discussion => Topic started by: Giik on January 24, 2018, 05:10:55 AM
-
(https://i.imgur.com/duyaidx.png)
Devblog: https://the-giik-games.tumblr.com/
Oceanfarm is a game I'm workin' on. Yay.
It's a farming rpg crossed with a sort of relaxed puzzler/exploration thing. The world's flooded and there's all sorts of cool weird stuff out there. Discovery is a huge part of the game, meaning that I'm planning to add finicky, mysterious crops, crossbreeding and mutations, and some cool interactions.
Figured i'd start a dedicated thread for this.
-
this looks cute..... i like that you play as a kitty....
im curious how hard it was to program the movement..... i dont think ive ever made a game with nontrivial collisions on the z axis..... the slopes particularly seem like they would be weird to do
-
this looks cute..... i like that you play as a kitty....
im curious how hard it was to program the movement..... i dont think ive ever made a game with nontrivial collisions on the z axis..... the slopes particularly seem like they would be weird to do
the method i'm using is pretty inefficient really and it purely uses bounding boxes so i'd have to change it up if i want to use more complex masks.
at the moment it checks each block and seeing if the bounding boxes interesect; if it does, then it moves on to compare Z levels to see if it's a top, side or bottom collision. In the case of a side or bottom collision it just pushes the player out, but if it's a top collision then it sets a "zfloor" variable in the player to the block's z level, if it's higher than zfloor already.
In the case of slopes, then instead it compares a lerp of the block's base z-level and the top of where the slope should be instead of just straight z.
If I wanted more than a bounding box collision then I'd need to rewrite both checking the collision (which could just be a place_meeting function) and how it pushes the player out (nooo idea how i'd do that).
-
i watched pannenkoek's explanation of how super mario 64's collisions work. it was interesting but it made me realize that n64-era 3d platforming was actually just really jank
-
tbh i cant imagine it being that much more sophisticated nowadays. the takeaways i had from that video are:
-geometry (triangle in a model) is determined to be a floor or wall from its normal z-component. i imagine that games like zeddon do this sort of thing to determine what can be climbed on in real time
-walls push you along xy axes and floor/ceiling push along z axis. (this is probably something that has improved nowadays)
-mario's xy speed is unaffected by slopes. this is definitely jank lol
the great 3d platforming engine oddwarg helped me with basically uses these three principles (the jank mario versions ofc)
-
true, i think it's a good balance of being somewhat accurate over the majority of stage geometry, while also being simple. cuz when i wrote my first 2d game engine which only had rectangles, i was super anal about being extremely precise with collision (making sure nothing could phase through each other, etc). and i always wondered how anyone could work with 3d + slopes + rotation + all the crazy crap but between sm64 + also reading sonic retro's physics guide i realized that you can go pretty far if you just use sensors and "push" things out of walls.
-
(https://cdn.discordapp.com/attachments/121565307515961346/409209042544885766/1.gif)
Inventory works now sorta yay!
Right now you can just rearrange items and that's it. Items are also a single number with placeholder sprites, so I'll need to change how it works to allow for item stacking and metadata.
one step closer to closing that gameplay loop yo
-
i love grameplay. what kind of wack ass shit are you going to do to store this data in game maker
-
oh yeha did you have to use nested data structures or something for that inventory? those are always fun in game maker
-
The inventory is just a ds_list at the moment. The actual UI loops it according to a variable, so i can have the same inventory display with different widths.
I'm thinking of using arrays for an item's data, since those are copied and deleted easier than a data structure. As for the table of stats consistent across all instances of the same item (name, description, sell value, etc.) I'm not too sure yet. Maybe just have a ds_map with every stat for every item stored at the same time. I'll be able to change it if I find a more efficient solution to that. If any of you have advice for large data tables then lemme know. :P
-
in game maker it takes a lot more planning to build things intelligently given the language's limitations. good luck gamer
[6:26 PM] Oddwarg: last time I tried I wanted to translate good programming practices into game maker and it just made everything even worse than doing the horrible noob shit I used to do
[6:28 PM] Oddwarg: I think you just have to do the dumbest thing you can think of and prepare to maintain massive code duplication with no code navigation features
however, i can provide some advice for your "table of stats": text/ini files could be your friend. generate them for all known items and fill them out. read the text files in and build a mapping or array from that.
here's a file from sbw2, it describes a "Blue Fruit" for the virtual pet:
Cost of food
price = 150
How much to increase hunger stat when eaten
hungerIncrement = 1
How much to increase happiness stat when eaten
happinessIncrement = 0
Character palette index for washable color change when eaten, -1 for no change
primaryColorChange = null
Character palette index for washable color change when eaten, -1 for no change
secondaryColorChange = MeatFiend #2
outline color change when eaten, null for no change
Values: NORMAL, URA, WINE, HEMMA
outlineChange = null
the comments are automatically generated and stuff, but the fields work a lot like an INI file and it's easy to read and modify. (does game maker studio still have ini file stuff lol)
also this might be useful for defining behaviors for your items:
https://docs.yoyogames.com/source/dadiospice/002_reference/miscellaneous/script_execute.html
-
idk i usually dont have much code duplication in game maker unless i do it deliberately out of lazyness.... thats what parents & scripts are for.... maybe i just havent bulit anything complicated enough
one of the most useful features of gm studio that gm8 didnt have is an actual damn search feature that lets you search all the code in your project for a particular string.... but yeha its definitely way behind java ides in terms of code navigation..... i remember when i used intellij it had all this fancy automatic refactoring stuff
you could store item data in ini files like hub said and read it into a ds map of ds lists or something.... probably one of the more annoying things about gm is that you have to do stuff like "ds map of ds lists" instead of like defining a class with sensible field names
-
the ds_map of ds_list sounds hellish but yeah thats probably the gm way to do it.... shucks. also after further reading it seems that script_execute or whatever wont work for the purpose i had in mind (i was thinking you could define some fields in the ini file that would indicate behaviors for the items), but it seems like execute_script doesnt accept a string for the script and wants that sweet weird gm script pointer
-
yeah, doesn't seem like there'd be any sort of graceful solution to it. text files seem like a good way to store it off of runtime but my main concern is having all of those stats loaded at the same time. I'm probably really overestimating how much data that would actually take up but eh i'm paranoid.
my current planned solution is to have it loaded on a ds_map, where each item has an index separate from their object_index (so adding new ones doesn't fuck everything up). from there each stat's key would be like "<itemindex>_description". Unsorted, but I don't think that would matter too much, since if i want to have a sorted list i can go by the item index.
as for actually getting the stats onto the map, text files can work for that. Studio 1 has json and ini support. I'd probably use a json.
-
oh storing all the data in memory should not be a problem, computers have a lot of memory these days.... even if u have like a few hundred items and 20 stats for each of them thats going to be a miniscule fraction of memory.... i think game maker already has to store texture data for sprites and backgrounds in memory and thats probably way worse than a bunch of numbers and short strings
im talking out of my ass here but im also pretty sure im right? can any computer's scientists back me up on this
-
Storing as files is way cleaner anyway. Less error-prone, and gives you more system tools to work with (grep, search and replace, whatever else).
And yeah not a real CS guy but storing that in memory is completely insignificant compared to other assets.
-
i dont know how game maker stores its data since it seems to be a "dynamically typed" language. but lets assume the worse and say if for some horrible reason everything is stored as a string then it would take (assuming a character is 1 byte, counting only the key and value strings, and not worrying about null-terminating the strings):
[price] = 150 (8B)
[description] = a big nusty (22B)
[stat1] = 6999 (9B)
[stat2] = 7000 (9B)
theres 8 + 22 + 9 + 9 =48bytes. if you had 1000 of these item definitions you would have 48000bytes or 48KB, aka not shit nowadays. textures on the other hand use
(width * height * components[rgb=3 or rgba=4] * subimages) bytes
the main character sprite for cr*z'd is
32 * 32 * 4(idk if gm7 stored all textures in rgba, u could load files with nonbinary alpha transparency in with it so im going to say yes) * 64
= ~262KB. which is still not a huge deal (i think average ram is at least 4GB nowadays) but obviously more significant than a bunch of data.
in general, you neednt worry about storing data, you have plenty of room to play with that. make wise performance choices instead
-
i dont know how game maker stores its data since it seems to be a "dynamically typed" language. but lets assume the worse and say if for some horrible reason everything is stored as a string then it would take (assuming a character is 1 byte, counting only the key and value strings, and not worrying about null-terminating the strings):
[price] = 150 (8B)
[description] = a big nusty (22B)
[stat1] = 6999 (9B)
[stat2] = 7000 (9B)
theres 8 + 22 + 9 + 9 =48bytes. if you had 1000 of these item definitions you would have 48000bytes or 48KB, aka not shit nowadays. textures on the other hand use
(width * height * components[rgb=3 or rgba=4] * subimages) bytes
the main character sprite for cr*z'd is
32 * 32 * 4(idk if gm7 stored all textures in rgba, u could load files with nonbinary alpha transparency in with it so im going to say yes) * 64
= ~262KB. which is still not a huge deal (i think average ram is at least 4GB nowadays) but obviously more significant than a bunch of data.
in general, you neednt worry about storing data, you have plenty of room to play with that. make wise performance choices instead
the real numbers are actually stored as 32-bit floats, so it's a bit smaller than that.
still though, yeah, i'm overthinking it. ds_map it is, at least until i find something more efficient, if ever.
-
Premature optimization is the root of all evil and all that.
-
well yeah but i dont think that a map is really a premature optimization
-
I thought we were agreeing on that
-
well yeah but i dont think that a map is really a premature optimization
i think he's talking about me being all worried about if a solution is efficient enough
-
Yerp.
Better to keep a clean and maintainable system. Your future-self will thank you for it.
-
suddenly i see
-
p.s. in case youre interested, maps (if theyre implemented properly in game maker) run in O(1) (constant time [means good!!!!]) for lookup. this means getting information from the map using a key is really really cheap and could be as cheap as indexing into an array (depends on how hashing works in gm...)
-
(https://78.media.tumblr.com/ba8d111eeb91f4c8207ea0c2feb73cb5/tumblr_p3rduenrvK1wfwlewo1_500.gif)
Yaaaaay i did it
i also changed items to arrays so I can store more than just their ID
-
so i decided to move the project over to GMS2
it works for the most part but tilesets and backgrounds are pretty much completely changed so i gotta wrap my head around how the fuck THOSE work now
-
this part still works though
(https://78.media.tumblr.com/eba0d77ebbcb95ba363d74665f4c8d58/tumblr_p3ypvcTzvy1wfwlewo1_250.gif)
so that's cool
-
why did you move it to Game Making Skunk 2
-
why did you move it to Game Making Skunk 2
because gms 1 is falling out of support and has an absolutely shitty room editor
apparently there's like a GM/Computer crash with the latest windows update if you go fullscreen with gms 1 too so like fuck it
-
interesting. how are you enjoying all the amazing new features
-
they're..............eh
i understand the purpose of a lot of revisions; they're switching to a large reliance on "layers" instead of pure depth, which helps a lot with organization, and tilesets and backgrounds are both just sprites now, with tilesets just tacking on extra properties to an existing sprite, which is a really nice unification of assets
the new tileset format is really throwing me off. all i need to do is replace like, a couple tile_adds, a tile_exists and a tile_delete, 'cept i don't really know which functions are supposed to replace them yet. that and me worrying about code optimization makes me conflicted if i should just go with the standard -y thing as usual and just have a fuckton of tile layers.
also annoying is how i apparently need to make every tile a square, which i'm not actually doing; the vertical tiles are 16x8, since a z-level is 8 pixels instead of 16
there's a blog post on gm's website that has an alternative method of depth by having the tiles be all on the same layer, tilt every sprite, and use a custom shader and a z-buffer to cut off sprites behind terrain. it all seems really confusing and with a lot of caveats that don't really seem worth it
The UI is.........i don't like it. i liked being able to have separate windows for everything since you could like, have one code window be fullscreen, but now it's trapped in this tiny little workspace mini-window and like wtf
overall i think it's more a matter of getting aquainted with the new UI than outright bad decisions, but it's still frustrating to be set back so far
-
wow none of that sounds great to me..... good luck with that tiling nonsense
-
wow none of that sounds great to me..... good luck with that tiling nonsense
the thing with that is that you can have layers specifically for backgrounds and tiles, so they aren't just instances drawing sprites to replace it. the actual images are sprites, but the behavior is pretty much the same as before
-
I got it all working and even better now thanks to some fancy new shaders here https://www.yoyogames.com/blog/458/z-tilting-shader-based-2-5d-depth-sorting
took a while to actually get working cause gamemaker added a script that fucked with it when i imported it from 1.4 to 2 and i have no idea why
now that i'm getting more accustomed to gms 2 a lot of the changes are really handy; there's a huge reliance on "layers" now. everything is in layers. backgrounds, tilesets, instances, everything. one of the cool things is you can have "sprite" layers, which you can plonk down any sprite onto without having to make each one an instance
that, and HUD can just be its own layer that's kept on top of everything too. i don't have to use a surface for that, hooray!
(https://cdn.discordapp.com/attachments/167532865716879360/416750367053840385/1.gif)
here's a new vaulting animation that i've partially implemented. i'll have to experiment with the relationship between animation and code to make it all look right. at the moment it just instantly warps the player's coordinates to the ending point, and plays the animation of them climbing up. it's goooood but kinda clunky so i wanna figure out a cooler solution
but yeah, back on track now! <3
-
wow i dont really get that shader thing but its cool that you can use 3d stuff to handle depth in a purely 2d pixel art game. im surprised it actually seems to work well and isnt janky as hell
-
orthographic projection is the only reason this sort of thing can work nicely. ortho good
-
(https://78.media.tumblr.com/9f96011f4d410fd6ac76de9e1ed7441e/tumblr_p4shy8Ikaa1wfwlewo1_500.gif)
wanna go shopping
-
https://giik.itch.io/oceanfarm-demoday19 AGDG's doin' a demo day thing so i submitted a super early terrible build of OF
-
is agdg real or is that agdq typo
-
is agdg real or is that agdq typo
Amateur Game Development General
it's a 4chan thing apparently but i'm just on their discord
-
i LOVE 4chan
-
(https://78.media.tumblr.com/cef6b80c8af01acd1407b0fe3cf1e425/tumblr_p5uwa3pCsl1wfwlewo1_500.gif)
-
woha cute fx.......
-
(https://78.media.tumblr.com/2bcc9b562f6e2ef0d5a582366b49a5ce/tumblr_p5yzpj8E0w1wfwlewo1_500.gif)
i temporarily lost the art direction but i found it again
i'm gonna try taking a page from Knytt's book in terms of the terrain art; The tiling is easily recognizable, but still appealing to look at. So things like polkadots, chekerboards, stripes, stuff like that. I'm calling it "quilt-like".
-
cute stuff. the proteus-esque "pixelated graphics in a space that is clearly not pixelated" aesthetic is great.
-
(https://78.media.tumblr.com/3ab14e1829a1bd7327898504e44f0b46/tumblr_p8stv5D2ml1wfwlewo1_500.gif)
(https://78.media.tumblr.com/d887d1814a19986745002b6e6c16efc2/tumblr_p66kpxDt0c1wfwlewo1_400.gif)
i like this new style of hud
-
make an untitled story clone
-
just kidding this looks great
i was too lazy to use surfaces so i had to do some fucky things with draw_set_alpha and different parts of my hud are more transparent than others. i wish id done it the proper way
-
just kidding this looks great
i was too lazy to use surfaces so i had to do some fucky things with draw_set_alpha and different parts of my hud are more transparent than others. i wish id done it the proper way
i'm not actually using a surface here. studio 2's got layers instead of just depth now, so i have a dedicated HUD layer that i can force above everything else, and i just spawn all my HUD elements on that layer
-
oh i guess that makes things easier.
-
(https://78.media.tumblr.com/e979b4247e038e30580173b61af149f4/tumblr_paiaua2FhF1wfwlewo1_400.gif)
(https://cdn.discordapp.com/attachments/283045308059877378/456275534159282177/unknown.png)
NPC code is implemented in a very basic form. I still need to make them actually do things, but for now you can just talk to them
-
those are good portraits...... i have a lot of trouble drawing things that are larger than 16x16