Pause screen

[mspraggs]

Just because it might be useful at some point.

[Fyll]

Do we want a pause screen that just greys out the screen, or do we want an actual screen (as in, with an image)? If the latter, do we want it to move/animate? Also, if the game is still visible through or around it (or whatever), do we want things in the game to still be animated (I'd strongly recommend against this)?

As to what's on the pause screen, I'm just picturing it with 3 buttons: Continue, Options, and Suspend. There would then have to be an options menu too, with the fiddleable options on it.

[DivFord]

My personal preferences would be as follows:

• Just grey out the screen. If we go for an actual screen, I have to draw the image, and beyond just laziness, I can't think of anything I could do that would be better than leaving the level visible. Of course, I'm assuming you mean a transparent grey overlay, rather than just a flat grey square…
• No motion/animation. Everything freezing in place is a good way to indicate that the game is paused, so why go out of our way to undo that? That said, it might be nice to highlight the button the player is hovering over (i.e. swap the texture).
• Agreed on the buttons you propose, though "Save & Quit" might be easier to understand than "Suspend".

[Fyll]

Yeah. A big grey square would look silly.

Okay (assuming Matt has no objections). My next question would be: What options do we want? The only in-game-toggleable options I can think of are volume and a fullscreen switch (and a window size option I suppose).

[DivFord]

Maybe just leave the options menu out for now? Put in the "Options" button, but don't make it do anything. It's not like we don't have other stuff to be getting on with :P

I'm led to understand that switching to fullscreen after launching a game is quite tricky. Are we going to have to do the "the game will fullscreen after restarting" thing?

[Fyll]

I'm not concerned about it out of a want to have it all implemented and ready to go now, more just concerned about if I'll need sliders, toggle buttons, text input etc. to be programmed in. At the moment, the menus are just a collection of buttons on a partially greyed out screen.

Also, I forgot to mention this, but I felt it was right to "pause" the game when you pick up a gun (that's how I got onto trying to right the menus), and maybe have some pictures/text on there explaining what it is. Is this maybe a bit against the experiment-y tone that I think we were going for at some point?

Fullscreening after restart would be an easy way out, and as someone who generally avoids fullscreen (I like having the buttons at the top), I'm fine with it being like that. I'm having a bit of a look into fullscreening an open window, and will see how it looks. EDIT: It looks like you can only fullscreen (without a lot of hassle) a resizeable window, and I don't think we want the window to be completely adjustable by the player. Nevermind then.

[DivFord]

Depends what you explain about the gun really… If we say that the magnet gun "attracts metal", people still have to work out that the metal crate is metal and therefore they can pull on it. So long as we don't list all the game mechanics, I think we preserve the tone. In other words, I'm all for a "gun info" screen, so long as it's used for fluff.

[Fyll]

Okay. I've pushed my menu'd version.

Press enter to pause, and there should be three buttons: Cannon, Freeze Wand, Drain Beam. Cannon continues with the game, Drain Beam saves (not yet implemented) and quits (implemented), and Freeze Wand goes to the "menu" you'd get if you just picked up the Freeze Wand (click anywhere to exit).

The buttons are all fully animated with hovering and clicking animations, but there're no sprites (no pressure :P), so they only look like they're not doing anything.

[DivFord]

Yay! It works!

I will start working on some buttons for it. That reminds me though, I've been worrying about localisation (surprising, I know). With the current system of drawing the text into the sprites, we'll need new art for every language. I may be getting ahead of myself, but I wonder if there's a better approach. Create a font, perhaps?

Quitting is fairly abrupt. Is it worth quitting to the menu rather than quitting the whole game?

[Fyll]

Hmm. Well, how much text is there in the sprites? The start and quit tiles and the gun icons are all I can think of. I've never tried creating a font before.... I'll see how it looks.

As for quitting, I suppose I could give it a go.

[DivFord]

I have, but the program I used probably isn't freeware anymore. I'd forgotten the start and quit tiles. There's no way we can replace those with a font…

[Fyll]

Seeing as there isn't all that much text in the game, surely portability isn't too big a problem. If the gun icons change over to using the corner-scrolling thing, they would/may be textless. Then it's only the menu, for which a font would work quite nicely.

A quick look offers https://birdfont.org for free .

[mspraggs]

I'm happy with a grey/transparent screen. There are plenty of fonts with licenses that allow use in other projects for free, provided you credit the authors or whatever other caveats. See for example Google fonts, though I think most of those look best in webpages, not games. There might be a couple that look good.

As for portability, there should be a way to download the font and include it among the assets in the game repo.

Ultimately, when it comes to portability, I think we're going to have to figure out a way to package the game, with assets, so that it can be installed so that everything works. That's a topic for another thread though.

[DivFord]

We actually already have a font in the game (FreeMono.ttf in the gfx folder), so we know we can do it. It's more a question of finding one that fits in with the rest of the art. As you say, most fonts out there are better suited to webpages. When I suggested making a font, I was essentially thinking that I could take the letters drawn into the art and build a font around those.

[Fyll]

For the quit/start signs, we could use symbols. Or just do something visual to show what the different sides are.

Also, do we want the score and lives (and framerate) to be only on the pause menu? They're a bit tricky to read when there is a pale background, and that seems somewhat like a bit of a problem.

[mspraggs]

Not trying to create more work for David, but could we perhaps have an area that appears when the lives and score change, then fade out after a few seconds? I'm casting my mind back to old N64 games like Mario 64 and Banjo Kazooie, where if your health was low the indicator would remain, otherwise it would disappear and not clutter the screen. Thoughts?

[DivFord]

I assumed we were going to put in actual HUD elements for score and lives eventually, so probably not worth sticking it on the pause menu. At least not until we make up our minds.

I like that idea Matt. I expect to make graphics anyway, so it's not more work for me if we have them appear only on your last life (it is more work for a programmer though). It adds a sense of tension as well.

[mspraggs]

Sorry I'm not sure I explained that clearly: they would still appear temporarily when you health changed, but they wouldn't persist. I am okay with not showing health in these instances, but it'd just make it harder for the player :-P

[DivFord]

Ah. The thing is, "life lost screen" is on my to-do list, so I assumed we would just use that instead of flashing something while in the level. Of course, you can't see my to-do list, so we were bound to get confused...

[Fyll]

I think having it pop up when it changes would be good (like the gun icons do at the moment), and agree that keeping it hidden would also be good. I would say that it should be visible on the pause menu though.

I'm not sure that a life-lost screen is such a good idea. It flows quite smoothly (ish) at the moment, and I feel a screen into the process would break what flow there was.

[DivFord]

Fair enough. Smaller bits of GUI are easier to do, so no objections here.

[Fyll]

I've added some (very basically) animated buttons, and allowed text to be printed on menus. In case you haven't figured it out by this point, my coding productivity is directly proportional to real life deadline proximity, and I do have a lot of deadlines to be worrying about at the moment. :P

Anyway, this seems to show me that the font we have looks a bit blocky, so that's another good point for making our own (although it's almost certainly just scaling issues).

[Fyll]

I've added some tucked GUI elements in, namely for the Player's score and lives. For now, they use the Ice beam's sprite (hence the blue speckly-ness), and tuck in/out as you hover over them. You can click on them (when they're open) to lock them open, and they pop up themselves when the related stat changes.

Should we hold them open when the game is paused? At the moment, they just act as normal.

They've actually worked out surprisingly well, I think. :D

[DivFord]

I like them. The highlighting on the menu works well too. I'll see about getting some art done. Maybe even today. Are the tucked bits sliding or stretching the sprite? That would affect how I do the art for them.

I think we should hold them open while the game is paused. It gives players another way to access them in case they don't work out about mousing over them.

Is it possible to disable the tucked GUI on the menu level? It's a bit odd for the menu to tell you score and lives. Plus, it's confusing for a new player to launch the game and immediately have GUI popping up.

I'm getting a weird bug where the menu freezes. As far as I can tell, it's triggered by opening the menu after killing the lizard, but that seems like it can't really be what's causing it.

[DivFord]

I worked out what the bug is. The mouse-over coordinates are relative to the level, not the screen. So if you move the camera across the level, you can't select stuff on the menu. Applies to the tucked GUI as well.

[Fyll]

Yeah, I just fixed that. Pushed now.

As in, have the tucks not there at all, or just not pop up right at the start?

EDIT: Oh, and the sprites are off-screen, not stretched.

[DivFord]

Quick work. Possibly too quick: the characters don't turn round anymore…

Not there at all, I reckon. It's surely better for the player to not even realise they have lives on the menu. It's a bit odd, after all. On a related note, should they be allowed to kill themselves on the menu?

[Fyll]

.< That's what happens when you change variables names from noShift to shift: You forget to swap the default value. It's all (hopefully) good now.

It'd be pretty fiddly to make the menu act so strangely. We could turn off seppuku easily enough, but what to do about them shooting themselves... Takes their gun away, or stop them shooting as far as i can see.

EDIT: I've locked the tabs open on the pause screen now.

[DivFord]

Fix confirmed. Hooray!

Stop them shooting is probably the best option… Beyond the oddness I've been complaining about, I just realised that damaging yourself in the menu carries over into the actual levels. Unless that's hardcore mode, we should probably do something about it.

[Fyll]

I've stopped the Player from shooting or killing himself on the menu. I've also stopped the game from drawing the tabs when you're there.

The gun icon should probably go too, but weren't we thinking about doing something about that?

[DivFord]

Yeah, it probably should. I don't remember discussing it, and it's not mentioned in the "Weapon Icons" issue, so I'm not sure what you're remembering.

[Fyll]

It was in "Shooting through things" #101. About 2/3rds of the way through, we started talking about alternatives to how guns rotate.

[DivFord]

So it is. In that case, perhaps this should wait.

[DivFord]

I've pushed some sprites for the menus.

I thought the number of animation frames on the menu buttons was overkill, so I've fiddled with that code. It seems to work, but I may have made a mess. Sorry about that...

[Fyll]

Looking good, although I think the texture height is a bit small (only a pixel or so, it just moves a little when I hover over it).

Also, you haven't added the score and lives sprites (if they exist. They're called in the code). Also also, the score starts from a negative number so that it's 0 when you enter the first room.

[DivFord]

Oops. Okay, I've pushed the sprites and set the score to start at -1. I'm stuck on the texture height part, since I don't really understand that section of the code.

[Fyll]

Looking at the image, you seem to be missing the last row of pixels?

Also, what's the scribbley one for?

[DivFord]

It looked like you'd coded in a sprite for the moment you click on the button, so I drew a scribble to test it. It never seemed to show up, so I ignored it.

I have now removed it, and fixed the sprite size problem in the process.

[Fyll]

I had, but I've removed that now. I hadn't noticed, but it never showed that sprite, because it leaves immediately. So now it's just not an option anymore.

So, is this all for this Issue? We have a pause screen (plus extras), and saving has its own issue....

[DivFord]

Reckon so.