Sign in to follow this  
  • entries
    198
  • comments
    445
  • views
    82956

## Lazteroids2::UI

Sign in to follow this  

68 views

Okay so I think I'm going to tackle the UI next in my game. I've only written anything like this once, and it was for our Full Sail final project called "The Omega Initiative" (I swear I'll put the site back up someday).

It was rather lame in that it didn't have any windows. You could create buttons, labels and sliders. That's about all. I'd like something a little more robust for Lazteroids 2, so I'm going to do some brainstorming. Oh yeah, and you guys have to read as I brainstorm out loud. I've done a little thinking on this, but nowhere near enough, so hopefully writing this stuff down as I think it will help.

Soooo, I might go about creating a window class that takes a width and a height in the constructor. The class could hold a of a control base class, which is the base for all controls, which contains things like position, size, and value. The window class could have a function such as NewButton, NewLabel, NewTextBox, etc... that will take coordinates and such, local to the window. For example, (0, 0) would be the top left of the UI window, not the game window.

All controls will take an x-position, y-position, width, height and default value parameters upon creation. Basic controls I'd want would be:
  • Button: This control will act like a normal button. Click it and it does something. How does it know what to do? When you create it, you will pass it a function pointer. That function is called whenever the button is clicked. (*)

  • Label: Simple text label. Mainly used to label things, because things need labels.

  • Text Box: This one is tricky. I've never actually attempted to create a text box before, so it should be interesting to try and work out... *cringe*

  • Slider Bar: Typical slider. This one will take additional parameters, min-value, max-value, and ticks. Ticks is the number of "steps" in between min and max. So if you had 0 for min and 100 for max with 0 ticks, you could either have 0, or 100. If you had 1 tick, you could have 0, 50, or 100. etc...

  • Scroll Bars (?): So... there might come a time where I've put too much in one window. Do I just resize the window accordingly? Or I just draw all the overlapping crap anyway? Or do I fuck with trying to make a scrollbar? *shudder* ... I'll decide on this later.

  • Image: This will just take a texture ID number and render the texture on a polygon. Sho'nuff.

(*) Okay, so one of the problems i'm going to face is telling what has focus and what doesn't. My game uses the mouse to aim, so i can't very well give focus to a window if the user clicks where a window is while trying to fire, so I suppose I could only accept UI clicks if the game is paused. I guess in each windows update function, I can check to see if the game is paused, and if it is, then check the mouse position. If the mouse position is over the current window then the window will have focus and can register the input.

Another thing is the UI textures. How do I go about doing this? I could always hardcode the texture into the game. Just load a simple TGA file and stretch it to the length of the polygon that the window is rendered on, but that would be messy. Another option, separate TGA files for each part of the window (Top left, top right, top, left, right, bottom left, bottom right, bottom). That might work but could become messy if I want to change it later and i have to rename a bunch of files in my code. An extension of this, is I *could* just give my window class a folder name that contains filenames such as "topleft.tga", "button.tga", "slider.tga", "slidertick.tga" etc... this would allow me to have multiple windows looking differently if I want. Decisions, decisions.

So in the end, we have:
  • CWindow
  • CControl
    • CButton
    • CLabel
    • CTextBox
    • CSliderBar
    • CImage
  • CWindowManager (going to need some way to keep track of all the windows

I know it seems like a lot of hastle for such a small game, but i've literally played games where the UI was so horrible, I couldn't stand to play it. Damnit. Now that I look at all that I wrote, this will be a lot of work. If anyone has any comments or suggestions, please tell me. I'm flying blindly into this.
Sign in to follow this  


1 Comment


Recommended Comments

I say you implement the bare minimum. Get what you NEED coded and usable, and marvel at that completion, rather than spending many nights of indecision staring at your code.

Write it.

Build it.

Use it.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now