In betweens?

[Amon]

I never realised how intimidating game development can be untill I needed to code the inbetweens. For example, scene switching, UI, menus, highscores, saving, loading from saved file,and all the general aesthetics needed to call a game complete and finished.

The fun part is getting the main game mechanics done and my mistake was to think that getting the rest of what is needed to complete a game would be just as fun but no, it's tedious, boring, and requires a huge amount of testicular fortitude to get done.

So, never underestimate those last few steps of completing a game. They determine whether you are a games developer with a release history or just an imagineer.

That's all.

 

[rIKmAN]

I never realised how intimidating game development can be untill I needed to code the inbetweens. For example, scene switching, UI, menus, highscores, saving, loading from saved file,and all the general aesthetics needed to call a game complete and finished.

The fun part is getting the main game mechanics done and my mistake was to think that getting the rest of what is needed to complete a game would be just as fun but no, it's tedious, boring, and requires a huge amount of testicular fortitude to get done.

So, never underestimate those last few steps of completing a game. They determine whether you are a games developer with a release history or just an imagineer.

That's all.

Welcomer to the ninety-ninety rule!

The first 90 percent of the code accounts for the first 90 percent of the development time.
The remaining 10 percent of the code accounts for the other 90 percent of the development time.

 

[Nocturne]

I never realised how intimidating game development can be untill I needed to code the inbetweens. For example, scene switching, UI, menus, highscores, saving, loading from saved file,and all the general aesthetics needed to call a game complete and finished.

Welcome to the life of a game developer!

I generally spend MOST time on these parts of the game, tbh... The main gameplay and mechanics are the first thing I do, then I spend a massive amount of time on the UI, menus, achievements, stats, and general front-facing interface details, and then go back and flesh out the content and do the balancing... so it's like first 20% game design and mechanics, next 70% is all the bits and bobs related with making the game presentable and making it nice to use, and then the last 10% is polish and balancing. Thankfully I actually love doing UI and menus and stuff, so that's okay!

 

[Geoff Jones]

Give a man a game, he'll have fun for a day. Teach a man to make games and he'll never have fun again...

 

[The-any-Key]

It takes 20% work to make 80% of the game to work. Then it will take 80% work to get those 20% left on the game to work.

 

[Siolfor the Jackal]

Maaaan. Menus can be great. I feel like there is a lot less pressure when trying to make good ones. Like, I don't have to worry too much about optimising a menu or that it will run poorly because it's a menu, it will be fine(unless I somehow do something completely stupid).
I always get stuck in the trap of making barebones gameplay then spending 10x more time playing around with how my menus look and work.

 

[Nocturne]

Maaaan. Menus can be great. I feel like there is a lot less pressure when trying to make good ones. Like, I don't have to worry too much about optimising a menu or that it will run poorly because it's a menu, it will be fine(unless I somehow do something completely stupid).

Loooool! This is SO true... Most of my menus in my projects are monolithic single objects that do everything... I mean, I have a main controller object with about 3000 lines of code in the step event to control 20 different sub-menus, and the draw event is a massive tangle of switches and ifs and if it was actually running with gameplay then I'm sure I'd be lucky to get 4FPS. But, it's a menu... and it works... so to hell with it.

 

[rIKmAN]

is a massive tangle of switches and ifs

Toby Fox, is that you!?

 

[Siolfor the Jackal]

@Nocturne Haha exactly the same. My step and draw events are often massive.

 

[GMWolf]

Wow I'm the opposite. When I do menus and think "yay, I don't need to be efficient" I start splitting it up in lots of objects, lots of runtime type checking etc.
That's the really slow stuff...

 

[zendraw]

I never realised how intimidating game development can be untill I needed to code the inbetweens. For example, scene switching, UI, menus, highscores, saving, loading from saved file,and all the general aesthetics needed to call a game complete and finished.

The fun part is getting the main game mechanics done and my mistake was to think that getting the rest of what is needed to complete a game would be just as fun but no, it's tedious, boring, and requires a huge amount of testicular fortitude to get done.

So, never underestimate those last few steps of completing a game. They determine whether you are a games developer with a release history or just an imagineer.

That's all.

its just a new concept to you, it is as fun, becouse it is a part of the game. the GUI for instance, its function is to keep the player up to date of faktors that arent otherwise visible to him so he can decide in real time what direction to take during gameplay, etc. its fun, it just have to be a part of your workflow.

 

[Alice]

Depending on how much leeway I have, I might end up making a pretty elaborate menu and layouting system with a bunch of container and controller objects hierarchy. I've at least once implemented something like WPF/CSS grid at least once, too (with all its pixel and star dimensions goodness).

I suppose it might work even better for the planned GML with the inline functions and stuff, but alas, right now my generic buttons need to accept script asset references instead (possibly with some callbacks). Another tendency I've found is that I tend to make a bunch of specific instances for mouse-controlled menus, and a single options-listing instance for a keyboard controlled menus.

As for the tweens themselves, when in rush, I usually just slap some variable onto an existing object. When I'm not in such a rush, I might make a dedicated tween object which is attached to a specific object, and then the tween makes sure to change a specific variable of the object (be it alpha, position or something else). This system probably works best for the values that the object doesn't update on its own; it might get pretty messy otherwise.

 

[pixeltroid]

I never realised how intimidating game development can be untill I needed to code the inbetweens. For example, scene switching, UI, menus, highscores, saving, loading from saved file,and all the general aesthetics needed to call a game complete and finished.

The fun part is getting the main game mechanics done and my mistake was to think that getting the rest of what is needed to complete a game would be just as fun but no, it's tedious, boring, and requires a huge amount of testicular fortitude to get done.

So, never underestimate those last few steps of completing a game. They determine whether you are a games developer with a release history or just an imagineer.

That's all.

good post. I'm currently making those little screens in between stages that say "level 1 -- Jungle" etc. and I'm having a bit of a hard time trying to get it to work consistently.

and yes, I've struggled with menus, save & load and all the other boring tasks! Once I got them to work, I just said "phew" and stopped messing with them!

 

[Amon]

Since starting this thread I've thought about putting everything on hold in order to develop and solution for myself that I can use for each and every type of game that I make. A kind of framework that takes care of and obliterates the 90 90 rule.

It's easier said than done. A one solution for all is not going to happen as mobile, desktop and html5 all have different requirements. So, a core code is needed that will suit them all but then I am going to branch out and develope the three different flavours. Fingers crossed I can sort this.

 

[Nocturne]

Another issue with "one size fits all" solutions is that they tend to be bland and anodyne... Good UI and Menus are unique to the game they are included in, and by creating frameworks to use in all your games, you run the risk of losing the unique personality of the game. Keep in mind that the UI and Menu system is the first point of contact that a user has with your games, and if it's boring, then your game may be perceived as boring too. I mention this as I've often thought about doing the exact same thing, but have never done it for this exact reason. Instead I created a set of handy scripts that can be used to HELP create good UI... things like a "gamepad_any" script to detect any button press on a gamepad, for example. This gives me a faster start creating menus, but allows me the flexibility to make each one unique to the game.

 

[Gamebot]

I'd rather make the menus then the game. Especially since I've been doing most of my menus using ds_maps.

 

[RefresherTowel]

I think a good idea for the "one size fits all" faction is to only genericise the arithmetic. An example for a menu selection system: A common scenario is for a menu to have a max and a min value. Are you at position 0 or position MAX? That's perfect for a little script to be written that determines whether a value is over or under a max/min system. Externalising a script that alters a value based on it's position between a min and max scenario is perfect for this.

my_value = menu_bound_check(my_value,min_value,max_value); // Basically a clamp that would take into account value wrapping from the max to min or vice versa

Basically stops you typing a bunch of checks each time. Of course, this is super basic scripting, but having a library of things that you can import from game to game helps menu creation speed, while allowing for the flexibility of menu appearance/interaction that nocturne is talking about (just pointing this out for newbies, I know that nocturne and others of the same ilk would already know this type of thing).

 

[sitebender]

Well I just spent 10+ hours yesterday programming "the feel" of a single enemy with someone's notes. Know what else I could have done in those 10 hours of programming? Made an entire game. Turned out well, but at the time I feel like wow this is quite the waste of time. Even in that time, I'd say 4+ hours was good for the feel and other 6 hours was stuff that no one will ever notice.

 

[Siolfor the Jackal]

I often feel like I am wasting my time with a lot of that little stuff no one will notice, but at the same time I think that that stuff adds up and whilst regular people may not notice individual things, I feel like they may sort of notice it overall on some level. So they may not notice X or Y specifically but it adds to the experience.

 

[RefresherTowel]

"10 hours"..."make an entire game" keep dreaming buddy =P But on a more serious note, the amount of time Miyamoto spent perfecting literally just the movement in Mario 64 is ridiculous...But look at how many people absolutely love the movement of that game. Sometimes it simply takes many many hours of tedious back and forth to really get to the heart of something and make it shine. You can't learn to run a marathon in an afternoon, but you can use many afternoons to learn how to run a marathon.

 

[sitebender]

"10 hours"..."make an entire game" keep dreaming buddy =P But on a more serious note, the amount of time Miyamoto spent perfecting literally just the movement in Mario 64 is ridiculous...But look at how many people absolutely love the movement of that game. Sometimes it simply takes many many hours of tedious back and forth to really get to the heart of something and make it shine. You can't learn to run a marathon in an afternoon, but you can use many afternoons to learn how to run a marathon.

True 10 hours isn't quite enough to do an entire game that people would go out of their way to play, but I've done 24 hour game jams and put in 10 hours of work:

Spoiler: They are hardly gems

There are enemies and an exit to go to the next level, but I'm struggling to find the project now and I only have a few production photos.

There was a game called Piximelism on Steam. It was taken down. I decided to remake it. The entire game remade took 5.5 hours. I copy / pasted the menu from a different project along with a few of the effects like the landing puff and the blood, otherwise that would have been a few hours more:

Here's the real game:

You get the picture.

It's all stuff I've done before, over and over and over again, so I can do it faster and faster each time, even if it does look a bit ghetto without that polish.

As for Mario 64 being Mario jumping in a room for the first year, that was at a time that 3D platformers didn't really exist on consoles.