turn based games

[K4Z]

The models are fairly low poly, I can always lower the poly count if need be. Gimme an hour and I'll post more pics.

About the code, you could maybe start with some improvements to the GUI, if you understood how it works.
I'll find you something to do

I've gone through the code several times, and I understand most of it pretty well now. There's not too much to improve though, I'll wait for your update.

[K4Z]

The swords are about 40-50 polys, but the bows are about 200 polys though, I think I'll cut 'em down a bit :lol: .

Here's a quick render of the warrior holding a sword and a bow, just to see if it fits ok.

[{MSX}]

The swords are about 40-50 polys, but the bows are about 200 polys though, I think I'll cut 'em down a bit :lol: .

Here's a quick render of the warrior holding a sword and a bow, just to see if it fits ok.

It looks nice indeed!

Here's some screenshots too
I've made some interface prototypes.

The login screen:


and the main screen:


Of course there's nothing definitive here, but it's kind of what i'd like it to be.
If you look at the main interface, you'll see that the functionality are on the right buttons. I'd like that selecting a button will change the main content to the relevant part (for example, the chat part is currently shown).
In this case, what is needed is some kind of "multi layer" widget that can show different contents. The whole should work much like a "notebook" component.
If you want, you could start making this widget
Here's some guidelines, in the case you're interested.
[size=7px]
You should derive TUiLayered from TUiContainer, so that each children of TUiLayered are TUiContainer, each representing a "layer" (or a page as in a notebook). A property "ActiveLayer" should point to the currently active layer (by index). It should be obviously changeable. The DoMouse* procedure should be overridden to only send events to the active child. The WidgetByPos should also be changed the same way.
You can override the Add method to raise an error if the passed widget is not (exacly) a TUiContainer (to avoid mess ).
The guidrawerunit should not need modifications.
You can put the code on a separate unit if you prefer.
[/size]
The latest version of guiunit is here. Download it before coding

Of course feedback on the screenshots (and on the code too ) is welcome

Ah, here's the login screen with an alternative style :mrgreen:

[WILL]

Wow, nice GUI. Is that Final Fantasy wallpaper?

I think the coloring for the first style is nicer, not so nice for the 2nd (No pink! ). You gotta keep that cursor, it's just too cool.

[K4Z]

One small thing I was thinking of adding to the GUI were Visible and Enabled properties.

The big and little chat TUiEdit's, would be a child of a TUiWindow. Same set up for the Buy,Sell, etc. Then simply, when you click on Buy, it would just change the visibility of the Chat window to false, and show the Buy window. So your just showing and hiding Windows.

(A visibility of false would also make it disabled)

...If that all makes sense.

But yeah, I understand what your saying, some sort of multi layered window, or panel, like a TNotebook component.

The interface graphics look cool, perhaps creating multiple GUI styles, or skins, that the user can change between.

I goto catch up on some study today, but I'll try and get a start on a Notebook style widget.

[cairnswm]

I'll get started on some networking stuff soon. I currently have two components ready - both TCP based (Indy TCP Client/Server, and SDL_Net TCP).

Doing development on my Dogfight entry I found that my game loop never gave the indy threads time to recieve messages. Using SDL_Net the recieving of messages happens as part of the game loop and therefore works fine.

[{MSX}]

One small thing I was thinking of adding to the GUI were Visible and Enabled properties.

The big and little chat TUiEdit's, would be a child of a TUiWindow. Same set up for the Buy,Sell, etc. Then simply, when you click on Buy, it would just change the visibility of the Chat window to false, and show the Buy window. So your just showing and hiding Windows.

(A visibility of false would also make it disabled)

...If that all makes sense.

Yes, that's a solution too, but i think it's harder to implement than a simple layered widget.
Also, i think the controls shoud stay on the desktop as in the shots, not in windows (as you stated above), since windows are draggable around and that's not what player probably want. Maybe you meant TUiContainer ?
Effectively, a Visible attribute could be useful in future too.. It just take some work to adjust event dispatcher methods..
An enabled attribute also could be useful in future, effectively. We can't say how complex our gui will be (for example the market or army manadgement section), there can be the need for a disabled button

Umm maybe you're right, we could eventually add this two attribute and forget the layered component.

For cairnswm: ok, i'll take a look on how SDL_Net works. If it's TCP it should be good.

[cairnswm]

I have classes already to manage both the server and the clients. I will send them to you later. (They are in my Run-A-War source file anyway)

[K4Z]

Yeah I kinda ment TUiContainer, or a modified window without drag, mabye like a TPanel or something. So you can just change the visiblity of the panels to quickly show and hide multiple components. That probably would of been easier to make, but I've already started on a TUiLayered widget. I've tried to keep all other units unchanged, But I think I'll have to slightly modify the DrawWidget function, since it wants to draw the button graphics where the TUiLayered is (Wants to draw it as a TUiContainer). Which I think the TUiLayered widget should been unseen, only it's children should be drawn.

Another thing that should be added, is to give the widgets a Name property. This would make it easier to identify a specific widget. To make it easier to change the properties after the widget is created and initially set up. Basically creating a GetWidgetByName function to easily find, and modify a required widget.
eg something like: GetWidgetByName('ButtonOne').visible := false;

The TUiLayered component is about 80% done, should be finished by tomorrow. Might even start on a TCheckBox type component next.

I'm off to bed now.

Welcome back to the thread cairnswm , just had a quick game of Run-A-War, very nice!

[{MSX}]

Yeah I kinda ment TUiContainer, or a modified window without drag, mabye like a TPanel or something. So you can just change the visiblity of the panels to quickly show and hide multiple components. That probably would of been easier to make, but I've already started on a TUiLayered widget. I've tried to keep all other units unchanged, But I think I'll have to slightly modify the DrawWidget function, since it wants to draw the button graphics where the TUiLayered is (Wants to draw it as a TUiContainer). Which I think the TUiLayered widget should been unseen, only it's children should be drawn.

You're right.

Also, i'm not sure that the drawgui is a nice way of dealing with drawing.

The problem is: i definely want to keep logic and drawing separated.
The two ways of doing so are: create a separated drawing facility (like it is now) and create widgets with abstract "draw" method, that will be derived in graphic-specific classes (implementing the draw).
I've used this second option in my engine (if you look for the TMesh and TGlMesh classes on MeshUnit and GlMeshUnit you can take a look).
Now i'm not so sure that the drawgui system is the right way..

What do you think K4Z ? Maybe deriving each widget would be better instead.

Another thing that should be added, is to give the widgets a Name property. This would make it easier to identify a specific widget. To make it easier to change the properties after the widget is created and initially set up. Basically creating a GetWidgetByName function to easily find, and modify a required widget.
eg something like: GetWidgetByName('ButtonOne').visible := false;

The TUiLayered component is about 80% done, should be finished by tomorrow. Might even start on a TCheckBox type component next.

Ok Only, we should decide about the drawing (as i wrote above), to avoid correcting a great number of widgets :mrgreen:
Feel free to add the Name property (it should be little work, shouldn't it?) and also the Visible and Enabled.
Of course do what you feel Just tell me when you're done so that i can work on it again (a manual CVS )

Well even if we don't finish the game, we will still be releasing a nice open source gui system

Welcome back to the thread cairnswm , just had a quick game of Run-A-War, very nice!

Yes, that was nice
I looked your code for runawar, i just didn't get some things:
- to receive something you have to call the Recieve method ? doesn't this block the game ?
- do you use fixed size messages ?

For the rest, it should do the work for us. I'll check if it compiles in linux (probably need only little fixes).

Ah, what licence does your code has ? Mine is GPL, and so i'd like this turn based game to be

Bye