• Log InLog In
• Register

Student Game Dev Part Seven - User Interface

Post a Reply

Soan New Zealand194 Posts January 10 2014 06:14 GMT #1 Part One - It begins Part Two - Technical Foundation Part Three - Game Design Part Four - Input and Physics Part Five - More Physics Things Part Six - Even More Physics This Week Hello again TeamLiquid! Welcome back to my blog about the development of The Adventures of Sam the Pirate, the 2D platformer I'm creating as the final game project for my Bachelor of Software Engineering degree. Hope you all had a great Christmas and New Years, I spent far too much time playing Hearthstone, a bit of Civ5, and spending time with my family to do any work. I have managed to get a bit of work done on some user interface related things over this past week, and have a new piece of concept art to show off today as well. I had some thoughts over the holidays on fixing the remaining physics issues, but have not got around to implementing any of them yet. User Interface Most of the work done on the user interface so far has been pretty basic low level stuff, setting up for the more interesting stuff later. At the moment, an interface layout will be stored in a file, and be loaded when needed. When the player forces the displayed interface to change, through starting a game from the main menu for example, the displayed interface will simply be switched. In the case of opening a menu while in a level with the level interface displayed, I'll be able to directly force an separate interface to be displayed over the top of that. So basically I'll have interface layouts stored in different files, and be able to display multiple layouts at once. As well as creating the basics mentioned above, I've created a generic button class, with normal, hover, and click states. Creating this generic class has given me a little bit of a problem however. If I want to create multiple buttons that each take different actions, I'll have to create extra class, each inheriting from the generic button class. While this would work, I don't really want to do it as it is inefficient, and I want the user interface system to be fairly generic, so I can more easily reuse it in future projects. As I've used Lua scripting on my debug console, allowing me to add commands without changing code, I'm considering doing something similar here. As the interface layouts are stored in files, I could also store the name of a Lua file, and function within that file for each button, allowing me to ensure that each button has unique functionality without creating tons of different classes. Still thinking about how best to implement this however, so we'll see how it goes. The user interface system in general will also need to scale based on display resolution. I have a target resolution of 1920x1080 (art will be created with this resolution in mind), but it's unrealistic to assume that everyone uses that resolution. It should be relatively easy to compare the resolution the game is running in, with the target resolution, and make adjustments based on that. New Concept Art What's next? Officially back to class next week, where we'll also be getting a new capstone assignment. We finished a research based capstone before Christmas, and this new capstone will be development focused. With any luck, I'll be able to use the capstone to create a level editor, which I was planning to do already! I have a feeling the tutors might want me to do a bit more though, so I'm also considering turning it into more of a general engine editor. So as well as creating levels, it'd be able to create interface layouts, preview sprites in the game engine, etc. It would certainly make things easier, as currently levels and interface layouts are created by hand in text files! So until Monday, and I know what I'm doing on the capstone, I won't know 100% what I'll be working on next. Likely I'll be continuing with the user interface stuff, planning out the level editor, and continuing to adjust/fix the physics. Keep up to date! Be sure to follow me on Twitter, and like the Facebook page to stay up to date on future content and blog posts when they happen. If you have any questions don't hesitate to ask, either through Twitter or Facebook!

MrShankly United Kingdom370 Posts January 10 2014 22:44 GMT #2 Never noticed your blog before! Rated 5 stars! I graduated as games programmer but I switched to doing regular software development. At the moment I work for a company that builds 3d Visualisations for mobile tablets and stuff so i still get to use my 3D/gfx skills and do regular mobile Dev. Sometimes I kinda miss working on games though. I'm currently building an iOS app in my spare time. Maybe when it is done I will try build a game.

Yferi United States90 Posts January 14 2014 09:59 GMT #3 For your buttons, you could use the observer model and have all classes that you want to respond to the button click implement a certain function (like onButtonClicked() or something). When you create the button, register each listener and when the button is clicked, call the onButtonClicked() method for each listener. That way, what the button does (receiving input) is decoupled from your listeners (doing stuff once you've received input). By the way, it would be cool if you could post some videos/screenshots of your game so far. Keep up the work!

Soan New Zealand194 Posts January 15 2014 19:24 GMT #4 haha, I totally forgot about using the Observer pattern like that. I'm using it elsewhere in the project, so I did know it existed, just didn't occur to me to use it like that, even though I've seen it used elsewhere. Ended up going with a similar Lua implementation to what I used for my debug console, and I'll probably talk about it in this weeks blog. I do want to do videos/screenshots of the game, but there isn't much to look at at the moment. Currently the tiles and character are just white boxes with black letters to indicate what type of tile/what animation should be playing.

Please log in or register to reply.