GUI

So, the thing that I started working on this week, and was really hoping that it would only take me two days (at least I learned early about this whole setting deadlines business) is a GUI and windowing system for Deceit. I wanted to design it in a way that would be usable for other games that rely on HTML5’s canvas and JavaScript with some simple modification in the future. The way I’m tackling it is a little bit different because I’m trying to keep it as in line with Steve’s vision of the GUI and windows as possible. He’s the one that makes it pretty, and I’m the one that makes it work, but in this case it’s a prettiness/usability matter, so I’m going to do what he tells me.

He gave me a 40px x 40px template for the first window to be based off of, and after working something out to draw the windows, I’ve decided that’s what the rest of the templates should be, at the moment.  If we ever need a custom window or overlay, Steve could design it and base the dimensions and whatnot off of the resolution we decide the canvas to be and we could just draw it out to the screen.

Now what we wanted was to have a dynamic GUI, so the user could click and drag windows and maybe resize them if need be. I know many times when I’m playing a game, if the windows are static and in an inconvenient spot, I get really frustrated, so I want to make them as seamless with the games as possible. 

Since the scaling unit of our game is 10px =1m, we’ve decided to just let the GUI’s size be based off of that 10px size as well. Our other games are most likely not going to use that same scale, so all it took was a member variable and for the drawing method to take that variable into account to allow the changing of scale later on.

Since Steve gave me a window template of 40 x 40, I’m going to look at that as a 4 x 4 template because of scaling. How I draw the window out based on its size is pretty much a O(n) operation (if you consider n to be the units2 size of the window). It starts drawing from the upper left of the window and travels across in the positive x direction, which in this case is to the right (and hopefully for all other cases in the future, unless I work with some engine that has a strange coordinate system) based on the size of the window. If you dictate that the window should be 100px x 100px, then it scales it into the units of the game, in this case 10 x 10, and then draws it out.  So it will draw a square from the template 10x10 (or 100) times.

I’ll need to work on how it picks out the "frames" from the window template, though, because as it is, I have it check whether it’s drawing the first row, second row, any row in between, and then the second to last row, and then finally the last row. I have it checking like that because Steve drew up the window to have shading in certain parts. He asked if having a 3x3 template would screw things up, and as it is now, it would, because I (foolishly) hard-coded which frames were to be used in certain situations. Here’s an example in some pseudo-code:

                if (first row) {

                    if (first column) {

                                        Draw the top left corner, or frame 0;

                        }

                    else if (second column) {

                                        Draw frame 1;

                        }

                    else if (last column) {

                                        Draw frame 3;

                        }

                    else Draw frame 2;

                }

That’s pretty much how it goes, all the way up to frame 15 (16-1, or 4x4, starting he count from 0).  What I should do is take the total width, in pixels, of the frame template image, then adjust it to the scale, then have a variable set dictating how many rows and columns the template has, and then divide the scaled width by that variable to get the “frame” (I just noticed I’ve been using the word “frame” to describe each cell of the template image, so when I say “frame” I mean “cell” from the image, not the frame of the window) size for the window. I won’t adjust for crazy-shaped or oddly-sized templates for the windows, because I don’t think we’re going to have hexagonal windows where the window’s template is wider than its height.

Changing it to work like that instead of having it set in stone which frames (or cells :D) it should use for which situation will allow us to use frame templates that are 3x3, 4x4, or 16x16 (god help us) if need be.

I’ll have to think a little bit more about how I want to do this. The windows are being drawn for the moment . . . but now that I’ve written this all out and thought about it, I might have to change it a little bit, haha!

Currently Working On

Currently, we're working on the first chapter of our 'Deceit' action platformer! As well, we're working on a Kickstarter to help us shift our focus from SAP Business One training to game design!

Read more

Current Projects

Location

US
17285 Sw Arborcrest Way
Beaverton, OR 97006
Email
info@tiger-sheep.com

Get in touch

Give us a call at503-427-8177

Email us at

currentprogress460.png