Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

Haha, I'm glad I'm not the only one.

I'm the most curious about the following:

  • UI Organization & Scalability
    • Process of creating UI that doesn't spaghettify itself as it scales
  • Animating UI Elements
    • How much time is spent, and how much is reused 
  • Managing Game Balance
    • Do you create spreadsheets or just wing it?

Any insights would be amazing! My submission was also UI-heavy, and it cost me a bunch of time to properly manage and connect it. I'm super curious about how you did so much in such little time.

Thanks again!! :)

(3 edits) (+1)

So I use gamemaker which makes things pretty simple and easy. Basically buttons are just a main class (object) that runs a state machine, and all buttons are just children of that class. Coupons are the same, just an object with a shared "Selectable" parent as the buttons. So I just basically create objects all over the place and use my Compass library for managing things like disabling hovering, or checking what current button is actually being hovered over. So from there its just a bunch of individual objects. The "coupon container" and "coupon book" manually handle their coupon positioning and depth handling. Basically buttons/coupons just exist as hoverable/clickable objects that other objects control position wise. The only exception is during repositioning wherein coupons check who they need to be handled by once released (e.g. book or container)

With this, the register, board, dollars, container, etc are all objects that themselves are also essentially "handled" by a global "SceneState" (statemachine) which controls *their* positions. And lastly 1 level above SceneStates are GameStates which handle the scene states. Hopefully that makes sense. Haha. 

As far as knowing positions I just most place things in the room and alter their positions/active status within compass or create them manually. 

Animation wise, I have a "component" system that is basically "fire and forget". So if I had a "wobble" component to a button or coupon, the wobble component updates the button/coupon until it is removed or replaced and resolves itself. Buttons and coupons all use the same "scales and "wobble" components in this way, and idle/hover states just add those components on "entering" the state. 

Of note coupons have like 3 different angle handlers too, 1 for animations/effects, 1 for actual collision/hover detection (real object angle), 1 for play angling (when they are "fanned"). Each button/coupon also has a "drawx/y" variable that just lerps to its actual x/y position. 

Game balancing, honestly its a crapshoot. Lol. I generally have a list of coupon ideas, implement them, play it, and change it as needed. Haha. Another reason I usually like to frontload art for gamejams is because if I play something for too long, I tend to make it too difficult of add too much since I get bored or familiar with it, whereas saving most actual gameplay implementation until the end gives me a more fresh view closer to what a new player would experience. Haha. Since I use that time to frontload art/ui design it also helps me think about the gameplay as im implementing what I need to explain to players.

Overall, I just know gamemaker EXTREMELY well as ive been using the engine for over almost 15 years now. Haha. That helps with speed on top of also utilizing pre-existing libraries like my own state machine lib, component lib, input & scribble by Juju adams, and of course my compass library as well. Ive made and worked on lots of games with these exact systems a number of times so ive just gotten really familiar with how to fit them all together. Haha. 

But yeah to recap for UI: ("->" means controls/handles)

Gamestate -> SceneState -> Game Objects -> Selectables -> Functionality

That's the basic chain of command. I hope this helps in any way! :)

(+1)

SO COOL!!!

I never really thought about UI as a state machine, but that makes complete sense! I like to use Godot, which handles scene states via signals. I totally see a way I could start managing signals like a state machine.

I really like composition, so hearing you use components made me very happy. I still have a long way to go to have 15 years' worth of components, haha. I made a few non-UI components for this project, but I might make some UI ones for future projects. Godot 4.7 is around the corner, which will add some cool offset UI features. Maybe I'll wait for that before I start a project like that.

The game balance struggle is real, haha. I like your advice, though, as I ran into the problems you mentioned. I think my game would've benefited greatly from saving the minigame implementation until the end. I was certainly getting tired of my game by the end of the game jam, haha.

I really appreciate you taking the time to answer my questions! It's not every day you can gain some insight from someone who's been doing this for 15 years!!

(+1)

Nice! Yeah Im not super well versed with UI in godot, but from what I understand it should be even easier with the tools they have available! Gamemaker is notorious for its bad handling of UI, but really no matter what engine you use or game you make, UI is almost *always* a pain to deal with. Haha. Even a lot of AAA games have to make/deal with convoluted systems to properly handle UI so it just is what it is. Haha. 

Best of luck! Looking forward to checking out your game as well! :D

Thank you again for your time!! Your game is amazing and a huge inspiration!! :)

(+1)

Aw thanks so much!! :) l