Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411319 Posts in 69331 Topics- by 58384 Members - Latest Member: Winning_Phrog

April 03, 2024, 02:03:58 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
  Show Posts
Pages: 1 ... 13 14 [15] 16 17 18
281  Developer / Design / Re: A word for continuous movement angle based on camera angle. on: November 01, 2012, 01:59:02 PM
Ah, that makes more sense, but "lock on action" sounds too close to "lock-on action", a pair of common words in gaming and options menus that have nothing to do with what we want to communicate. So, how about, based on your wording:

Always move relative to camera
Lock movement relative to camera on action

Or maybe even

Lock movement relative to camera on initial movement

So that's six or eight words, which seems almost better suited for a short description, but I guess given the complexity of it, that might still be the best option.
282  Developer / Design / Re: Mid-game genre shift on: November 01, 2012, 01:53:08 PM
A new set of rules does sound like the truest definition. All the minigames I can think of are complete games in themselves, just smaller and contained within the larger game. It's cool if it uses the same mechanics, since it's less work for the developer and more consistency for the player, but it sounds like the definition of a minigame really is in the rules.
283  Developer / Design / Re: Mid-game genre shift on: October 31, 2012, 01:46:01 PM
Is that even a minigame then, or just exploration of a mechanic? I would almost consider that just a new level and part of the core gameplay. Then that asks I guess if it's core gameplay if it exists for a whole level, but never returns again.

EDIT: For example, Casino Sonic levels are very much like a minigame using core mechanics, but exist for a whole zone, only to never return again for the rest of the game.
284  Developer / Design / Re: A word for continuous movement angle based on camera angle. on: October 31, 2012, 01:42:56 PM
Not in the industry yet, fresh out of college with only one internship under my belt, but I have used Gamasutra a lot before, and that's pretty easy to find stuff with usually (will check it again now). GDC Vault, I have not tried before though, so I'll look into that. GameDev I usually use as forums for game programming tech support xD do they have good articles too?

It seems like relative, absolute, and lock are the key words that come to everyone's minds, so I guess I'll be going with those. Relative vs. Lock on Movement might work... under a category of Controls. So...

Controls: Relative (Recommended)

Controls: Lock on Movement

The word lock really does fit nicely there, any reason to not phrase it as this?

Thanks guys!
285  Developer / Design / Re: A word for continuous movement angle based on camera angle. on: October 30, 2012, 03:14:17 PM
Huh, alright. That is exactly what I'm talking about then. Sorry for the confusion.

Do you guys know if there are any phrases for the subject in general of controls and automatic cameras? I get a lot of research from random Google searches, but I'm not quite sure where I'd start if looking for official definitions like input lock. Searches for combinations of camera, "input lock", and video game are not returning much on Google.
286  Developer / Design / Re: Mid-game genre shift on: October 30, 2012, 12:24:40 PM
I'm curious about this idea #Sharp is mentioning, more like genre asides than genre shifts. My friend picked up Assassin's Creed 3 last night, and we ended up spending about fifteen minutes trying to figure out strategies for an 18th century board game halfway through the intro.

Basically, minigames are the ultimate aside genre shift, and good minigames can give game design some real spice.
287  Developer / Design / Re: A word for continuous movement angle based on camera angle. on: October 30, 2012, 12:19:42 PM
lol rivon. Sorry, but the entire point of the project is to try and challenge that. Nintendo's managed to do some pretty awesome stuff with cameras that automatically position themselves, and I'd like to get better at that myself since it's significantly more accessible to casual gamers, but barely anyone takes the time to do it.

Surprisingly also: my playtesting has found that only hardcore gamers like having your angle *not* change when the camera moves during movement. I've had more complaints about it than thanks for it, until I switch people over to what hardcore gamers view as the flawed system. It's very interesting.

Gimmy TILBERT, wouldn't that be for absolute vs relative movement again though, instead of this initial vs continuous relativity? Maybe I didn't explain it quite right (which is kind of the whole point of this thread I guess), but it's the idea that you will always move relative to the camera's angle initially, but if while moving the camera also moves, whether it updates your directions (continuous) so you have to change what angle you're pressing the joystick, or it does not (initial) so only your starting angle for that movement (so until you stop moving again) is used as the basis for your movement.

It's very similar to relative vs absolute, but it's more like relative vs last-starting-relative.
288  Developer / Design / Re: A word for continuous movement angle based on camera angle. on: October 29, 2012, 02:27:05 PM
Wilson Saunders, that's almost right, but both are relative. One is just continuously relative, while the other is only initially relative.

ThemsAllTook, you are probably right. An animation is a great idea, I'll keep that in mind for when I have more time on this for sure.

Looking for a half decent fix for IGF student atm. xD

Initially Relative Controls vs. Continuously Relative Controls though? There's almost something there... way vague though.
289  Developer / Design / A word for continuous movement angle based on camera angle. on: October 29, 2012, 01:11:59 PM
Hello again TIGSource! You're going to know my whole game before I post the demo at this rate, but as long as you guys have good ideas I'm going to keep asking my hardest questions. xD

Making a game with a 3rd person camera that will automatically change directions (hopefully not during challenges, working on that) to show the best angle for completing a challenge, I've found with playtesting that there are two types of players. Veteran gamers are very demanding, they want exactly what they're telling the the game and no mistakes from a change in camera angle, which is fine. My fix for this is that movement angle is based on the joystick angle when you start moving, so if the camera changes, your angle doesn't. Second are the newer players who have no idea what's going on when this happens. For them, it's much easier if the controls are continuously based on the camera angle, and left is always left, right is always right, etc.

I'm pretty happy with this, but I need to put a toggle in the options menu. I'm doing a big font by hand, and haven't made all the letters yet, so I want to make the shortest wording possible for this option. It will switch between "Easy" and "Pro" for whatever the option is called. I originally named it "Camera Controls" but that means control over the camera, not controls in relation to the camera. "Directional Controls" sounds vague and "Movement Controls" sounds weird. So, thoughts?

tl;dr: What's a two/three word phrasing for Controls Based on Camera Angle: Continuous/Initial Angle Only?
290  Developer / Design / Re: Good level design theory? on: October 24, 2012, 06:05:06 PM
I've read a bit of Game Feel, very good looking book, and I keep getting Theory of Fun recommended to me, so I'll point towards that one as well. Have not heard of the others, except maybe Art of Game Design, but honestly any book that *has* been recommended to me on Game Design so far has always been good and worth looking into.
291  Developer / Design / Re: Co-op and falling back on: October 24, 2012, 06:01:58 PM
Good responses on all fronts! Zenroth, though I'm sure Lost Vikings is fun, if the game is designed around multiplayer, that's more like L4D (as Danmark mentioned) and not what I'm aiming for.

Graham: the enemies thing is again returning to combat, which I want to avoid so I can focus on platforming itself, but the guides idea is perfect. Leaving stardust to autocorrect the next player's jumps sounds perfect, as it whittles away at the challenge of overcoming all the jumps (and whoever gets it first, the next player just follows in their path. No need to even draw attention to whether they actually needed it or not). Taking care of the jumps is exactly what I was looking for, and my second closest idea was having a collectathon filled level and simply asking players to work together to 100% it.

Danmark: great commentary on L4D, and very aware of the differences. The non-forced but helpful, and organic aspect, is what I'm looking for. My platformer is 3D and harkens back to the N64 when exploration was king, so non-linearity is a big part of it and why I want more freedom in the co-op, but still interesting advantages to working together. Boss battles would be good for bringing people to one cause, but other than that and jumping on each others' heads to cheat, I'm not really sure.

Wilson Saunders: Good insight into the current market, but I'd like to try and prove otherwise Wink And yes L4D has good co-op, but it's too forced compared to Halo (Halo 1 in particular)

forwardresent: The tethering is a good idea, but it would (like the NSMBWii bubble) make it really obvious when someone needed help. I'd love to make it less clear, and Halo did a great job of that by having some unknown number of enemies, and allowing you to fall back at any time. A silent and unknown assist, if you will.

So to clear things up a bit more: my Halo reference was very specific ;P I want that kind of freedom in exploration, and ability to *not* do co-op, but silently allow the other person to do more work than you just by "falling back". My game is as non-linear as BK or SM64, or I hope for it to be long term, and yet I'd love for the platforming to be the main mechanic rather than collecting or combat. It might be too dull to do that long term, but we'll see! Thank you all for the suggestions so far, I am always impressed by TIGSource's insight into game development Smiley
292  Developer / Design / Re: Methods for coming up with game ideas on: October 22, 2012, 09:09:38 PM
If you're really concerned about not even making something better than pong, copy what you know and what you like. Replicate that which you would like to make. Once you learn the basics of what you like, then you can move on to what's beyond that.

My first finished game was a life simulator ala Animal Crossing/Harvest Moon. It was mostly content based, and a 2D engine in GameMaker. It was probably my fiftieth GameMaker creation, and was a remake of a demo I once made which I was actually pretty happy with.

Making a finished game doesn't happen overnight, and if you really want to learn more about the breadth of making a variety of games than the process of making one game, I highly recommend starting with experiments and demos. Only move on to a full game if you love the idea so much that you would commit a year to it, or set your scope much lower than the average game (maybe target flash games?). If you can figure out what you love to make, you'll be happy making it even if you're only barely making a dent towards creating it. I've always wanted to make games, so even terrible demos made me happy since they were a step in the right direction, and now I'm here calling myself a game maker. Smiley
293  Developer / Design / Re: Pitch your game topic on: October 22, 2012, 09:00:35 PM
What about a Risk-like territory conquer/conflict game, where your armies are Scrabble-like words?

You're thinking of Quarrel! Really fun actually.

"Quarrel: Risk meets Scrabble on Xbox Live Arcade, and it works"
294  Developer / Design / Co-op and falling back on: October 22, 2012, 08:52:17 PM
As a preface: I played a lot of Halo 1 growing up. That single player campaign, with multiplayer, was everything I ever dreamed of on my N64. Being able to share the story together and take on the world with friends, that was awesome.

Now I'm hoping to bring that to other genres if I can, starting with the 3d platformer I'm working on right now. I have the splitscreen, the co-op, and even some explorable worlds in little bits. What I'm lacking however, is the sense of safety brought on by having a friend with you. In Halo, this is easy - fall back. Your friend can take on waves while you recover, it works out well. In platforming, when you fall, you're alone in it.

New Super Mario Bros Wii has a half decent fix for this, a bubble system lets you recover a bit slowly to wherever your friends are, safe until that point. In Ratchet and Clank All 4 One, the danger is mainly in enemies, so taking cover works just like it does in Halo (or, similarly, you're safe at least even if you don't have shields to recharge). Other enemy based semi-platformers like arcade beat em ups do this too.

My question is though, how can we create a sense of safety by passing things off to our friends (who may be more experienced) while focusing on platforming rather than enemies? Or is there even a way to do this? Donkey Kong Country Returns probably has the closest solution, similar to the original DKC's tag off co-op system, you can jump on the other player's back and let them control both of your movements for a while. But it's not as invisible as Halo's falling back, where you can just slowly let more of the weight onto the other player's shoulders without even telling them.

Anyways, thoughts on this? I always think it's interesting to remix and move around parts from different genres. For now, since my goals are all in high places, I just have a "jump on other player's head" feature so that everyone except the guy on the bottom can get a boost.
295  Player / General / Re: IGF Thread 2013 on: October 17, 2012, 11:30:04 PM
Heart still racing from realizing a bit too late that video and screenshots were required. Lucked out and got it all in on time, even with a PC that couldn't handle it (640x480 video ftw)!

$50k is a lot of money, but If 500 people enter again at ~$100 a piece, that's... $50,000. Oh, whoops. Must've been doing my math wrong >_> Wow! That's very impressive that it all goes back to the contestants then.
296  Developer / Technical / Re: Suggestions for improving OpenGL 3D framerate? on: October 16, 2012, 02:14:11 AM
Tommo, yes - one batch would be bad for changing things quickly, but this batch is unchanging for the length of the level. When the level ends, an entirely new batch is loaded, and the whole level changes. So for my purposes, it actually works out quite well Smiley
297  Developer / Technical / Re: Suggestions for improving OpenGL 3D framerate? on: October 14, 2012, 01:19:49 PM
Over the past few days, I've been moving everything over to a two draw call system (one for the bases of the cubes, one for the tops which are assigned different colors that can't share vectors with the bases) and now the whole game runs at 60fps, regardless of level, player count or size! Neighbors are still eliminated, and shadow volumes are also drawn with a similar system (so I guess I'm at three draw calls then) but boy, I wasn't expecting this.

The meshes and breaking it into chunks would definitely help, but I think that's a bit beyond my skill level right now. For a quick fix though, shoving it all into one or two draw calls really did the trick, so I highly recommend that for anyone else making... uh, 40 thousand draw calls a frame. xD

Thanks guys!
298  Developer / Technical / Suggestions for improving OpenGL 3D framerate? on: October 12, 2012, 05:36:40 PM
Hey TIGSource! I'm working on a graphics engine for my game that's Minecraft-like, so cubes. Cubes everywhere! I wanted to know if you guys had any tips, as I'm trying to draw what is probably forty thousand or so cubes per frame (ten thousand from four camera angles for splitscreen, 7k for the earth/ground and 3k for castle walls). Currently I'm using a neighbor system where if you have an adjacent cube on one side, that face does not get drawn. There are two parts, and this is all with OpenGL (no GLSL yet)...

One: the code that calls the cube draw.

Code:
void drawCube(int n, int player) {
  // ALWAYS start by setting relations to cam
  // lets you skip drawing faces on opposite side from you
  cubeShape[n].setRelationToCam(
    cubeX[n]-cameraPointer[player]->getMeanX()>0,
    cubeY[n]-cameraPointer[player]->getMeanY()>0,
    cubeZ[n]-cameraPointer[player]->getMeanZ()>0
    );
  
  glPushMatrix();

  // Position cube
  glTranslated(cubeX[n], cubeY[n], cubeZ[n]);
  
  // And make cube bigger
  glScaled(100,100,100);

  cubeShape[n].draw();

  glPopMatrix();
}

setRelationToCam updates variables that will tell which faces aren't visible from your position, since all cubes are unmoving and don't rotate. The camera's means are just an average of its position, for smoothing. Then the custom draw command is below...

Two: the cubeshape draw itself.

Code:
void CubeShape::draw() {
  
  // Did not want to have to make an array every draw,
  // but otherwise all the arrays meld into one,
  // and all turn the last color submitted -
  // red for the goal. So here we are!
  GLfloat newColors[] = { r1, g1, b1, // front top left
                        r1, g1, b1, // front top right
                        r2, g2, b2, // front bottom left
                        r2, g2, b2, // front bottom right
                        r1, g1, b1, // back top left
                        r1, g1, b1, // back top right
                        r2, g2, b2, // back bottom left
                        r2, g2, b2  // back bottom right
                      };

  // These code blocks modified from work on songho.ca
  glEnableClientState(GL_COLOR_ARRAY);
  // activate and specify pointer to vertex array
  glEnableClientState(GL_VERTEX_ARRAY);
  glColorPointer(3, GL_FLOAT, 0, newColors);
  glVertexPointer(3, GL_FLOAT, 0, vertices);

  // Draw faces
  for (int i=0; i<6; i++) {
    if (
         (!useNeighbors) // either don't use neighbors, and draw everything!
         || // or...
         ( // if you do use neighbors,
           (!neighbors[i]) // If you don't have THIS neighbor
           && // and...
           ( // either
             (!directionalCulling) // you don't use directional culling
             || // or...
             ( // You do, and...
               (i!=0 ||   !leftCam) && (i!=1 || leftCam)   // camera can't see left/right of what's to the left/right of it
            && (i!=2 ||  !aboveCam) && (i!=3 || aboveCam)  // camera can't see top/bot of what's above/below it
            && (i!=4 || !behindCam) && (i!=5 || behindCam) // camera can't see back/front of what's in front of/behind it
             // Get rid of faces on other side from you
             // Each dimension recovers about 3fps
             )
           )
         )
       ) { // So draw that face!
      
      // Top is special
      if (i==2) {
        // Disable array colors,
        glDisableClientState(GL_COLOR_ARRAY);
        // use a special color
        glColor3f(r3,g3,b3);
      }

      // Trying new drawElements approach
      // used to be DrawRangeElements, but Windows didn't like that. Using drawElements now... is this more inefficient?
      //glDrawRangeElements(GL_TRIANGLES, 0, 3, 6, GL_UNSIGNED_BYTE, indices+6*i);
      glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_BYTE, indices+6*i);

      // Top has special cleanup too
      if (i==2) {
        // and re-enable array colors
        glEnableClientState(GL_COLOR_ARRAY);
      }
    }
  }

  // deactivate vertex arrays after drawing
  glDisableClientState(GL_VERTEX_ARRAY);
  glDisableClientState(GL_COLOR_ARRAY);
}

I have some other code to not draw any cubes at all that are directly behind the camera, but even that doesn't have that much of an impact. I've heard there are grouping techniques for such large numbers of cubes to turn them into unified walls and bigger blocks, but given that I have a checkerboard pattern across all the cubes' colors, that seems like it would be hard to maintain once things were grouped (although it does span about a 4x4x4 section, so it might still help). If there's an easy way to do that, I'm totally open to the idea, but otherwise, any thoughts on improving performance here? Maybe something like pointers to a multiplication matrix or something? (I have never done anything like that before, but it sounds helpful, and given the improvements that glDrawRangeElements with a vertex array made, I'm inclined to give it a try)

Thanks guys!
299  Community / Jams & Events / Re: So IndieCade on: October 07, 2012, 12:22:32 AM
Yamove was really fun! I only got to see others doing it, but the energy was definitely flowing into the audience - and following that up with Disasterpiece was great! (and Super Hexagon running in the background? Why so good only in the last hour??)

Really though, back on topic, Renga was amazing to watch, and you guys definitely needed more quads ;P
300  Developer / Design / Re: Good level design theory? on: October 06, 2012, 11:49:23 AM
That's amazing, I never thought of the secrets as a mechanic or gameplay element to introduce, but they definitely are. I'll have to think more abstractly about how my game works from now on I guess... thanks Azure Lazuline!
Pages: 1 ... 13 14 [15] 16 17 18
Theme orange-lt created by panic