When porting our game from mobile to desktop we wanted to add a few desktop specific interface enhancements. Things like using the keyboard, mouse, or managing the Window. By default games are setup to run full screen instead of within a window on desktop platforms, but since our game is pixel art full screen is a bit large on modern 24″+ monitors. So we’re sticking with running inside a window for now.
Ideally we’d allow players to resize the window. In order to support resizing a running scene we would need support to dynamically update every single UI element. Each scene or menu does size, scale, and position UI widgets on the current device (or now window) size, so we will allow changing resolution from a menu and then we will just reload that menu with
replaceScene() after the changing the window frame size. We could build in support for this and attempt to unify the changes into a base class or small set of resize methods, but it would be better done at the first design and creation phase of a game’s development.
/// glview - the cocos2d-x platform OpenGL view reference
/// frameSize - the desired window size
void OptionsResolutionMenu::static_changeResolution(GLViewImpl* glview, Size frameSize)
#if ((CC_TARGET_PLATFORM == CC_PLATFORM_WIN32) || (CC_TARGET_PLATFORM == CC_PLATFORM_MAC) || (CC_TARGET_PLATFORM == CC_PLATFORM_LINUX))
auto glfwindow = glview->getWindow();
auto fsize = glview->getFrameSize();
auto screenSize = glview->getMonitorSize();
int sw = screenSize.width > 0 ? (int)screenSize.width : 800;
int sh = screenSize.height > 0 ? (int)screenSize.height : 480;
// win position
int winx = 0, winy = 0;
glfwGetWindowPos(glfwindow, &winx, &winy);
Rect viewport = glview->getViewPortRect();
Vec2 viewcenter = Vec2(viewport.getMidX(), viewport.getMidY());
// update the cocos2d view frame
int x = int(sw - frameSize.width)/2;
int y = int(sh - frameSize.height)/2;
glfwSetWindowPos(glfwindow, x, y);
// call method with desired size (we get this from user options menu)
float resWidth = 800;
float resHeight = 600;
OptionsResolutionMenu::static_changeResolution(glviewImpl, Size(resWidth, resHeight));
[todo: convert into a gist, and cleanup post]
I’ll post discussion topics here discussing adding or changing the Menu, but I found out adding MainMenu.xib didn’t work correctly as I have thought during the discussions over on the forum.
Looking into where the menu is created I found out that GLFW3 actually creates its own default menu with only two Menus services(App menu) and Window. The code where it sets this menu up is found in cocoa_window.m over on github.
Once I figured this out I had to investigate how to edit the app or window menu. Looking over the window code, and searching through the various header files from within XCode I was able to add an item to the Window menu.
Update 2015-01-17: I’ve posted up an example project using cocos2d-x 3.3
void STDeviceMac::addMainMenu(GLViewImpl* glview)
NSWindow * appWindow = (NSWindow )glfwGetCocoaWindow(glview->getWindow());
// make your obj-c calls here
NSMenu menu = [NSApp windowsMenu];
NSMenuItem* menuItem = [[NSMenuItem alloc] initWithTitle:@"Check for Updates"
[menuItem setTarget:[SUUpdater sharedUpdater]];
NSMenuItem* menuItem = [[NSMenuItem alloc] initWithTitle:@"Steve's Test"
I ran across a twitter post to check out a new game engine called Spark. It sounds like an over lofty idea, but with the right focus and vision. I signed up and will give it a test drive if I get into the Beta.
Data-driven development is something every game developer learns over time when they realize the extra work required to go find and tweak the variable, or create another class for a new enemy. Instead they can move as much as possible into data configuration files or scripts separating it from the game logic and core engine code. This allows changing assets on the fly or pulling them from different sources, adjusting parameters for procedural generation algorithms, or even creating new enemies or modifying their behavior. It can allow simple modding support without requiring full scripting experience.
Now with any new games or prototypes I’ve started to build the data models and configuration first. There’s plenty to be said about this topic, and others have written about it better than I could today, maybe I’ll expand upon this topic in the future once I’ve built up a library of data-driven prototypes as well as continued writing practice.