Orxonox

Project: HUD

Journal:

6/2/2008: I am working on another HUD version, what do you think of this concept: it wont be many separate parts over the whole screen like previous ones. I will try to paint few elements into one single module, tell me what you think about that idea. Here is an example.

30/10: BINGOOOOO!! nearly all obstacles are removed. Now I can finally begin to work.

29/10(3:00 pm): I figured out how to add a HUD window on Solaris at ETH. And I will try to design some windows my own as next, and to make it possible on my mac.

29/10(1:00 am): I could change an existing sample file so that it made an overlay with some simple text on it. But when I use the method SHOW(), though it passed the compiler, but the debugger came out and told me "Program received signal: EXC_BAD_ACCESS". Anyway, it seems to be the right way. I will try it again on Solaris at ETH tomorrow(or today:D).

28/10: Incidently, I found a topic in the manual which talks about HUD. The right class for it is Overlay. As much as I understood: Either you can design overlays with Scenemanager::createOverlay, or you can make Overlays with an editor. Hopefully, I am on the right way.

25/10: I gave up to make a new project on my own. I will try to make some changes in the existing sample file.

24/10:
.mm file cannot work on other computers than Mac, so I still to have figure out how to make a new project.
It seems to be very complicated to show something on the screen. I read a full example and tried to make one on my own but the problem still exists that I can't make a new project.

23/10/2007:
I figured out how to make a new project on Mac, but there is a .mm file instead of .cpp.[/img]

Hey superegg ^^

Firstly it's great we have an ambitious Mac contributor. Now this is going to be hard because not many of us are very good with Macs. I will write my semester thesis on a Mac but I'm not really far yet, so I'm not really comfortable with it.

You still seem to struggle running Ogre so try to install Ogre on your Mac according to this side.

If this is working try to set up an application

Then if the first Basic Tutorial is working, try if Orxonox works as well. Orxonox is in fact nothing else than one of those Examples in the Tutorial (at least right now)

Hope to hear from your progress soon.

hi chai,

I can't help you with your mac-problem (isn't it possible to just use .cc instead of .mm or is mac so unflexible?), I'm sorry. But you don't have to create your own project. If you're able to build the orxonox trunk with either a self-compiled ogre or an SDK, you can modify the trunk-code for testing purposes. For the implementation you can get your own branch, because it's not possible to commit changes to the trunk directly.

.mm seem to be XCode Core C files. See here for details

Mac is not that "simple minded"... A friend of mine had the idea of creating a game on mac a few years back, and he used .cpp/.h-files.

Doing some research on cmake - and knowing that it has crossplatform capabilities, I found out that cmake can generate xcode files, as it does this for kdevelop.

Run the following command of the top orxonox dir, and it should create the needed files. cheers
nico

[edit] typo

I actually tried to follow the introduction we received two weeks ago on the mac. But I couldn't even install ogre on it.

Now I am a little bit confused, because I downloaded "OgreSDK", which can work alone. I also downloaded "Ogre.framework", which I only have to link into my .mm file and it works. The third version I have is from sourceforge, which after compiling is 2 GB big, although the other two versions are about 100 MB. The joke is, all the three version work similarily. So I don't know what is better in the third version.

cheers

The 3. version includes most probably several debug libraries, which are A LOT bigger than the others.

The ogre framework seems a little outdated (it's from january '07)... and from a little reading, it looks like an adapted ogreSDK.

And ogreSDK is the current original from the ogre page.

But I am unsure what this third version is and where exactly you got it from. Maybe a daily snapshot...

just my .02$

push

superegg wrote:6/2/2008: I am working on another HUD version, what do you think of this concept: it wont be many separate parts over the whole screen like previous ones. I will try to paint few elements into one single module, tell me what you think about that idea. Here is an example.

well, there are some advantages and some disadvantages:
pro: the hud looks like a unit, there are no scattered parts
contra: the hud covers a larger part of the screen, causing more action beeing hidden behind.

i don't recommend a hud looking like a block, but if the elements are loosely connected, maybe with transparency, it might look good. sketches are always helpful

Full NACK!

We need an HUD, and not a virtual cockpit. Yes, it looks more like one part, but it also forces you (or whoever gets the job) to create a new cockpit for every new ship/cockpit we introduce.

Start with a minimal HUD, which comprises of only the mandatory part, then add whatever you find appropriate.

cheers
nico

Well, since 6 months I didn't know how you guys understand the word "HUD" !!

In my opinion, the better it looks, the more distracting it is. The old version is the ugliest one, but everything is clear there.

And what is mandatory in a HUD? I would say somebody who has written this game, doesn't need anything to play this game, cause he knows every thing by heart. And somebody, who sees this game at the first time, every small help would be great.

Anyway, if the cockpit annoys you, I can, as x3n said, make it transparent.

It would be quite helpful if you guys sketch an example for me of how you understand this HUD.

Btw. the trunk version is just a black screen. Is this true?

Btw. the trunk version is just a black screen. Is this true?

Might well be. We didn't have the time to merge FICN back into the trunk - and we are not going to do it, until we did some cleanup.

HUD, Head-up Display: A semi-transparent graphical and textual display of information projected upon the field of view of a pilot of an aircraft.

Semitransparent, and field of view are the important part. Compared to older aircrafts which had no HUD, the pilot was force to look down to glance at his instruments, thus removing his attention from a main action.

It would be quite helpful if you guys sketch an example for me of how you understand this HUD.

Didn't we do this over and over...
Have a look at Freelancer, Starlancer, Freespace [12], Aquanox [12]. While Freespace and Starlacer are typical Spaceshooters, Aquanox plays in the ocean, and Freelancer somewhat describes best the gameplay we are heading for.

If you need another head to head explanation, I could be at the ETH any time soon. Just write a mail.

cheers
nico

Semitransparent, and field of view are the important part. Compared to older aircrafts which had no HUD, the pilot was force to look down to glance at his instruments, thus removing his attention from a main action.

The player has to look for information he needs, it doesnt matter whether these information are shown semitransparently or not. Unless you put your HUD directly in the middle of the screen, but then he cannt see anything else.

Didn't we do this over and over...
Have a look at Freelancer, Starlancer, Freespace [12], Aquanox [12]. While Freespace and Starlacer are typical Spaceshooters, Aquanox plays in the ocean, and Freelancer somewhat describes best the gameplay we are heading for.

Well, for the first HUD I designed (it could be the one you could call "mandatory"), you guys told me that many other information were missing. So Beni explained me what should be added. I painted all parts and added them to the HUD. And this time, all components were transparent, and you guys told me, it didnt look good.
So what is in YOUR eyes THE HUD, which looks good, fulfills its whole function, means that it is large enough to give the player necessary information, BUT small enough that it doesnt distract the player?

btw. I just looked at the few examples, Starlance has a quite large cockpit, so does Aquanox.

I think the criticism of the first HUD should be more specific, guys. Not good is way not good enough constructive criticism. Also be more specific what each example does right, and what could be better in each example.

About the functions, there are quite a lot and since the game design is not fully finished yet, the functions may change.
I think the things which were not that great was the design of each function. Bars are maybe better than numbers. Sometimes one needs both.
Also the design is rather minimalistic and it does not use gradients and round or oval forms, which are important for a nice looking design.

About the examples:
Aquanox: First thing is the symmetry. There are similar things on each side.
The most important information (where is my enemy/alliance/thing to protect) is located in the middle. The colored triangles are here to point to those things. Red is enemy, yellow is for items and green for allies.
The over all design has its style. This means all bars look the same. Which is good. All bars are dashed like. Also the color of the bars change when they show less percentage of something. This color goes from green (much) over yellow, orange to red (not that much anymore). Those bars may indicate many things, like health, armor etc.
Then a highlight: The radar in the middle, showing the ocean bed and on top of it objects. This of course works not in Orxonox. Notice the bar decoration left and right. Also look at the transparency gradient. It's not everywhere the same green.

Hope this helps to specify more exactly what we are talking about.

First of all: thanks to superegg for his initiative to do the HUD. In the long history of Orxonox we never manged to create a complete working HUD. The most important reason for this: We were never able to define the content of a HUD.

So I fully agree to beni. Be specific and for the start: minimalistic.

Create a modular HUD, meaning: Each element (for example the speed-o-meter, the ammo count, shield energy) is independent of all others. It may be placed at any location on the screen (like a GUI element). With this you will be able to rearrange them as you please and even create different cockpit styles (why not all in one block... no problem if it's modular).

1. Create modular HUD elements
2. Put them into a HUD container, test them
3. Experiment with different styles (not sooner)

This will allow you to extend the HUD at any time when new functionality is introduced into the game. The HUD represents space craft attributes. Never create a HUD element for a space craft attribute that does not yet exist (no sense in showing the amount of ammo a space craft has, when the underlaying space ship implementation doesn't have a ammo attribute).