99 replies to this topic

[mamutas]

Deimos, it is all in your hands now. Could you do another sketch?

[Deimos]

Deimos, it is all in your hands now. Could you do another sketch?

Yeah, no huge rush though I've got quite a bit going on atm. I won't forget about it and the thread ain't going nowhere

[coolp]

Could there maybe be a group move button where you can drag select a bunch of people and set a point and a direction by drag rightclicking and then they'll form up like that? Maybe with formations...
One of the annoying things in the original X-com's battlescope was deploying your troops out of the sky ranger, maybe if we could automate it a little to get the player into the action, without sacrificing control?

[coolp]

The abort button might be a little predominant... it might be easy to click that when you want to click options, or end turn (which you will be doing all the time). Might want to move the abort so that it won't be pressed by mistake as easily.
Great job on the UI! I never thought that I'd find a game like this being developed *open source* and *for free*, the idea that a game that could be one of the best games of the year is going to be free boggles the mind...

[Puasonen]

Looks excellent! Only one thing, I think the ladder picture in "view up/down" buttons are a little bit misleading.. Maybe a picture of an eye would be better. Ladder picture is more like an "unit up/down" picture don't you agree?

EDIT:
Oh, and if there is some more space needed for additional buttons, I think the multi level view doesn't have to be so big.

EDIT2:
One more thing, is there going to be a explanation text when you keep your cursor on a button for a second? You know what I mean? Kind of like pop up like almost all windows programs have. If you keep your mouse still for a second over an some button, there comes this explanation text. If we are doing it, we don't need any text at the buttons, just somekind of picture which gives a good glue what its action is.
It would save a lot of space again..

Edited by Nyyperoid, 25 November 2003 - 04:37 AM.

[Breunor]

There could be a help option that's on by default, and turned off by the user that provides mouseover text for each button.

A group move button would try to move everyone without changing their relative positions, and would probably be a hassle to implement. It's true that it takes an extra minute to deploy, but I'd rather have 1 soldier exit the craft to die to an alien grenade, than the whole team come out at once and die en masse.

[Syntax Error]

I think that the control screen on the right of the battlescape or on the bottom should be smaller and should contains icons (not words), don't forget that the game will work in high resolution (no more in 640x400 like in the forst UFO).
Don't you think?

[Cpl. Facehugger]

Xenocide's default resolution will be 800x600. Xcom 1 was around 320x200.

I like having the toolbar on the bottom, it just seems more nostalgic to me.
And yeah, the abort button is way too close to the end turn button. Could you move it somewhere else? Possibly put inventory or something that isn't dangerous there? Other than those, I can see no major problems! Great Job!

Edited by Cpl. Facehugger, 01 December 2003 - 03:36 PM.

[coolp]

Yeah, a help button would be really helpful. Maybe there could be a hotkey for the information button also, like in Sim City games with the query tool.
And though the toolbar at the bottom is more nastolgic, it does seem like the toolbar on the side works much better, but we probably won't know until we have a working battlescape.

[Syntax Error]

Why couldn' we choose the position of this Toolbar?
If i want it on the bottom, you want it on the right and an other is lefty and want it on the left...

[Breunor]

IIRC red knight mentioned that the hardware must draw all polys that are visible but not ones off the screen. If you make the toolbar float, you must also draw the polys under the toolbar, as well as have the toolbar change configuration if it snaps from the side to the bottom. So there's more programming involved, and you put an additional 25%+ workload on the graphics card. Having a square viewport looks better IMO than a long rectangle, so my vote is for the toolbar to sit on the side of the screen.

[Syntax Error]

Waow, It seems to be quite complicated, but i think the toolbar on the left is very practical, that requires less effort from the hand and the wrist.

Edited by Syntax Error, 03 December 2003 - 03:24 PM.

[Whitewashed]

Should we have save/load button present here as well? In original game it was sort'a annoying to open options window just to save game after each turn, not talking not having a 'load' button in battlescape at all! 

There's a easy solution for this: don't save after each turn and load after each death!

I definately feel that we shouldn't encourage players to do this by placing save and load buttons directly on the HUD!

[Puasonen]

Should we have save/load button present here as well? In original game it was sort'a annoying to open options window just to save game after each turn, not talking not having a 'load' button in battlescape at all! 

There's a easy solution for this: don't save after each turn and load after each death!

I definately feel that we shouldn't encourage players to do this by placing save and load buttons directly on the HUD!

I would have agreed some time ago but these people here have turned my head. We shouldn't make the game more annoying to those 'cheaters'. It's their own choice if they want to cheat.

[coolp]

You should be able to flip the toolbar to the left or the right depending on where you want it. And could you maybe customize the toolbar by making it modular, so if you don't use some buttons you can take them out or something...?

[Puasonen]

You should be able to flip the toolbar to the left or the right depending on where you want it. And could you maybe customize the toolbar by making it modular, so if you don't use some buttons you can take them out or something...?

Is it REALLY necessary? It has been talked before and ppl agreed it brings excessive programming issues..

This is what breunor said:

If you make the toolbar float, you must also draw the polys under the toolbar, as well as have the toolbar change configuration if it snaps from the side to the bottom. So there's more programming involved, and you put an additional 25%+ workload on the graphics card.

Edited by Nyyperoid, 06 January 2004 - 04:27 AM.

[revenant4]

You should be able to flip the toolbar to the left or the right depending on where you want it. And could you maybe customize the toolbar by making it modular, so if you don't use some buttons you can take them out or something...?

Is it REALLY necessary? It has been talked before and ppl agreed it brings excessive programming issues..

This is what breunor said:

If you make the toolbar float, you must also draw the polys under the toolbar, as well as have the toolbar change configuration if it snaps from the side to the bottom. So there's more programming involved, and you put an additional 25%+ workload on the graphics card.

I agree...if someone is set on having this feature they can MOD it in in a v.1+...

[Robo Dojo 58]

If you make the toolbar float, you must also draw the polys under the toolbar, as well as have the toolbar change configuration if it snaps from the side to the bottom. ...and you put an additional 25%+ workload on the graphics card.

I disagree. EVERY video card today has Z-Buffering. That means that the video card won't waste time on rendering triangles that it will never show. It is an extremely effecient process, and has been around for a long time. The 25% wasted triangles will hardly be felt, because the video card will simply ignore them.

The extra coding may be a problem, though.

Ahh... I remember the days when looking into the center of an FPS level would bring the computer to a halt...

[Cpl. Facehugger]

Does the GF 2 have this feature?

[Robo Dojo 58]

Yes it does, but it is nowhere as effecient, nor can it do as much as any of the newer cards.

The newer cards can apply Z-Buffering to shadows and lighting. (Part of Smartshader and Smoothvision). FYI, Z-Buffering is now known as HyperZ III on Radeons, and LMA II on Geforces.

[Tiskaite]

hey is that my lamppost model :o

:edit:

its not hehe

Edited by Tiskaite, 26 March 2004 - 05:21 AM.

[Deimos]

hey is that my lamppost model :o

:edit:

its not hehe

Yup Tiskaite, you're right its not your lampost, I hand drew that pic last year originally. No 3d stuff to be seen in it

[Tiskaite]

nice, it looks 3d

[centurion]

Well, how's the work going?

Just to shock you into doing something: a mockup of my mental image of the battleview.

Almost forgot:
Disclaimer: This image is based on an image posted in this thread, and neither me nor the original creator (Deimos ) cannot be held responsible for any harmful consequence of viewing it, including but not restricted to road rage, net rage or brain meltdown.

Attached Files

•  xenobview2.jpg   58.36K   8 downloads

[Black Dash]

*Switezle..* *POP* (Brain pops out)

- THAT IS SOOO COOL!!!!

Edited by Black Dash, 05 April 2004 - 06:54 AM.

[Robo Dojo 58]

I like that. Very much.

What is the space in the lower right for? Will it be messages, or maybe a quick view of what's on the ground?

[red knight]

Just a suggestion, why not use the bottom to put the soldier stats? The mini radar image looks a little difficult to read. (I may have say this long ago, but I do not remember ).

BTW in short you will be able to construct that UI stuff directly in OGRE as Mamutas has already finished the UI Framework and we plan to release a test app in not so much time... So start the UI work heavily as we (at the programming dept) will not do any graphics UI programming (unless we have to create new active components) anymore.

Greetings
Red Knight

Edited by red knight, 05 April 2004 - 08:10 AM.

[Robo Dojo 58]

I wonder, will the Unit up/Unit down be needed? In apoc, you could click anywhere in the air, and the unit would fly if he needed to/could. It also worked with grounded soldiers and elevators.

I agree with RK, the lines on the minimap make it much harder to view.

[mikker]

remove the little blinking 1. That makes it look too much X-com.

Nice abort-button but it looks too much like a tree.

I like the idea of messages in the buttom piece. You could have stuff like "CÏvilian Died", "Alien Died", "Commander Tommy died", "Alien Spotted", "Commander Tommy panicked", "Commander Tommy under alien control", etc.

Edited by mikker, 05 April 2004 - 09:33 AM.

[mikker]

I wonder, will the Unit up/Unit down be needed? In apoc, you could click anywhere in the air, and the unit would fly if he needed to/could. It also worked with grounded soldiers and elevators.

I agree with RK, the lines on the minimap make it much harder to view.

Apoc had a level up-down system. You can't just click above the unit. Then he will go/fly NORTH, not up.

and the overview should be zoomable.

Edited by mikker, 05 April 2004 - 09:35 AM.

[Robo Dojo 58]

Apoc had a level up-down system. You can't just click above the unit. Then he will go/fly NORTH, not up.

If he has the Marsec flying armor, clicking above the unit makes them fly directly up. The up/down system is to change the view, and the level of your cursor. There is no button in Apoc to make them move up or down, you just select the correct level, and move them. This is easily seen on the many elevators in the game.

Due to the unusual way X-COM handled levels, it probably needed the buttons. But I think they won't be needed anymore in Xenocide.

[Breunor]

OK, a valid point has been brought up here regarding height position in 3D space. Unlike xcom, Xenocide is going to have freeform movement, right? So not only can a unit move just a little or a lot in the normal directions, but also up or down. So a flying unit could walk forward and then "fly" 3 inches off the ground at the very end. If we can also spin the camera's position 360 degrees around the selected unit, how will the cursor's position in 3D space be determined for flying units?

Below is a thought on how this could happen.The green dot is the unit's current position, the red dot is the destination point. You would move the cursor where you want the unit to move while a "flight" button is active. Left and right is how far from your starting point you'd move, while up and down is the change in elevation. The direction you'd move is determined on where you rotate the camera to. The soldier can only move directly to the left or right from their current position, but that is relative to the camera's view if that makes sense. So you rotate the camera and move the mouse until you get the final point in space that you want.

This "free flight" button would only be active for flying units, and then you'd still have to press it to fly in case you just want to walk around. Normal units without flight would move using the standard system of point and click.

Attached Files

•  1.jpg   3.08K   8 downloads

Edited by Breunor, 05 April 2004 - 12:06 PM.

[mamutas]

Yeah, listen to the RK man, cause UI test tool is cometh ye way!!!

[mikker]

but how would you GET to fly, and what elevation to fly to? I can imagine holding down the left button to move the destinationpoint op, if its like X-com. If, as previusly mentioned, a dropdown menu, it could be an option called "altitude" for FS, which would lock the cursor on the Z axis (normally, It can only move X and Y).

[Robo Dojo 58]

I feel uneasy about the moving camera thing. It would be great for beginner control of flying units, but it would get dizzying after a while. There should be a way to control flying units, without having to move the camera. Especially when going through alien bases. (Like a maze... )

Maybe the mouse wheel could control the altitude of the cursor.
Each wheel click would move the cursor's altitude say, a foot. (arbitrary measurement) While you won't be able to control your altitude to the inch, it'd be more than enough to satisfy everyday altitude needs.

As an alternate option, holding down a mouse button to control the altitude would be good. You'd control the X/Y normally, then control the Z when the button is held down. I've seen this type of control in Homeworld 2. It takes a little while getting used to, but it works really well IMO.


I like the idea of being able to turn flying on or off. Sometimes, I want my agents to follow the contours of the land, and pathing can make some major flying mistakes. It also opens up an option, for MC'ed agents to turn off their flying suits. Squish.

[centurion]

I feel uneasy about using the mouse wheel as a "must" for controlling your units; if there is an alternative, it would be good though. I like Mikker's idea, maybe there would be a (yet another) button that would toggle flying, and when flying, the mouse cursor would move a vertical stick in the XY plane, switching to Z coordinate after clicking.

EDIT: forgot the most important thing, this whole problem arises with targeting, right from the beginning, so whatever is implemented, it would be nice to use the same method in flying and targeting.

Edited by centurion, 05 April 2004 - 01:21 PM.

[ATeX]

I've seen this type of control in Homeworld 2. It takes a little while getting used to, but it works really well IMO.

totally agree with it! The way you move your viewpoint in Homeworld 2 is just prefect! easy to learn and very effective!

[mikker]

I've seen this type of control in Homeworld 2. It takes a little while getting used to, but it works really well IMO.

totally agree with it! The way you move your viewpoint in Homeworld 2 is just prefect! easy to learn and very effective!

never played it, but if its easy to learn, then we could use some of the concepts.

[Deimos]

The z plane should be done best with the most simple solution we can come up with. Whatever it is, it has to cout TU's in the same way as 'walking'.

I'd prefer a modifier key as its less likely the player would accidently (in the heat of battle) go into vertical mode. Another way would be to use a waypoint system (like the original blaster bombs used). Single click sets a waypoint. ALT as a modifier puts the cursor into vertical plane, again single click to set a waypoint. To make the unit move double click to execute. If the player makes a mistake then use SHIFT as a delete modifier. The path generator would then work out the most efficient path to the destination using all the waypoints.

Remember it isn't just flying units that will need to be controlled with vertical plane movement. Things like the blaster bomb trajectory will need to be factored in as well.

I suggest an overlay path line that the player chooses the destiniation. Most airborne action is going to take place in one action and will mostly be up down motion of the unit moving along the path (unless the player is sadistic and likes 'bouncing' his units around).

So taking Breunors' drawing as an example: Point A is the unit's starting point and Point B is the destination. The pink line would be the trajectory the unit would take but to get there the player first clicks to the destination on the ground and then ALT and moves the cursor 'up' and ALT clicks to place the waypoint. Double click will set the unit in motion and it travels the pink path.

Attached Files

•  post_43_1081188273.jpg   25.66K   8 downloads

[mikker]

alt button would work fine, but it might be harder to lern. But i can see the point, indeed.

[mamutas]

The pink line does not need to be straight - it could go around obstacles: above, below, right, left - assuming that there is a way from A to B.

[mikker]

The pink line does not need to be straight - it could go around obstacles: above, below, right, left -  assuming that there is a way from A to B.

and assuming that A to B takes <X ammount of TUs, where X is total of Soldier. What would happen if a player don't have enough TUs?

[Deimos]

I'd imagine the pathfinding algorithms would operate either in realtime or close to realtime and would calculate the TU's needed for the unit to get to the point before the player commits to an order. SO the player would see how many TU's they're spending and the actual path around obstacles before they actually send the unit on its orders.

That way if the player doesn't like the path they can use their own multiple waypoints to set the path they want the unit to take.

Sometimes I wish I knew how to program, then I could show what I meant

[red knight]

I dont think there would be much of a problem for that... all games do that now in realtime.

Greetings
Red Knight

[Robo Dojo 58]

How will TUs be calculated for moving? Since movment will not be based on tiles, an agent will be able to move by fractions of a TU. Will this be kept track of, away from the player's point of view? Or, will movement have TU costs rounded up/down? Will TUs amounts be scaled up to account for the finer precision?

[Deimos]

IIRC 1 metre in the game equates to 1 TU. I don't know but for simplicity's sake I think we should stay away from fractionising (is that even a word ) TU's. Maybe rounding every action up to the nearest TU would be easiest. But for actions like firing and reloading, they'll all be set values anyway, so the only thing we have to worry about is the movement.

[centurion]

With rounding up there is a problem if you try to fine position somebody (sniper near a building edge, to shoot in a narrow opening, etc), then TUs would melt away real fast. If we used floating point TUs, the only problems would be showing the player how many are left and not staying close to the inspiration's idea. A TU bar could be something to consider, with a part greyed out or whatever for reserved actions and also showing remaining TUs if the player used the currently active path. Vertical 'milestone' lines like in the original (a bar for each increase by 10 in value) could give the user an idea of how much TUs (or stamina, for that matter) is there; maybe a more-or-less precise value could be displayed on the mouse hovering over the bar?

[j'ordos]

I thought one square in the game was one metre, and advancing one (clear!) square used up 4 TU's, so it's more like 25cm/TU

[Breunor]

Correct j'ordos, 4 TUs per meter of movement, and if memory serves it's 1 TU for every 90 degrees of turning. The last I heard, if you used part of a TU (turning 110 degrees for example), the remainder is saved until the turn ends. So you could turn a bit, move a bit, turn some more, etc. A display/text field would show how much remains, rounding the amount to something like 1 decimal place just for display purposes. Keeping track of remaining TUs should be an easy use of a variable for each soldier.

Regarding the 'forward then up' system for positioning a flying unit, the issue I see is when you want to fly above an object you can't go into like a hill. If you move the cursor out, it goes into the hill before you elevate the cursor, so the cursor placement system needs collision detection as well, and would move the cursor and/or its path over and around items as you move the cursor around the screen.

The idea of the mouse wheel/double click and drag would work for elevation changes, you move the cursor where you want the soldier to go and then click-drag to elevate.