• 9
• 9
• 11
• 12
• 9
• ### Similar Content

• Hi!
We're currently two programmers and a game designer working on a turn-based tactics fantasy board game. For reference you can search for images of "Tactics Arena Online", a fairly dated game that used to have a lot of depth and complexity.
Our goal is to use the same combat concepts, but giving it a much needed modern touch as well as a whole new set of heroes to choose from with additional abilities. The game is a mix of isometric and 3D and we plan to release the game on Steam and hopefully Android & iOS as well.
We are looking for someone to work with us pro-bono (just like we're doing) as a 3D character artist. The skills needed are creativity, a hard working attitude and an ability to make minor animations (things like idle, walk, block and very rudimentary attack animations). A perk to have would be the ability to make some VFX. If the game makes it on steam and money starts coming in, you'd obviously be compensated for your hard work, but as it stands this is a hobby project to garnish your portfolio.
A bit more about the game:
This game will be an online multiplayer game where each user gets to pick up to 10 characters to place on his half of the board (this would be done before even entering matchmaking. Think runes in League of Legends for example). The user can place his 10 units of choice anywhere he likes on his half board. Some units can be used more than once. So if you want 4 knights and 2 mages or even if you want 10 clerics, you can do as you please. You can then save your setups for future use. The goal of the game is to wipe out the enemy team.
Each character or Hero (except premium and abyss characters) start with 1 ability and they can ascend (either by playing a certain amount of matches with the character or by forcing the ascension with real money) to gain a new ability or passive. Acquiring a new character can be done by using in-game currency that you earn from playing matches or using real money with the exception of Abyss characters which can only be acquired by winning certain rare matches. The goal is to offer a freemium game with lots of customizable elements while making sure that no user can "buy power" with real money. We want everything that a paying user can get to be available to non-paying users who play the game a lot.
Ultimately we want this to become a competitive game that people can enjoy and really get invested in. Each character is designed with options for counterplay in mind and synergy with other heroes.

We sincerely believe in what this game can become and we home to find someone just as passionate as we are to get involved in this project!

•    Hello , i would like to showcase my first game project, a simple endless casual arcade game called Apples Mania : Apple Catcher. The game has simple goal , scoring as high as possible by collecting falling apples while the difficulty gradually increases. Different apples are worth different amount of points and there are also 2 power-ups to help you in your challenge.
The game took me about 2 months to complete and polish and i made everything except for the music tracks and some of the sound files. Made in unity and blender3d.
Would appreciate any kind of feedback.

A trailer showing basic game-play:

• By Paszq
Troglodytes are a playable races in Arpago - they usually don't talk much and most of them lives near water sources.
• By Paszq
a Fox in a dungeon :)
• By Paszq
Fox Folk is one of 3 playable races in Arpago.

# Unity Revisiting Win32 wrappers

This topic is 3570 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

After reading this Win32 related thread I was about to post a reply but then decided it would be better suited as a new thread to avoid hijacking the topic there. So here it is: It's a rather old concept now but I've begun thinking a little into this sort of thing again recently. Having looked at a few existing Win32 wrappers in C++, like Evil Steve's (from the other thread) as just one example of them, some things from most of these designs stand out to me generally:
• People have a static routing wnd-proc as opposed to using a free function, I don't see why, it's perhaps just "over OO-ism"?
• People register a new window class at the same as creating a new window, seems like Microsoft intended window classes to be reused between different windows yet that rarely seems to be supported by the design.
• People give each new window class the same name - problematic? Perhaps not if Windows doesn't re-register the window class, but strikes me as a design smell anyway.
• People have separate create/destroy functions from the constructors/destructors. If the class is meant to represent a win32 window then surely these things should be in the ctors/dtors? Otherwise, if the class is meant to represent a win32 window handle, then surely the handle shouldn't be the one creating and destroying windows?
• There aren't always satisfactory examples of how people expect to use these classes in real applications - inherit from them for each window they want?
So, I wish my question was "What actually is the best way to go about this... really?" - but that's obviously subjective. I was doing some thinking whilst typing the above and I thought upon this:
• A WindowFactory registers a WNDCLASSEX and can return Window objects associated with that window class and thus its wnd-proc. This allows sharing of the window class. I'm wondering whether this factory can be specialised to, for example, create windows for a given D3D device or OGL context? Basically anything that is sharable among windows at construction time?
• A Window is a thin, auto_ptr style, wrapper around a HWND to support some RAII.
• A Window needs to be convertible to a HWND so it can be passed to OGL/D3D/Win32/etc functions, but that's safe as far as I can think(?).
• A Window object must not survive longer than the WindowFactory that created it in order not to out-live its WNDCLASSEX - that doesn't seem too evil, somewhat like an iterator must not survive longer than the container it's referencing.
• The default wnd-proc would probably be like the static ones you see in other designs (except not a static function) but it wouldn't dispatch to the Window rather to an EventHandler that can be implemented in whatever way the client wants.
I think that is perhaps a better design than before, though still not ideal. It's certainly an improvement over my last attempt at any Win32 stuff, which always seems to be the most brittle part of my initialisation code, although I don't find it too much of a problem in practice. So any thoughts, ideas, suggestions, critique or abuse? [smile] Or if anyone has anything they consider to be better?

##### Share on other sites
Quote:
 Original post by dmatterPeople have a static routing wnd-proc as opposed to using a free function, I don't see why, it's perhaps just "over OO-ism"?
By making the static window proc a static function, it can access private functions in the class. That allows the non-static window proc to be private.

Quote:
 Original post by dmatterPeople register a new window class at the same as creating a new window, seems like Microsoft intended window classes to be reused between different windows yet that rarely seems to be supported by the design.
A single window class is designed to cope with all windows that behave in the exact same way,. If you have E.g. 4 views in a model editing program that are 4 windows, then you'd probably use the same class. In a game, there's usually only one window, and if there's a different one, you'll usually want to use a different window proc for it - and that requires a different window class.

Quote:
 Original post by dmatterPeople give each new window class the same name - problematic? Perhaps not if Windows doesn't re-register the window class, but strikes me as a design smell anyway.
Window class names cannot clash in one process. I'm not sure what happens if you try to register two classes with the same name, I suspect the second will fail. If you have two EXEs though, you can have the same class name in each.

Quote:
 Original post by dmatterPeople have separate create/destroy functions from the constructors/destructors. If the class is meant to represent a win32 window then surely these things should be in the ctors/dtors? Otherwise, if the class is meant to represent a win32 window handle, then surely the handle shouldn't be the one creating and destroying windows?
True. I usually have a create and destroy function, it just allows me to clean up the window without deleting it. Admittedly I can't think of a time that I've needed to do this, but it's handy anyway. I suppose it's just a matter of choice.

Quote:
 Original post by dmatterThere aren't always satisfactory examples of how people expect to use these classes in real applications - inherit from them for each window they want?So, I wish my question was "What actually is the best way to go about this... really?" - but that's obviously subjective.
In my apps, I used to have the same window (C++) class and then inherit from it. The only thing that needed changed was that the non-static window proc became virtual. However, in most apps I write, I only need one window so I just put the functionality in the base class and don't bother with a derived class. It'd be trivial to use the former method though.

Quote:
 Original post by dmatterI was doing some thinking whilst typing the above and I thought upon this:A WindowFactory registers a WNDCLASSEX and can return Window objects associated with that window class and thus its wnd-proc. This allows sharing of the window class. I'm wondering whether this factory can be specialised to, for example, create windows for a given D3D device or OGL context? Basically anything that is sharable among windows at construction time?A Window is a thin, auto_ptr style, wrapper around a HWND to support some RAII.A Window needs to be convertible to a HWND so it can be passed to OGL/D3D/Win32/etc functions, but that's safe as far as I can think(?).A Window object must not survive longer than the WindowFactory that created it in order not to out-live its WNDCLASSEX - that doesn't seem too evil, somewhat like an iterator must not survive longer than the container it's referencing.The default wnd-proc would probably be like the static ones you see in other designs (except not a static function) but it wouldn't dispatch to the Window rather to an EventHandler that can be implemented in whatever way the client wants.I think that is perhaps a better design than before, though still not ideal.It's certainly an improvement over my last attempt at any Win32 stuff, which always seems to be the most brittle part of my initialisation code, although I don't find it too much of a problem in practice.So any thoughts, ideas, suggestions, critique or abuse? [smile]Or if anyone has anything they consider to be better?
To be honest, it all sounds a little over the top. When do you really need multiple window classes?

##### Share on other sites
Quote:
 Original post by dmatterA Window object must not survive longer than the WindowFactory that created it in order not to out-live its WNDCLASSEX - that doesn't seem too evil, somewhat like an iterator must not survive longer than the container it's referencing.So any thoughts, ideas, suggestions, critique or abuse? [smile]Or if anyone has anything they consider to be better?

Once you have registered your window class, the lifetime of the WNDCLASSEX is not relevant. For example, my class registering function uses a local variable WNDCLASSEX that is destroyed when the function returns.

int Register(HINSTANCE HIn){    WNDCLASSEX Wc;    Wc.cbSize=sizeof(WNDCLASSEX);    Wc.style=0;    Wc.lpfnWndProc=WndProc;    Wc.cbClsExtra=0;    Wc.cbWndExtra=0;    Wc.hInstance=HIn;    Wc.hIcon=LoadIcon(NULL,IDI_APPLICATION);    Wc.hCursor=LoadCursor(NULL,IDC_ARROW);    Wc.hbrBackground=(HBRUSH)GetStockObject(BLACK_BRUSH);    Wc.lpszMenuName=NULL;    Wc.lpszClassName="WhateverWin";    Wc.hIconSm=LoadIcon(NULL,IDI_APPLICATION);    return RegisterClassEx(&Wc);}

After that, the window class is accessible in CreateWindow* by its lpszClassName.

Not in anyway meant as a criticism of your ideas - just thought it might save you some work.

I agree with Steve that for a D3D/OGL game requiring a single window, there is far too much engineering going on here, but for a Win32 wrapper for writing windows apps (if anyone is still masochistic enough to do such a thing post-.NET), you raise some interesting points.

##### Share on other sites
Quote:
 Original post by Evil SteveBy making the static window proc a static function, it can access private functions in the class. That allows the non-static window proc to be private.
Ah good point, I'd overlooked that, and a private non-static window proc is usually better than a public one, so yes.

Quote:
 A single window class is designed to cope with all windows that behave in the exact same way,. If you have E.g. 4 views in a model editing program that are 4 windows, then you'd probably use the same class.
Yeah this is exactly the sort of thing I had in mind actually. If we said each such window is a "window view" then I'd have a factory for creating them:

WindowFactory windowViewFactory(/*params*/);

Quote:
 Window class names cannot clash in one process. I'm not sure what happens if you try to register two classes with the same name, I suspect the second will fail. If you have two EXEs though, you can have the same class name in each.
In your link, you create a window class with the same name each time. If you attempted to create two windows with your code then you would be registering a window class with the same name more than once. I'd think the same as you, that it would fail, but that the window would be created with the first registered window class - I don't really feel comfortable with the idea of failing registering overally.

Quote:
 To be honest, it all sounds a little over the top. When do you really need multiple window classes?
Well I'd need multiple window classes when I want a different type of window, for example an application window and a panel window in a model editing program. The panel window views could then have a shared window class. I can see the uses, but I can see your point to.

Some people make a window class per window, others have one window class for all of them - by introducing the window factory you get the flexibility of the middle ground but without the hassle of building icky win32 structures yourself.

Keep in mind that the factory is not just limited sharing window classes, there are other resources that can be more easily shared like brushes, toolbars, API contexts/devices and so on.

##### Share on other sites
Quote:
 Original post by EasilyConfusedOnce you have registered your window class, the lifetime of the WNDCLASSEX is not relevant. For example, my class registering function uses a local variable WNDCLASSEX that is destroyed when the function returns.

Ooh, I wasn't very clear at all about that.
I have in mind that the window factory would not only register the window class but also unregister it too, in it's destructor. If the factory is destructed then the window class is unregistered and pulled out from under the feet of any outstanding windows.

Quote:
 I agree with Steve that for a D3D/OGL game requiring a single window, there is far too much engineering going on here, but for a Win32 wrapper for writing windows apps (if anyone is still masochistic enough to do such a thing post-.NET), you raise some interesting points.

Yeah .Net is the way forward, but thinking more along the lines of properly abstracting the windowing code in general (so win32 or not) I think it is 'more correct' to use a factory here and not a fat do-it-all-in-one window class. I do still use some Win32 stuff though so I can at least stand to benefit; and the main reason I brought in OGL/D3D was to fire off peoples' synapses so they can see how it all fits in [smile]