Jump to content

  • Log In with Google      Sign In   
  • Create Account


Krohm

Member Since 27 Aug 2002
Offline Last Active Jul 24 2014 12:50 PM
****-

Posts I've Made

In Topic: In need of some architecture help

21 July 2014 - 02:28 AM


I might have missed something in there, but it seems to only really be useful on window creation, but doesn't really provide anything useful if I want to resize or move the window mid-session does it?
What it gives you is the ability to pass there a pointer to an object you can use to interface with your "real" object so even though the WndProc is static, it can forward calls to non-static functions through a object pointer.

In Topic: Choice in Games

20 July 2014 - 11:44 PM


He justifies his case by saying he believes video games are all about empowering the player and the more choice the better. He also says it would add longevity to the game by adding more varied gameplay, though as I stated before I think it would be over-complicating what was supposed to be a fairly simple and straightforward game. What do you think? Do you think that empowering the player with more choice over their game is worth making things more complicated than they should be, and even risking being over-complicated?
I had a similar problem with the edutainment tower defense game I was working on some months ago. By the time I hit the second milestone, I had ... some bad feelings about it.

 

Similarly as you, I considered adding multiple layers of complexity to let the game last longer. I decided to halt the project for a bit so I could re-read the GDD and elaborate it a bit. I still had a bad feeling. I left the project alone for a month so I could detach from it.

 
The core target was kids, 5-8 years old. Keep this in mind. After taking an "external" stance on the project I've come to the realization the project was too complex for the target demographic. There were really 4 different mechanics at work. I've decided to remove some and simplify the remaining ones. I think I will reintroduce them at next product iteration.
 
What I found is that those extra complexities really added a lot of time and effort to the testing and design. Without exploring the possibilities of the true core mechanics which survived it was difficult to asses what the extra rules given or taken.
 
So, I'd suggest to keep it simple because you really cannot figure out how the characters abilities affect the game - not in theory but the finished product - without having an accurate idea of what you need. Perhaps push those features to a following iteration.

In Topic: C++ avoiding pointers

20 July 2014 - 11:30 PM


The real proper use of these are all based on _lifetimes_. Who is responsible for creating the object? Who is responsible for destroying? Are users of the object just borrowing it for a while or do they need to take over responsibility of the lifetime? If they're just borrowing the object, how long do they need to borrow it for?
Quoted for emphasis.

I honestly find given proper design thinking about ownerships and lifetimes beats smart pointers at large.


In Topic: In need of some architecture help

20 July 2014 - 11:21 PM

On creation, the window gets its messages in a well defined order. In particular, CreateWindowEx allows you to fetch an LPARAM to the WM_CREATE message. Pack there a pointer to your struct. You can also do something similar on the window class but I'd consider it a bit ugly.


In Topic: The next step?

20 July 2014 - 11:16 PM

I'm afraid you have to begin considering engineering your code. You have probably just wrote your game code so far. Now the next step is to make sure the code can scale. Engineering it to be "better fitting" your head is a thing. The other way is to reduce the code size.

It's not this XOR that. You have to acquire both tools. 

 

How are you with data-driven systems? Is that term new to you?

 

Writing your code to be data-driven means writing your code to be flexible, ultimately reducing the amount of code. It takes some more effort but scales up better. That's why you see so many people writing about "engines" in those forums. "Engines" are data-driven frameworks in the end.

 

Now, without going to that degree, what you need to find is a way so you code less and artwork more. Is that a verb? :P


PARTNERS