Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

170 Neutral

About iceman76

  • Rank
  1. iceman76

    Fully asynchronous gameplay examples

    Yeah, I liked the idea of a virus because it fits so well thematically with "infecting" 3DS's you pass by, but, like you said, it could fit so well to make people worried it's actually happening =P   I was thinking of the game being competitive for 2 main reasons- first of all, it helps slow down the exponential spread of the virus (or whatever is being passed).  A 3ds would only be able to be infected by one virus, any new viruses would have to defeat that virus in order to infect the 3DS.  The second reason is similar; a player would feel MUCH prouder of seeing a heatmap showing their "virus" is on 3DS's across the world if they knew it was because their "virus" was better than every one of those 3DSs', rather than just being the natural result of spreading over time. (I'm a bit tired right now, so I'm not sure how much sense those sentences make- If you don't understand something, feel free to ask)   But yeah, you could make a cooperative game that uses streetpass to help and affect other people's games (similar to the built in streetpass games, but with more interaction between the player's games).  I just don't think it would be able to capture the "my creation is spreading over the entire globe!" feeling that I'd like the game to give.   Oh, and I'm still open to any examples of games that have the fully-asynchronous gameplayer, or something similar.
  2. JustinS, you seem to be getting angry at people for making suggestions when they could not know what the game you're making is.  Read your earlier posts- not once did you say this was a survival game, not once did you say this wasn't a war game, not once did you state there were no enemy troops (the closest was that there are non-humanoid enemies such as dogs).  ALL that we knew before this post was that A. It was a cooperative shooter that B. had a heavy focus on realism.  Most of the feedback they gave was the best they could've given based on what they knew- don't expect them to read your mind and understand exactly what you want.
  3. I was thinking about the 3DS's puzzle swap and how cool would it be to give only 1 person a certain piece, and then track the spread of that piece over time.  Naturally, I started thinking about how awesome it would be for a player to watch something they designed spread over the world, and I wondered what sort of game would be able to do that.  The best idea I had is spreading a virus, either computer or biological, through every streetpass.   That brings me to actually designing the gameplay.  Because the game needs to resolve who wins and infects the other player's 3DS within a single streetpass, a player's role in the game is limited to preparing their defense and offense (somehow), but they can't influence the result beyond that (this is what I am referring to as fully asynchronous gameplay- let me know if there's another name for it.)   I can't think of any other games that have this type of gameplay, but can you think of a game that had it (or something similar), and what they did well/poorly?   The closest games I can think of are the multiplayer tower defense games, where a lot of the work is done between rounds to choose which units to send and which towers to build.  Other games with similarities are CCG's, where a large part of the game is how well you build your deck.  The problem there is that watching two AI play your deck isn't going to be very engaging.  A last type of game that I can think of are those like The Castle Doctrine/The Might Quest for Epic Loot, where you build up defenses and then have no further say in what they do.  These games (especially TCD) offer the rewarding type of defense building that I'd like, but their "offense" relies entirely on player input.  
  4. iceman76

    Oculus Rift and Super Resolution

    He's commenting on an effect that he's noticed with the Rift, and wants to know other people's experiences/thoughts on it.   Basically, think of looking through a screen or fence slats- if you're standing still, they block your vision and you can only see part of whats past them.  If you're moving, though, they basically disappear, because your mind pieces together what you're seeing to form a complete image of whats behind the fence/screen.   He's noticed a similar effect with the Rift.  The game world seems to be at a much higher resolution than it actually is, because the brain is piecing together all the pixelated images (that are slightly different because the head is moving, however subtly) to form a near-perfect, "complete" image of the game world that is at a "super-resolution".  However, aspects like UI that are stuck to one point in the screen can't be improved by this effect, so UI text was almost impossible to read.   I don't have a Rift, so I can't comment on whether or not this happens to me.  However, if this is generally the case, it does offer a way to improve VR UI.  I know people are saying to have stuff like ammo count and health bar as part of the world, but if you did want it as floating UI for whatever reason, it'd be best to still have it fixed (more or less) in world, so that the brain can piece a better image of it together.
  5. iceman76

    Old Keyboard State in Input Handler

    Oh, don't worry, I am most certainly going to fix that.  I was just joking about the same thing Buckeye said, actually- calling it a feature when it is so obviously a bug.  Sorry that I wasn't clear.  Also, this isn't something I'm planning on distributing, this is just me learning how to use SDL2 in the first place.
  6. iceman76

    Old Keyboard State in Input Handler

    Haegarr, you're right- the problem was that I was accidentally calling SDL_PumpEvents.  Right before I check for the input in main program, there's this little snippet to exit when the user presses X: //Handle events on the queue while( SDL_PollEvent( &e ) != 0 ){ //User requests quit if( e.type == SDL_QUIT ){ quit = true; } } I read online several times that SDL_PollEvent calls SDL_PumpEvents internally, but it completely slipped my mind!  Serves me right for purposefully ignoring this from the FAQ:   Anyways, commenting out the above lines worked, so I can detect keyPressed and keyReleased to my heart's content!  Of course, that means that you can't quit my program without resorting to the Windows Task Manager, but that's a feature, right? =P  I've also changed the delete to delete[]   Thanks to everybody for helping me figure this out!
  7. iceman76

    Old Keyboard State in Input Handler

    Yes, the keyboardNew buffer is definitely being updated correctly.  Like you said, SDL_PumpEvents updates the buffer that it's pointing at.   I just tried copying the values with the for loop, and the result is the same.     I haven't set up anything with multi-threading myself, so I don't think this should be an issue (unless SDL automatically does threading).
  8. I've been working on an input handler, using SDL2 and C++.  Right now I'm testing it with a Pong clone, but I want to be able to use it my next games.  Right now it detects if a key is currently down or not, but I start running into issues when I try to see if a key was pressed or released that frame.   I'm using two arrays, one for the current state and another for the state the previous frame.  Every update, I use memcpy to copy the new state to the old state, and then use SDL_PumpEvents to update the current array.   The issue is that this actually isn't keeping an array of the old keyboard state.  Instead, the old and new arrays are always the same, so the keys are never able to be tagged as "pressed" or "released". (I did some debugging and can confirm that keyboardOld is changing)  I'm sure this is an issue with memcpy and constant pointers and all of that fun stuff, I just don't have enough experience with them to figure out what's going wrong.   So, why are keyboardOld and keyboardNew always the same, even though I copy New to Old before updating New, and how can I fix it?  Thanks in advance!   Here's the code: Input.h #ifndef Input_h #define Input_h #include <SDL.h> #include <cstring> #include <stdio.h> class Input{ public: enum keys{ A = SDL_SCANCODE_A, B = SDL_SCANCODE_B, C = SDL_SCANCODE_C, D = SDL_SCANCODE_D, E = SDL_SCANCODE_E, F = SDL_SCANCODE_F, G = SDL_SCANCODE_G, H = SDL_SCANCODE_H, I = SDL_SCANCODE_I, J = SDL_SCANCODE_J, K = SDL_SCANCODE_K, L = SDL_SCANCODE_L, M = SDL_SCANCODE_M, N = SDL_SCANCODE_N, O = SDL_SCANCODE_O, P = SDL_SCANCODE_P, Q = SDL_SCANCODE_Q, R = SDL_SCANCODE_R, S = SDL_SCANCODE_S, T = SDL_SCANCODE_T, U = SDL_SCANCODE_U, V = SDL_SCANCODE_V, W = SDL_SCANCODE_W, X = SDL_SCANCODE_X, Y = SDL_SCANCODE_Y, Z = SDL_SCANCODE_Z, UP = SDL_SCANCODE_UP, DOWN = SDL_SCANCODE_DOWN, LEFT = SDL_SCANCODE_LEFT, RIGHT = SDL_SCANCODE_RIGHT, }; void init(); void update(); void close(); //True if a key is pressed bool keyDown(int key); //True if the key was pressed this frame bool keyPressed(int key); //True if the key was released this frame bool keyReleased(int key); private: //Length of keyboard arrays (given by SDL_getKeyboardState) int length; //State of keyboard last frame Uint8* keyboardOld; //State of keyboard this frame const Uint8* keyboardNew; }; #endif Input.cpp #include "Input.h" void Input::init(){ keyboardNew = SDL_GetKeyboardState(&length); keyboardOld = new Uint8[length]; } void Input::update(){ std::memcpy(keyboardOld, keyboardNew, length); SDL_PumpEvents(); } void Input::close(){ delete keyboardOld; keyboardOld = nullptr; } //Returns true if the key is currently pressed bool Input::keyDown(int key){ return keyboardNew[key]; } //Returns true if the key was pressed this frame bool Input::keyPressed(int key){ return (keyboardNew[key] && !keyboardOld[key]); } //Returns true if the key was released this frame bool Input::keyReleased(int key){ return (!keyboardNew[key] && keyboardOld[key]); } And the relevant code from the main program: //Handle player input input.update(); if(input.keyPressed(input.UP)){ player->y -=50; } if(input.keyReleased(input.UP)){ player->y -=50; } if(input.keyDown(input.DOWN)){ player->y +=1; } if(input.keyDown(input.LEFT)){ player->x -=1; } if(input.keyDown(input.RIGHT)){ player->x +=1; }
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!