Jump to content

  • Log In with Google      Sign In   
  • Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

Rorakin

Member Since 27 Oct 2012
Offline Last Active May 15 2013 06:04 PM
-----

Posts I've Made

In Topic: Custom window GUI system

07 May 2013 - 04:53 PM

Check this thread for many C++ suggestions


In Topic: Where are all the good GUI libraries?

15 April 2013 - 05:47 PM

Alright so I spent most of my weekend reading NGUI code, and I understand the business with the shaders clipping the textures for scrollable panels because to do scrollable panels with Unity camera's would require creating both a separate camera AND a separate layer for EACH scrollable panel. Since only 32 layers are ever allowed in a Unity game, it would not be possible to create an arbitrary number of scrollable panels using cameras in Unity. I was thinking the camera approach would be viable if you set a limit on the number of scrollable panels that are active in the game at any given moment to some number, say 10.

I want to go with this more simple camera based approach for my GUI editor rather than recreate the graphical complexity of using custom shaders, can anyone think of an actual gaming use case that would require more than 10 scrollable panels needing to be used on a single screen in a game? I can't think of any game that does this, so I think I will proceed this way.

 

EDIT: Hmm I just realized the camera approach would work for an arbitrary number of simultaneous scrollable panels if the GUI were 2d only, because then the z axis could be treated as the layer, and separate cameras could be made on different z layers for scrollable panels. Then panel content would be on that z layer but would be contrained by the camera viewport for that layer, but then we lose the ability to do 3d sadly.


In Topic: What should I do?

15 April 2013 - 05:03 PM

Hello, most programmers use existing engines / APIs, you should focus on actually programming with something that already exists. Most engines should already handle rendering, so you won't need to worry about that. Just test your general programming skills by programming some games from "scratch" using some of the free 2d / 3d engines out there. Most companies look for well-rounded programmers / experienced programmers. For example, if you go to a game job site and just look at the job descriptions for "game programmer" you'll find most postings look exactly like this (I just pulled this off gamasutra):

 

Key Skills

• Strong working knowledge of C++ and/or C#
• Linux/Unix environment operating systems and multiplatform development
• Scripting languages
• Team oriented attitude
• Strong knowledge of tools to test software applications/systems
• Advanced debugging skills
• Strong math skills
• Working knowledge of art development/modeling tools
• Self-starter with strong multi-tasking skills
• Excellent communication and organizational skills.

Pluses

• A passion for games
• Unity development experience
• Experience with developing software within a video game environment
• 3D graphics programming
• Experience writing and debugging shaders


In Topic: How to create an efficient Game Menu System

12 April 2013 - 04:42 PM

There's many different ways to do it, but I don't think you need a separate class for the main menu. The main menu is just a collection of buttons that do different things.

You can create a GUI factory class that creates buttons, or just create them manually if all you have are buttons.

Your main loop should just be a finite state machine that pauses / unpauses the game and checks for input / displays different buttons depending on which state the game is in. "Main Menu" would probably be one of the states for your main loop.


In Topic: Where are all the good GUI libraries?

10 April 2013 - 04:34 PM

See, that looks slick and you might think it's awesome, but I notice 2 things:

The skill popup windows are all exactly the same size. This implies someone has had to hand-make that specific window with some fixed-size labels inside. And it means that if I ever write a skill with too much text, I have to go back and edit the GUI, and that's exactly what you don't want.
Earlier in the video (1:30) I see a portrait with left and right buttons next to it. Again, it's just an implication, but that is the classic thing you implement if you aren't able to support a scrolling selection area (which is usually preferable since a player can more easily compare potential choices).

 

Yes this video is a few months old when I was just quickly prototyping my GUI from scratch. The editor I'm making will of course allow 3d animations in addition to the diverse functionality of GUI elements that can scroll / resize / etc. I was just pointing out the 3d stuff smile.png


PARTNERS