Start menu progress

[Samapico]

tcsoccerman, I don't know if you started anything yet... but anyways, I almost have a functionnal skinnable menu interface... If you want to work on stuff, you could do the profile manager, key manager, macros... these kind of things.

 

I just need to find out how to draw stuff like a bitblt... Right now, as soon as the picturebox refreshes, I lose my image... grr...

 

I'm getting used to C# again by doing this, so once I'm mostly done I could help on the engine I guess... openGL sounds like fun

[»doc flabby]

I'd like to make a change to the current interface design. This shouldnt' interfere with what you are doing, if we do decide to run with it.

 

This is an idea for discussion really.

 

Bascially because in Continuum creating a profile and user. and logging into the game is counter intuative. Its confusing how you are meant to get started for a new user.

 

When you first start the game. I imagain it asking you to select a profile or create new profile, copy profile, your last profile being auto selected. (like in many, many other games).

 

On the create new user screen, it will then contact the main billing service, to work out if the name is free. (there will be an option to ignore this check) At this point we ask for optional demographics /email address (required for password reset)

 

You then press "next" and you enter the main skinned screen, like it is in continuum (ie List of zones) I'm proposing to remove ship selection from the main screen and do it in game. Bascially because there is going to be no limits on the number of types of ships a zone can have, its impossible to skin for it. Or maybe only display the first 8 ships. (pictures would be downloaded from the directory server) The zone could choose what ship people enter as.

[Samapico]

All the options selected should also depend on the profile, which isnt the case in continuum

 

and no it doesn't interfere with what I have so far at all, because nothing is fixed yet. At the moment, the default skin is defined at runtime with a few simple lines.

 

----How Skin works

 

A Skin is made of Hotspots and Bitmaps. A skin could use several different bitmaps. Kind of like the current skins, the bitmap(s) contain a variety of images, and some parts of them will be used for different purposes.

A Hotspot is some place on the menu where something happens. If a hotspot is named "Profiles", it would link to the profiles editor, for example.

 

Each Hotspot is made of Regions and MenuImages.

A single hotspot can have multiple regions. Regions can be rectangular or elliptic.

MenuImages define a part of one of the bitmap to use, and how to use it. For example, it could be: use the first bitmap of the skin, take a portion of it from X,Y of size WxH, and animate using a Fade when the mouse comes over it, but don't animate when the mouse leaves (i.e. disappear instantly).

When the mouse goes over one of the regions, the whole list of MenuImages is activated, some could be animated, some not.

 

What the Hotspot actually does when you click on it would depend on its name. So one could have 2 different hotspots for the same purpose without a problem.

 

----

 

That's pretty much how Skin works so far... with this we have pretty much infinite flexibility, me thinks. If anyone played FreeSpace 2, I think it would be possible to create a main menu similar to that, where everything moves and seems interactive. Should be also possible to have "ambiant" animations... would be cool.

 

FreeSpace 2 menu:

http://www.3dnews.ru/do!@#$%^&*ents/577/main_menu.jpg

When you go over the door that exits, for example, it opens, and closes when your cursor leaves.

 

 

Haven't thought much about it, but I'm guessing the skin file format will be similar to the .lvz format. Multiple files compressed, one of those files being a text file defining the order of the bitmap files, hotspot definitions, region definitions, menuImages definitions.

[tcsoccerman]

I've done a little research on interfaces and learned that theres two main interfaces.

 

Sequential Interface - Giving the user options one at a time. This is used when you need certain information first in order to complete certain tasks. I think this is what doc was talking about.

 

Event Driven - Most modern interface, used in most applications. You give the user many options (ex. - menuitems toolbar buttons) and execute code based on that event.

 

Now for my opinion: I'm not gonna lie, but i like doc's idea a lot more than sampapicos idea. First, it's what i imagined as well for the start up screen and that's how i started to make the start screen already. Second, the idea sampaico had i don't like in any application. It makes me feel limited to my options.

 

I'll get the basis of my idea implemented in my program and attach it in a few.

frontend.zip

Edited December 20, 2007 by tcsoccerman

[Smong]

How do you plan to store the user settings? cfg/conf? XML? Custom file format?

[tcsoccerman]

I vote for either xml or custom.

[»D1st0rt]

I'm a big fan of Nini for this sort of thing

 

Another option you have would be to create a configuration "object" and serialize it with DB4o

[Samapico]

I've done a little research on interfaces and learned that theres two main interfaces.

 

Sequential Interface - Giving the user options one at a time. This is used when you need certain information first in order to complete certain tasks. I think this is what doc was talking about.

 

Event Driven - Most modern interface, used in most applications. You give the user many options (ex. - menuitems toolbar buttons) and execute code based on that event.

 

Now for my opinion: I'm not gonna lie, but i like doc's idea a lot more than sampapicos idea. First, it's what i imagined as well for the start up screen and that's how i started to make the start screen already. Second, the idea sampaico had i don't like in any application. It makes me feel limited to my options.

 

I'll get the basis of my idea implemented in my program and attach it in a few.

There will be a sequential wizard to choose your profile / create a new profile -> choose main options. But after that, you're pretty much free to go. A 100% sequential menu has the disadvantage of being annoying when you want to go back changing something. Plus, you can't have EVERY option in the sequential wizard

 

Edit: I checked your program... the 2nd part whre the user selects ship and stuff would be the skinned part. It would be nice to include zones in there as well (All zones won't have the same ships necessarly, so you'll want to change available ships depending on the zone)

 

And in FreeSpace2, there's a tech room, where you can read all sorts of technical info on ships/species/stuff... Would be nice to have something like that, like fancy technical details about ships, and some sort of pseudo-storyline. Could have some info on "known systems" or something, which would be zones...

 

Actually, connecting zones together in a star map would be kind of cool... speaking of subspace, in FreeSpace, systems are connected together with subspace tunnels.

http://www.volition-inc.com/fs/downloads/fsnodemap.gif

 

...yeah, I love Freespace I don't want to copy all these ideas, but it could inspire some new ideas

[JoWie]

I think it would be very nice if entering a zone looked something like this from stargate:

 

yVUn_ws1bishttp://www.youtube.com/watch?v=yVUn_ws1bis

[Samapico]

lol, maybe a bit shorter... but yeah it's a nice effect

[Samapico]

Ok now...

 

how cool is that?

 

 

Fully skinable For now the default skin is generated at runtime, so there isn't any specs for the skin file format yet.

Now I have to be able to animate the pictures that appear in different ways (fading, toggling between multiple frames, on/off flash) with different delays

 

We don't see it on the screenshot, but each hotspot can have its own cursor too.

I was thinking to make the right-click access the menus... and.. well the default skin will have some kind of menus too I guess

 

Each image that appears can have transparency (for example, the black surrounding a part of an image will not be shown)

The transparency you set for your background image defines the shape of the window itself. You could make some images pop with that color to make holes or change the shape of your form.

 

The skin bitmap looks like:

http://subspace2.svn.sourceforge.net/viewv...bmp?revision=86

 

Skins can also use several bitmaps at once so you don't need to have one huge-!@#$%^&* bitmap

[rootbear75]

wtf were the pix for?

[Samapico]

The thing with SS2 you see there is actually a skin... it's the main menu. The window can have any shape with the transparency you give it. And I put some shapes in there to create hotspots that will eventually do something. When you hover over a hotspot, a defined set of images appear. For example, the yellow X you see appeared when I put the cursor over the red one underneath it.

 

I left the stuff around the form to show that it was transparent.

 

I'll try to get some basic animations to work, then I'll design a quick functionnal skin... cause... of course that skin doesn't do !@#$%^&* for now.

[rootbear75]

sort of like how the mini-player skin works for windows media player?

 

Edited January 2, 2008 by rootbear75

[Samapico]

Yeah, pretty much.

 

Basically, the appearance of the menus, !@#$%^&*le bar, and everything will be skinnable instead of only the inside of the window.

 

Also, having hotspots that do something very specific will be very easy. So it will be possible to have custom skins with any button/menus you want.

[tcsoccerman]

samapico what should i work on? I've added those classes...any ideas on profile/macro/keyconfig edit forms? Same hotspot idea?

[Samapico]

Well, for editing profile/keys/macros, we don't really need to skin that form. So something kind of like what Continuum currently has for that would work fine.

 

Kind of like we can switch macro sets ingame, we should be able to switch key configs too... mhm...

[Samapico]

Just made an ugly rip-off the classic menu... just to have something that looks better than the MSPaint-ish crap I attached earlier

[»doc flabby]

samapico what should i work on? I've added those classes...any ideas on profile/macro/keyconfig edit forms? Same hotspot idea?

Hey tc,

im going to have a look at all the code today or tomo and try and work out what everyones doing.

 

Key configuration is a good task to take. I want a method that has no limit on the number of weapons/ships/direction. Basically the zones will provide a map to the client, that will then be loaded in the key defs window, that will show what weapons, ships etc are advaiable. I still need to finalise how im going to design this, do you have any ideas. Basically when you download a zone for the first time, it gets a file from the server containing all the advailble ships (images for client) the weapons and control axies (ie 1d,2d,3d, mouse?) This will then determine the keydef map for the zone. The zone will provide a default keydefset with this file.

 

I was thinking of a file like this maybe, im not sure how to tackle it.

 

Is this even a good idea? Better way of acheiveing this?

 

Ship
 Image
 Attributes
   Weapon 
       Key
   Weapon
       Key
   Weapon
       Key
   Ability
       Key
   Ability
       Key
   Ability
      Key
 Movement
     Keys
     Mouse

 

I'm gonna have alook at all the code everyone written this weekend hopefully, see if i can integrate it into the trunk!

Edited January 2, 2008 by doc flabby

[Samapico]

Hmmm... if I want to handle multiple animations going on at once, I'll probably have to multi-thread. Gonna be fun

[rootbear75]

Hmmm... if I want to handle multiple animations going on at once, I'll probably have to multi-thread. Gonna be fun

ill look into multi threading (w/ java at least... told me he was using it ?).. might help sama out w/ some stuff

[»doc flabby]

Hmmm... if I want to handle multiple animations going on at once, I'll probably have to multi-thread. Gonna be fun

One thing to bear in mind is that only the thread that created the form is allowed to access the form controls.

(This is true in all windows programs - i think)

 

This can make things a little more tricky. I suggest looking into BeingInvoke

[Samapico]

ew... ok.

 

I'm not using java, but the examples I saw were in Java, and were exactly the same as C#

[Samapico]

From what I see here:

http://www.java2s.com/Code/CSharp/2D-Graph...nimateaball.htm

 

He calls the form's Invalidate() method from the thread... that's pretty much all I need too, there are not a single control on my form, it's all painted stuff.

[Samapico]

Wee, was able to see something animate...

But now I'm getting some conflicts between threads about objects that are already in use in another thread... bleh