Sign in to follow this  
Followers 0
occams_razor

how to make In-Game command and control panel?

5 posts in this topic

Hi all,

 

I'm programming the beginnings of an RTS game. Right now, I have a rudimentary 3D plane where units walk around on it and when they get within range, they shoot each other (without a shooting animation, but they have a walking animation). There are only units and walls for now.

 

Anyways, I thought it would be nice to have a 2D command and control panel on the bottom third or so of the screen. I'm using windows 7 and directx 9. I don't think this question requires me to show code because its more of a "general concept" question. I'm not sure what the general practices of posting code are but I would prefer to keep the code private for now, and just ask for a general answer.

 

Basically, I want to make a panel so when you select one or more units a bunch of command options come up, it has a little close up picture of the unit type and there is always a mini map in the right hand side of the control panel. Does anyone know of the general techniques people use to do this? Thanks!

 

occams_razor

0

Share this post


Link to post
Share on other sites

In general, you would define a shape at the bottom of the screen (say, a rectangle) and then dedicate specific parts of it to do what you want. So in the panel, you have a rectangle in the lower left which loads a portrait when a unit is clicked, a set of shapes that respond when clicked for command buttons, and so on.

 

So you'll have to define the screen areas, draw the shapes, set up event hooks to populate the shapes with the correct pictures when a unit is clicked, and set up event hooks to carry out the right commands when buttons are clicked. It's not really any different than setting up any other graphics on the screen that the player can interact with, and if you've ever coded a menu or any graphical interface you've probably already got the techniques that you need.

1

Share this post


Link to post
Share on other sites

Hey, thanks guys! I got really useful info from your responses.

 

Khaiy: So yeah, what i had in mind was a rectangular region, it just didn't occur to me to make it a rectangle in 3D space that looks 2D because it moves with the viewer. So, I'll implement it in that way that you pointed out to me.

 

JTippetts: It's really challenging for me to use software design, the way I've been doing it so far is just coding without design at all a little bit every day. The result is that it grows sort of amorphously smile.png  and I end up going back and tweaking a lot of stuff. Even though I use C++, I don't use object oriented design because I think to myself "linux is written in c" and so I have used that as an excuse in the past. This UI will be a good opportunity for me to design it clearly and then implement it based on a blueprint. So from your reply where you talk about "proxy type of component for the camera" you mean that all the buttons on the UI have an object oriented class object (or as I would have used in the past, a struct) that the buttons talk to when they are clicked and then the proxy objects talk to whatever unit receives the command. I'll design a little bit every day for a while before I start coding the UI.

0

Share this post


Link to post
Share on other sites

JTippetts: It's really challenging for me to use software design, the way I've been doing it so far is just coding without design at all a little bit every day. The result is that it grows sort of amorphously smile.png  and I end up going back and tweaking a lot of stuff. Even though I use C++, I don't use object oriented design because I think to myself "linux is written in c" and so I have used that as an excuse in the past. This UI will be a good opportunity for me to design it clearly and then implement it based on a blueprint. So from your reply where you talk about "proxy type of component for the camera" you mean that all the buttons on the UI have an object oriented class object (or as I would have used in the past, a struct) that the buttons talk to when they are clicked and then the proxy objects talk to whatever unit receives the command. I'll design a little bit every day for a while before I start coding the UI.

You might want to read up on on some design patterns, and make a serious effort to learn how to engineer a system. Just because Linux is in C rather than C++ doesn't mean there isn't a hefty chunk of design going on.

You can iterate on design, that is fine. I myself have never worked very well doing all of my design work up front, then trying to code the system perfectly from that design. That approach doesn't work for very many people, actually. However, there does need to be design done as you work, and you really, really need to engineer a sensible framework or system upon which everything will be built. Or else, as you put it, everything grows "sort of amorphously". Try working with that amorphous codebase three years down the road, when you need to fix a newly discovered game-breaking bug, only the code that you wrote that contains the bug is a huge steaming pile of spaghetti with dependencies that thread everywhere in such a brittle fashion that the slightest of changes has ripple effects that propagate throughout the entire project. It can happen, but you can choose your design so that it does not.

In Goblinson Crusoe, the framework I chose is a component system. (You can read the article section here for some good introduction to component systems.) Basically, each object is a generic container for a collection of components that define the behavior and characteristics of the object. Is an object a combat unit? It needs a Vitals component (to hold life, food, elemental powers and resistances, etc...), it needs a CommandQueue component (the puppet master that executes low-level tasks such as take a step, cast a spell etc...) a FloatingCombatText component (listens for events regarding combat, such as damage, healing, status changes, etc... and queues a text message up to be displayed above the unit's head) a BuffsDebuffs component (container for status-modifying buffs and debuffs) the various components for animation and hosting of particle effects (AnimatedModel, AnimationController, AnimationMap, etc...) and a few others. Each combat unit also needs a PlayerTag component to define faction affiliation, or who owns what, as well as a Controller (Human Player or AI controller variants exist) and any auxiliaries that are required. Human Player units possess an additional set of components acting as go-betweens for the UI: a PortraitTabSelectionProxy acts as a go-between for the unit and it's selection portrait, which is the portrait the player can click on to select that unit during the player's turn; when the frame is selected via the mouse, a Selected event is passed from the UI widget to its owning object via the proxy component, telling it that it is now active and ready to be controlled by the player. (GC is a turn-based RPG, by the way.) The player unit also has a QuickBarProxy that acts as a go-between for the player's row of quickbar buttons and skills. When a hotkey corresponding to an action button is pressed, or when a button is clicked, the button generates an action event that is passed, via the proxy, to the unit. And so on, and so on.

Note the use of proxy components in this case. The UI widget gathers some input and decides, based upon the input, that something needs to be done to a particular object. But since objects can be comprised of pretty much any combination of components, and since objects are generic containers rather than some kind of interface class, there is just no built-in way to tell the object what it needs to be told. The proxy is the UI widget's "way in" to the unit, the mouthpiece by which it can speak to the object, using the particular "language" that is central to the widget's behavior and which the proxy understands. The proxy is responsible for handing that communication on to the object. Since the UI widget talks to the proxy rather than, say, directly to the Player Controller you are free to build different Player Controllers (perhaps for different kinds of control schemes or types of units) without having the code the widget to talk to all of the varieties. You limit the dependency of a player-controlled unit upon the UI code to one specific module (the proxy) rather than spreading that dependency out among various classes.

All of the complex behavior of a combat unit, then, is broken down into these kinds of modular "pieces" that are plugged in to the object to build complex behaviors. Each nugget has been broken down into specialized tasks, and each works in relative isolation without having to be aware of the other pieces, although there are, of course, a few places where dependencies are built-in. An AnimationController, for example, is useless without an AnimatedModel to work on and does its work directly upon the AnimatedModel if it exists. Similarly, the AnimationMap (which converts events such as Start Walking, Stop, Turn and Melee Attack into Play Animation commands passed to AnimationController) depends upon AnimationController. But other components do what they do in mostly complete isolation. FloatingCombatText, for example. It doesn't have any explicit dependencies to any of the other components, nor do any of the other components have any explicit dependency upon it. Its sole purpose is to eavesdrop on the events being passed (the primary means of communicating with an object is through events), cherry-pick the ones it is interested in, and build a floating text message in response.

The basic framework I am now using for this system is provided by the Urho3D library, which builds the foundation of the component and messaging systems as well as rendering abstraction and so forth. That is what I mean by choosing a framework. Either you pick a library/engine that has such a framework built-in, or you design your own custom-built framework from the standpoint of creating a flexible enough system that you can realize your design upon it and it will help you to constrain your design to something that hopefully won't end up as a pile of spaghetti with weird tendrils all over the place.
3

Share this post


Link to post
Share on other sites

JTippetts,

 

That is a lot of good information and I'm thinking about how to do all these different things (component systems, design patterns, and proxies) to prevent it from being brittle and not have the whole system sensitive to a change in a single part of it. It's not trivial. Thanks for the help.

0

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0