Who's up for a group challenge?

The Partridge Family were neither partridges nor a family. Discuss.
albinopapa
Posts: 4190
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Who's up for a group challenge?

Post by albinopapa » November 22nd, 2013, 3:50 pm

Team project still being worked on. Cameron, Luis and myself are the only ones working on it right now, still plenty to do if anyone is interested. I know it's the holidays so progress is still going to be slow and many of us are going to be kind of busy. Anyway, for now I have removed the project from the first post, will upload a fresh copy after this weekend. Since I posted updated info, but didn't have a zip ready I just took it off.

Happy holidays everyone.

BTW, you can always get the latest version through the Git server Luis has setup.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

User avatar
thetoddfather
Posts: 338
Joined: October 1st, 2012, 9:53 pm
Location: Canada

Re: Who's up for a group challenge?

Post by thetoddfather » November 22nd, 2013, 6:54 pm

Lookin forward to seeing the new version :)

albinopapa
Posts: 4190
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Who's up for a group challenge?

Post by albinopapa » December 10th, 2013, 1:58 am

Full of bugs at the moment, the first level has been laid out and boss added.
Mouse control in menu screens, cursor will disappear when playing.

up/down/left/right or w/a/s/d to move
space to fire
Controller can be used X, Y axis for movement button 1 fires.

Known bugs:
Sometimes it takes a few clicks on the buttons to start the game or change menus. Luis has fixed this but hasn't uploaded yet.
Moving in negative directions (up/left) is faster than moving in positive directions (down/right) again Luis has fixed, but hasn't uploaded yet.
Upon closing there is an error, still looking into this one.

Boss doesn't die, player shield doesn't change colors as it depletes, the green and red rings at the boss are missile explostions you can't shoot them, Asteroids spawn randomly on screen (rare).

Let us know what how we're doing so far. As far as graphics go, we aren't to the point of "flashy" so please be patient. We are still trying to make the engine and as we go make it flexible so that we can scale it up when needed.
Attachments
Shooter.zip
(4.62 MiB) Downloaded 68 times
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Who's up for a group challenge?

Post by LuX » December 10th, 2013, 8:36 am

Maybe I should/could contribute to the project as well at some point. Anyway... Reading through some of the code I found some things strange. Like why have the input struct AND keyboard, when really only the keyboard is required. Maybe have a separate struct for the player that hold its position, hp, etc... Also missing the ESC as an exit button, at least for now when there is no pause menu. And instead of having the player fall back when you don't move, have him move forward at the camera speed ( which could be faster ).

Those are my thoughts so far. I don't know exactly how you were planning to structurise the project.
ʕ •ᴥ•ʔ

albinopapa
Posts: 4190
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Who's up for a group challenge?

Post by albinopapa » December 10th, 2013, 11:24 am

The input struct is there to keep some of the variables grouped together, like I told Luis it's more aesthetics than anything, instead of having a bunch of "loose variables" as chili said in a video or two. When I first started this project I thought I was going to be passing more data between functions so it would have been faster to pass the address of the struct if needed. This far into it I realize I'm not saving myself anything since I'm passing in individual values, and there aren't that many of them, and because of the way DInput handles the mouse that information has to be retained so the joystick info has to be zeroed each frame. It would probably be best to change them to individual data members at this point. Thank you for making me take a second look at them LuX.

As for the pause menu, I'm close to making it, though I've been wondering myself why I haven't done that already :).

As far as structure, I've sent chili a PM to see what his suggestion is and have let Cameron know that it may need to be restructured. My original thought and interpretation of how the code "should" be is making each class handle it's own "life span" and using Get functions so that Game can control the game based on the returned values of other classes, instead of passing a reference to D3DGraphics for instance to each class object that needs to be drawn or passing Keyboard and Joystick class references to player or Mouse class reference to all the separate Menu classes.

Think of the Game class as the central hub taking input from all the input devices, passing info back and forth between other unit classes and finally passing relevant data to the graphics and eventually audio classes for sure and maybe a network class. Hope this clears it up. If you weren't talking about code structure, then I may need a little more clarification.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Who's up for a group challenge?

Post by LuX » December 10th, 2013, 1:19 pm

Yea, that's what I meant. I still think the keyboard to individual booleans is a bit weird, since the updated keyboard was done exactly to avoid such a thing, but I understand what you mean. Since there are multiple inputs, another way would be to just make an extended keyboard that combines the two. For example:

Code: Select all

bool moveUp( )
{
   if( input == joystick )
   {
      return if_joystick_move_up_condition_met;
   }
   else
   {
      return ( key_up_pressed || key_w_pressed );
   }
}
Or if they have to be actual booleans, you could store them in the keyboard and update after updating DirectInput/Joystick. I just think that all "input" things belong to one input class, instead of spreading them to other classes, especially the main application class, which for me would only need to compose what need to be done, instead of actually holding much data. But I guess it isn't really a huge problem, nor does it really matter, that just pocked me in the eye a bit.
ʕ •ᴥ•ʔ

User avatar
chili
Site Admin
Posts: 3935
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Who's up for a group challenge?

Post by chili » December 14th, 2013, 8:44 am

I've taken a look at your guy's code at papa's request. I'm glad to see that this project is still alive and I'm looking forward to seeing it develop further.

I would just like to say that since this is a kind of practice project, you shouldn't be too worried about haveing the correct archietecture for you code (if there even is such a thing as a 'correct' archietecture), but just try stuff and and see what sticks. Every individual and every team has their own style and you need to find what works for you.

As for myself, I would say that the Game class has gotten a little to fat. The main idea of the game class is to contain the top level components of the game and maybe help them to interact with each other. If you were intending to follow strict object oriented programming paradigms, you should have each individual class as self-contained as possible and keep most of the code for working on the class objects inside the class.

If i were making a fairly complete game with levels and shit, I would have a class composition hierarchy as follows

Code: Select all

game
 keyboard
 mouse
 graphics
 top level screen state machine pointing to: (menu screens/game screen/end screen/pause screen)
input and subsystem objects would be passed to the screen state machine which would have a pointer to the current active screen object (all screen objects derive from a base class with the common interface). The game screen would then contain all the agents of the game (player, enemies, powerups etc) and they would all be passed the required subsytems when necessary (player would need keyboard for its update function, all would need gfx for drawing). In such a scenario, game itself would have very little code, most of the work being done in the active screen object. even in the active screen object, a lot of the work should be done in the objects which make it up.

Of course i'm just pulling this out of my ass, but that is how i would try and structure things. the details will vary as roadblocks are run into and need to be worked around. That being said, I see no need for you guys to rewrite the whole damn thing. I think you can get far enough with the general codebase you have now. It's a little top-heavy but hey, as long as it runs :P

P.s. about your question regarding the menu screens having a different method for clearing the screen than for the main game, I'm not sure what the problem is. Of course how you'll draw the screen is contingent on what state the game is in. You will need a check of the game state in one form or the other before you can draw the correct screen.

Well, that's my two yen. Let me know if there's anything else you want to ask or something more detailed you want me to ramble on about.
Chili

albinopapa
Posts: 4190
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Who's up for a group challenge?

Post by albinopapa » December 15th, 2013, 5:31 pm

Thanks for the time and clarification chili. I realize that using the word "correct" would be difficult to work with, but you handled it with elegance, hehe. You answered my question and gave me some idea of how to go about things in a more object oriented manner.

P.S. Your use of classes as state machines in the platformer is/was a pretty neat "trick". I knew there was a way to make things a little simpler.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

User avatar
chili
Site Admin
Posts: 3935
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Who's up for a group challenge?

Post by chili » December 16th, 2013, 3:47 am

Yeah, a class based state machine has advantages and disadvantages. I like the approach, but that doesn't mean that a switch-based state machine is 'bad' or anything. The main goal for this arc is to give examples to familiarize viewers with object-oriented programming beyond just the videos where I introduce the topics and to give practical examples on how to use object-oriented paradigms and constructs when making a game.

Keep us in loop with updates every now and then on how the project is going brah. ;)
Chili

User avatar
chili
Site Admin
Posts: 3935
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Who's up for a group challenge?

Post by chili » January 25th, 2014, 7:15 am

Hey guys, been quite on the western front for a while. How's tricks?

I have a question for anyone in the group. In the folder I found a text file with point data, maybe for a vector art object? I want to know what tool if any did you use to generate that data (or was it just hand input into the text file?)
Chili

Post Reply