First off, some rewrites from the last update. The Input model is now its own object, so instead of typing Control.input_horizontal_previous it now is input.horizontal_previous. Also Control has been renamed to game, and so where other variables renamed, especially if they ended in _state. Additionally, I added the _held variables to the face buttons, and they count how steps has the button been held for. And lastly, I omitted last time on describing the pointer model, which is similar to the keyboard, gamepad and touch control types, but not quite.
The pointer model is active when the control_state, now just control, is keyboard or touch. This is because on keyboard, the mouse is accessible, and can be used to navigate menus as well as with the keyboard. On Touch, it is awkward to navigate menus with a virtual joystick when the menu item can just be tapped. On keyboard, the pointer is the mouse, and on touch is the first touchpoint. The pointer model keeps track of the current and previous x and y values, as well if the pointer is clicked, previous, pressed, released, and held. On keyboard, the x and y can change whether the pointer is clicked or not, while in touch, it can only change when it is being clicked. This is all working on the previous release, save for _held which was added on this release, but I omitted it because nothing used it, since menus weren't in the previous release.
But before talking about menus, just a quick explanation on Isometric Projection, since it is simple. Anything that need to draw in Isometric, check if game.perspective==perspective_type.isometric, if so, it draws the isometric sprite of itself at iso_x(x,y) and iso_y(x,y). Those are scripts. Iso_x returns argument0-argument1, and iso_y returns (argument0+argument1)/2. Additionally their depth is set to -iso_y(x,y). The Player also checks for the perspective, and if it is isometric, it subtracts 45 degrees to input.dir, so the Player movements in relation to the screen match the physical input, otherwise, the player would move diagonally in relation to the physical input instead. On the web version, the 'P' key switches between perspectives. I'll later add as a menu option. Speaking of which.
The Menu...
the menu...
the menu. I spent way too much time on this. But I like the end result, still. There is the parent pMenu that has all the navigation logic, and two children, mTitle and mSystem that provide the content and actions. Previously, it was one object that stored all the menus and changed depending of certain veriables. But then there was the settings submenu. It is present on both title and system menus and worked identical except when going back to their top menu. It was too convoluted to check which menu to back to. If I made an identical copy that could back to their proper top menu, I would have to keep them the same and all sort of bug would be waiting to happened. Going back to a top menu is contolled by which submenu is currently active. The quit submenu also suffered from this, but it only had to options, so I made a copy and called the new one exit. So the quit menu backed to the title menu and the exit to the pause menu. But the settings menu is much bigger than quit and exit. Also, quit and exit where a bit different, since exit went back from the game to title screen, and quit closed the game. The settings menu on both Title and Pause do the same thing, so it was going to be confusing. That's when I started experimenting with Inheritance.
The pMenu object has all the logic for navigating menus. It has the array menu[] that holds the menu items. The child fills it up with content. There is the variable menu_position that keeps track which menu item is active. On each step, it reads input.vertical_titled, and based on the that value and the current length of the menu[] array, it determines the value of menu_position. pMenu also has the pressed and back variables. Pressed is set to true if input.attack_released, input.pause_released or input.pointer_released are true. Back is set to true if input.jump_release or input.back_released are true. The children decide what to do with based on those varibles.
Drawing is also handled by pMenu. It stores the variables menu_x and menu_y to determine where to start drawing the menu, spacing for the spacing between buttons and size_x and size_y for the size of the buttons. There is also the label variable that is drawn on top of the menu. Previously, the menu was drawn based on the center of the screen, but now, I want to be able to position the menu more freely. Though I don't think I'll change it from what I have now, the code is more flexible. pMenu draw label on top of the menu. Then for each item on menu[], it draws a rectangle using the size_ variables, and then the string stored at menu. The colors depend if i==menu_position or not. On touch, if the pointer isn't being clicked, menu_position=-1.
The children fill the menu[] with whatever menu they have. There is script menu_goto(menu_type) which is used to change the menus. This script is called when back==true or when press==true. other things can be done when press==true. Right now, only the yes option on both quit menus and start on the title menu do something else than switch menus. And that is just about everything about menus, save for.
The pause menu. Pausing is easy, there is the variable game.pause, which can be set to true or false, and objects act upon it depending on the value. For the Player, the step event calls exit near the top if pause is true, so it doesn't do anything else on that step. mSystem, which is the pause menu, destroys itself if game.pause==false. But the pause menu wasn't working correctly. The menus used to have transitions, but the pause menu wasn't working correctly, so I deleted all that. And pressing and releasing the back button caused for the menu to show up and then it exited back out. And at one point, two menus were created. Previously, the Player controlled when the game would be paused, and mSystem controlled when it would be unpaused. Currently, the game object controls both pausing and unpausing, and it has the variable can_pause which both the Player and mSystem can change. This works, but it feels jimmy rigged. Once I put transitions back, it may how I intend for it to work, but till then.
And that is it so far. I spent too much time on this. I wanted for the Dev Menu to be functional. On the web version, like I had said before, pressing the 'P' key switches perspective. That would be a menu item. As well as the ability to turn on and of the dbug lines. Another new Dev feature was drawing crosslines at the x, y and iso_x,iso_y values of the object, depending of perspective. But because of all the problems with implementing the menu and pause, I postponed on making those features functional, I even took out transitions. Still, I found how useful scripts are.
When I started writing this, it was four days 'till GDC15 Expo. Now, as I am writing this line. I am waiting on the Greyhound Station, waiting to start heading to San Francisco. I took too much time in writing this as well. I hope I can get some time during GDC to add animations back. I am nearly finished animating a character that I could show of with the animation system as well. Still, I hope I have a blast at GDC.
Ps. As I publish this, I am ta GDC.
