ExploRPG DevBlog 2
28/6/16
At this point in development, the game is not currently ready to pursue a mass audience or public recognition. At this early stage in development, I am mostly writing these devblogs for the purpose of looking back at the development history of the game - some people find that interesting, after all.
It’s been a while since I’ve last updated, so I’ll briefly cover the last few months in this entry.
The engine that the game is being developed with, JMonkeyEngine (JME), recommends using a toolset called NiftyGUI to handle user interfaces (UI), such as the title screen, pause screen, health display, etc. It claims to make programming user interfaces easier, which is something that I must, frankly, disagree with. The alternative is to use different toolsets, which are not supported natively and, thus, require more effort to integrate into the engine, or to develop the UI manually using the GUI Node, a node that renders to the screen after all other rendering processes complete to display graphical elements that should be rendered “on the screen.” The downside to using the GUI node is that the developer must manually handle issues such as scaling the UI to differing screen sizes that the users may have.
I began by attempting to create the game’s title screen, using a temporary logo that I mocked up (ExploRPG is the working title, not the final title) and a static image background (the intention is for the final game to display random areas of the in-game map in real time). If you are curious, this is the mockup (full disclosure: the background image is something I found on Google and is merely temporary):
28/6/16
At this point in development, the game is not currently ready to pursue a mass audience or public recognition. At this early stage in development, I am mostly writing these devblogs for the purpose of looking back at the development history of the game - some people find that interesting, after all.
It’s been a while since I’ve last updated, so I’ll briefly cover the last few months in this entry.
The engine that the game is being developed with, JMonkeyEngine (JME), recommends using a toolset called NiftyGUI to handle user interfaces (UI), such as the title screen, pause screen, health display, etc. It claims to make programming user interfaces easier, which is something that I must, frankly, disagree with. The alternative is to use different toolsets, which are not supported natively and, thus, require more effort to integrate into the engine, or to develop the UI manually using the GUI Node, a node that renders to the screen after all other rendering processes complete to display graphical elements that should be rendered “on the screen.” The downside to using the GUI node is that the developer must manually handle issues such as scaling the UI to differing screen sizes that the users may have.
I began by attempting to create the game’s title screen, using a temporary logo that I mocked up (ExploRPG is the working title, not the final title) and a static image background (the intention is for the final game to display random areas of the in-game map in real time). If you are curious, this is the mockup (full disclosure: the background image is something I found on Google and is merely temporary):
And this is what it looks like in-game:
It took an unimaginable amount of time to create this screen using NiftyGUI; I’m starting to find it to be quite ironically named. The documentation is incredibly sparse, leaving me to spend significantly more time than I feel should be necessary just to simply render two images (the background image and the logo image), a few buttons, and some text. I thought CSS was annoying, but this is agonizing. That said, at least I managed to make it work, right?
The next step,in terms of UI, was to create the console pop-down window. For those unfamiliar with what I mean by “console,” many video games have a window similar to a chat window that can be opened and have commands input directly into the game to do things such as spawning enemies, loading a certain area, toggling collision detection on and off, etc. In many PC games, you’ve seen the console if you’ve ever hid the ~ key. It’s incredibly useful for development as it allows you to quickly test things - such as spawning an enemy, testing combat against the enemy, and then changing it’s health values on the fly to experiment with different strengths for that enemy, al without recompiling the game.
I have had endless trouble trying to implement this using NiftyGUI. More insultingly, it even includes an integrated “console-window” preset that just doesn’t seem to work for me. First, I was receiving compile errors I couldn’t resolve until I figured out - or at least, I think this is the case - that only one instance of NiftyGUI is allowed at once. So I did a lot of restructuring (breaking the title screen in the process, which needed to be fixed) to try to have only one instance of Nifty-GUI and switch between the different UI “screens,” as they’re called. This compiled, but once in-game, I seemingly couldn’t call the console window.
As it turns out, the problem wasn’t that the console window screen wasn’t being switched to, it’s that it wasn’t displaying (it was invisible), for some reason. After resolving this issue, I couldn’t work out how to receive inputs from the console and display output into the window, the one critical feature of a console window! Every single attempt resulted in an endless barrage of compile errors. For the time being, I’ve thrown in the towel in frustration. I’m currently debating whether it would be better to stop using NiftyGUI altogether and implement the UI manually - it seems it would allow for more flexibility, but also more work.
Either way, to absolve my frustrations, I decided to start focusing on developing other features for the time being. Currently, the temporary character model has semi-working animations and basic movement implemented, and I’ve been focusing most of my efforts on improving this and working out how to handle environment streaming (I am new to 3D games development, after all), a process I will detail in a later devblog. From here, I also want to focus on implementing some basic combat and NPCs, and after this I will revisit developing the UI.
Unfortunately, there are no in-game screenshots I’m willing to show, currently. The game is still in too primitive a state, so I feel that sharing images of the games current state will color the perception of the game negatively towards people who are unfamiliar to how ugly a game’s development is at this early stage. However, I am taking screenshots to create a video at a later date, when the game is more final, detailing the development history of the game.
If you’re interested in my posts, please subscribe to this blog for more news about ExploRPG! Thank you for reading.
The next step,in terms of UI, was to create the console pop-down window. For those unfamiliar with what I mean by “console,” many video games have a window similar to a chat window that can be opened and have commands input directly into the game to do things such as spawning enemies, loading a certain area, toggling collision detection on and off, etc. In many PC games, you’ve seen the console if you’ve ever hid the ~ key. It’s incredibly useful for development as it allows you to quickly test things - such as spawning an enemy, testing combat against the enemy, and then changing it’s health values on the fly to experiment with different strengths for that enemy, al without recompiling the game.
I have had endless trouble trying to implement this using NiftyGUI. More insultingly, it even includes an integrated “console-window” preset that just doesn’t seem to work for me. First, I was receiving compile errors I couldn’t resolve until I figured out - or at least, I think this is the case - that only one instance of NiftyGUI is allowed at once. So I did a lot of restructuring (breaking the title screen in the process, which needed to be fixed) to try to have only one instance of Nifty-GUI and switch between the different UI “screens,” as they’re called. This compiled, but once in-game, I seemingly couldn’t call the console window.
As it turns out, the problem wasn’t that the console window screen wasn’t being switched to, it’s that it wasn’t displaying (it was invisible), for some reason. After resolving this issue, I couldn’t work out how to receive inputs from the console and display output into the window, the one critical feature of a console window! Every single attempt resulted in an endless barrage of compile errors. For the time being, I’ve thrown in the towel in frustration. I’m currently debating whether it would be better to stop using NiftyGUI altogether and implement the UI manually - it seems it would allow for more flexibility, but also more work.
Either way, to absolve my frustrations, I decided to start focusing on developing other features for the time being. Currently, the temporary character model has semi-working animations and basic movement implemented, and I’ve been focusing most of my efforts on improving this and working out how to handle environment streaming (I am new to 3D games development, after all), a process I will detail in a later devblog. From here, I also want to focus on implementing some basic combat and NPCs, and after this I will revisit developing the UI.
Unfortunately, there are no in-game screenshots I’m willing to show, currently. The game is still in too primitive a state, so I feel that sharing images of the games current state will color the perception of the game negatively towards people who are unfamiliar to how ugly a game’s development is at this early stage. However, I am taking screenshots to create a video at a later date, when the game is more final, detailing the development history of the game.
If you’re interested in my posts, please subscribe to this blog for more news about ExploRPG! Thank you for reading.