Author Topic: Oceanfarm  (Read 288 times)

0 Members and 1 Guest are viewing this topic.

Giik

  • Cutey
  • **
  • Posts: 22
  • Cutes: 14
    • View Profile
  • Pronouns: He/Him
Oceanfarm
« on: January 24, 2018, 05:10:55 AM »


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.

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 765
  • Cutes: 72
    • View Profile
  • Pronouns: she/her
Re: Oceanfarm
« Reply #1 on: January 24, 2018, 07:08:28 AM »
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

Giik

  • Cutey
  • **
  • Posts: 22
  • Cutes: 14
    • View Profile
  • Pronouns: He/Him
Re: Oceanfarm
« Reply #2 on: January 24, 2018, 09:18:22 PM »
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).

dcco

  • Cuter
  • ***
  • Posts: 165
  • Cutes: 23
    • View Profile
Re: Oceanfarm
« Reply #3 on: January 25, 2018, 04:21:07 PM »
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

hubol

  • Cutester
  • *****
  • Posts: 707
  • Cutes: 98
    • View Profile
    • hubolhubolhubol
  • Pronouns: he/him
Re: Oceanfarm
« Reply #4 on: January 25, 2018, 10:27:59 PM »
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)

dcco

  • Cuter
  • ***
  • Posts: 165
  • Cutes: 23
    • View Profile
Re: Oceanfarm
« Reply #5 on: January 26, 2018, 03:11:34 PM »
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.

Giik

  • Cutey
  • **
  • Posts: 22
  • Cutes: 14
    • View Profile
  • Pronouns: He/Him
Re: Oceanfarm
« Reply #6 on: February 03, 2018, 07:23:04 AM »


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

hubol

  • Cutester
  • *****
  • Posts: 707
  • Cutes: 98
    • View Profile
    • hubolhubolhubol
  • Pronouns: he/him
Re: Oceanfarm
« Reply #7 on: February 03, 2018, 12:43:17 PM »
i love grameplay. what kind of wack ass shit are you going to do to store this data in game maker

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 765
  • Cutes: 72
    • View Profile
  • Pronouns: she/her
Re: Oceanfarm
« Reply #8 on: February 03, 2018, 06:41:18 PM »
oh yeha did you have to use nested data structures or something for that inventory? those are always fun in game maker

Giik

  • Cutey
  • **
  • Posts: 22
  • Cutes: 14
    • View Profile
  • Pronouns: He/Him
Re: Oceanfarm
« Reply #9 on: February 03, 2018, 09:17:37 PM »
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

hubol

  • Cutester
  • *****
  • Posts: 707
  • Cutes: 98
    • View Profile
    • hubolhubolhubol
  • Pronouns: he/him
Re: Oceanfarm
« Reply #10 on: February 04, 2018, 12:47:15 AM »
in game maker it takes a lot more planning to build things intelligently given the language's limitations. good luck gamer

Quote
[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:
Code: [Select]
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

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 765
  • Cutes: 72
    • View Profile
  • Pronouns: she/her
Re: Oceanfarm
« Reply #11 on: February 04, 2018, 05:57:36 AM »
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

hubol

  • Cutester
  • *****
  • Posts: 707
  • Cutes: 98
    • View Profile
    • hubolhubolhubol
  • Pronouns: he/him
Re: Oceanfarm
« Reply #12 on: February 04, 2018, 06:54:31 AM »
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

Giik

  • Cutey
  • **
  • Posts: 22
  • Cutes: 14
    • View Profile
  • Pronouns: He/Him
Re: Oceanfarm
« Reply #13 on: February 04, 2018, 07:27:52 AM »
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.

aimaina

  • Administrator
  • Cutester
  • *****
  • Posts: 765
  • Cutes: 72
    • View Profile
  • Pronouns: she/her
Re: Oceanfarm
« Reply #14 on: February 04, 2018, 07:46:05 AM »
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