| Issue 28: | Menue Design | |
| 2 people starred this issue and may be notified of changes. | Back to list |
We need to work out some new designs for the menu's. This will bring will allow us to come up with a feel for the entire games interface.
Apr 16, 2010
Project Member
#1
srpli...@gmail.com
Owner:
Lift_...@yahoo.com
Apr 19, 2010
Different style ideas: -LFO HUD style -Scub vision style -Gekko HUD style -High Altitude theme -Nature theme -LFO Laboratory theme That's all I've got for now.
Apr 24, 2010
I will come up with something this weekend Cerebrate.
May 10, 2010
ughhhh such a busy month!!! i made this las night. its got the very basic feel..there no bells and wistels know what i mean? like i didnt do any font selections or color n what not...dunno wanna add alot more to it when i get time. the basic idea is lfo selection screen, you scroll left and right till u get the one you want, click on it- it slides to the left the others disappear , and you get a bio screen with info on the mech and then you can go back or buy the lfo. we all sucked this month! sleepy, spelling bad..
May 10, 2010
(No comment was entered for this change.)
Labels:
-Milestone-May Milestone-June
May 10, 2010
I'd rather the pictures be in-game renders in the final version. It would aid immersion and would help us display LFOs that aren't in the anime (starter LFO, anyone?).
May 10, 2010
The only problem is I can't change lfo's on the fly in game cause of how my code works. So this menu will need to be in the main menu where you currently choose it.
May 10, 2010
This is a bit of a problem, that pretty much cuts out the whole purchasing new LFOs part of the game, is there anything you can do about it?
May 10, 2010
Yeah, hide the options in the menu until they're purchased, which is an in-game activity. You could RP it as taking your LFO back to the garage to switch it out/pick up your new one.
May 10, 2010
while thats a step in the right direction, best case scenario would be able to buy and select your LFO without leaving a server/
May 10, 2010
the code does something like this: Player is connected to server Player object is instantiated LFO model is instantiated based upon their preference Preference value is sent to everyone over the network, and is stored in the buffer for any players that connect after this player (so their model is correct). And this is the kicker where changing it gets hard: Upon model instantiation (for both the player and how you appear to other players), the code finds various "transforms" (game objects) in the model and uses those as reference points for mounting the board and guns. This code is not only executed on the player that just connected, but everyone else. Then guns and boards are instantiated and connected to their various found attachment points. If one deletes the lfo model (or eureka for that matter), the code starts throwing a hissy fit, because then it starts to attempt to find said bone in the model to keep things attached! Also the animation code will take a dump as it attempts to keep updating the main model that has now just disappeared. Synchronization is also an issue. Because now you've got to fill up your network buffer with even more shit of you changing your model. And changing your model would cause everyone each to need to change said model, and make sure they do it smoothly (all while having to deal with instantiations coming over the network from you, slightly delayed, attempting to spawn from things that don't currently exist) Basically: I could, but it would require a serious code revamp, possibly requiring me to rewrite not only the character instantiation, but a bunch of logic dealing with board/weapons over the network. And a lot of planning time to make it work well and avoid the network buffer issues.
May 10, 2010
in the end, i think that all that stuff your saying should be revamped, like you said it would need to be. i think it would be a better result down the track, as atm, it will either not be possible to do certain things, or to do them would break the flow/immersion of the game. also, i have an idea for the lfo selection screen, where they would be drawn artwork(either taken from the anime or drawn by one of us or something) but when you select it( before you go into the bio screen) that image would fade away and have a real time model of the lfo there, doing say an idle animation or something(standing still, or on a board flying towards you(without actually moving closer. this would also look cooler) now, i know this is all POSSIBLE, but will prob require alot of work on cer's part(this is why we should have more than 1 programmer, perhaps we could recruit some1 who has experience with unity or something?)
May 11, 2010
I agree with torchling. This is a huge problem that if we try to work around it will greatly effect our final product. It may sound like asking alot, but its something that simply has to be done. On the selection screen idea, that was something I was thinking about as well, but i decided against it in the end.
May 11, 2010
any particular reason as to why? i think we should have the realtime model of the lfo on the bio screen at least then. slowly turning or something like that just to show it off a bit. as you don't really get to see the lfo's(other than your own) all that much, at least not very close up anyway. would be nice to have it on the selection screen
May 11, 2010
I agree with using a model instead of art in the LFO screen for reasons already mentioned. I guess it would be a pain to have to repeatedly leave and rejoin the server in order to switch around your LFOs. Couldn't a special exception or instance be coded that would instruct the server to not attach those objects to the bones, or order said objects to simply remain at their last coordinates in space until the exception ends and the new LFO is in?
May 11, 2010
I think i decided against it because it sounded like alot of work torch. I never really got cerebrates input on it tho. I love the idea tho.
May 11, 2010
(No comment was entered for this change.)
Blockedon:
32
Nov 8, 2010
relates to issue 55.
Status:
Accepted
Labels: -Milestone-June Milestone-Release1.0 Component-UI Priority-Critical Blockedon: -32 |