Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Trent Squawkbox: Sep 6, 2009

I'm making a 2D platformer game in Xna. I just got the Box2D.Xna library working as the physics and collision component. I don't know how to use the physics with my characters. Should I apply impulses to them? Should I apply constant forces when they move and them remove them when they stop?
What do you advise for moving characters in a physics world?

# ? Mar 6, 2011 20:02

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 21:30

HolyJewsus: Jun 26, 2006; Disgruntled By Flashing and Blinking Lights.

http://forums.somethingawful.com/showthread.php?threadid=3392681&pagenumber=1#lastpost

just wanted to cross post this in here, hope thats okay, looking for some help with unity and creating a log of position data for an architecture project.

# ? Mar 7, 2011 22:46

Gerblyn: Apr 4, 2007; "TO BATTLE!"; Fun Shoe

Trent Squawkbox posted:

I'm making a 2D platformer game in Xna. I just got the Box2D.Xna library working as the physics and collision component. I don't know how to use the physics with my characters. Should I apply impulses to them? Should I apply constant forces when they move and them remove them when they stop?
What do you advise for moving characters in a physics world?

I've never used the XNA stuff, but I've tried to use physics (in 3D) to make character controllers before and it can be a bit painful. Be prepared for a lot of trial and error and messing about before you get it right. To be quite honest with you, I'd only use physics for the player character if I really wanted nice physics interactions between him and the world, otherwise it tends to be more trouble than it's worth. Writing your own thing with sphere slide algorithms is usually much easier to get good results with.

Anyway, to start out I'd use a circle as the primitive to represent the character in the physics simulation, and move it by applying a constant force linked to the left/right controls, plus an upward impulse linked to the jump button. You can try using other primitives if you like, but things like boxes will tend to tip over when you push them over the ground, which will probably mess things up.

The key problem you have to deal with is that you probably don't want the player to feel like they're blowing a rubber ball around with a straw. See what kind of material properties the system supports, raising friction can make the character easier to control, and reducing restitution/bounciness to 0 would probably be a good idea as well. If the library supports damping; both rotational and linear damping should help slow the character down faster when you stop applying force to it.

You could write your own damping code as well, simple linear damping is something like:

code:

vector velocity=character.getVelocity();

vector dampingForce = velocity * -cDampingStrength;

character.applyForce(dampingForce);

You can use similar code to grab the rotational velocity, multiply it by a negative constant, and then apply it as torque for rotational damping too.

Edit: Oh yeah, damping has a secondary effect as well. Since it applies a force proportional to velocity, once the character is moving fast enough, the damping force will be stronger than your own steering force, which lets you control the character's maximum speed.

Gerblyn fucked around with this message at 00:36 on Mar 8, 2011

# ? Mar 8, 2011 00:12

Pollyzoid: Nov 2, 2010; GRUUAGH you say?

Trent Squawkbox posted:

I'm making a 2D platformer game in Xna. I just got the Box2D.Xna library working as the physics and collision component. I don't know how to use the physics with my characters. Should I apply impulses to them? Should I apply constant forces when they move and them remove them when they stop?
What do you advise for moving characters in a physics world?

You could consider the same way Source does it. When you're touching ground, player.GroundEntity is set and normal physics no longer apply and the player has direct control of the character. For example, jumping is done by setting GroundEntity to NULL making normal physics apply, then by applying upwards force.

# ? Mar 8, 2011 12:26

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

A bunch of games simulate the player completely separately from everything else unless you take control of a physics object. UT2004 is probably the best example of this, try running somebody over with a vehicle and see what happens: It moves them outside of the collision area, and if they're an enemy, they take damage. If they can't be moved outside the collision box, they get instakilled and you get a "pancake" award. If it's a friendly though, they'll just sit inside the collision area until you move off of it. It never actually applies the vehicle velocity to the player in any situation.

The main advantage to doing this is that you can use a synchronous physics simulation (more stable) and asynchronous player simulation (more responsive).

If you do this, then objects in one simulation are unmovable in the other, and interactions between the two are limited to either "bouncing off" when collision is enabled, or "crushing" when collision is disabled and the collision areas overlap.

If you want to put the player and the world in the same physics simulation, the best thing to do delay player input by a fixed amount (which should be greater than the latency) in the actual simulation, but predict it as if it happened immediately.

OneEightHundred fucked around with this message at 19:50 on Mar 8, 2011

# ? Mar 8, 2011 18:59

Gerblyn: Apr 4, 2007; "TO BATTLE!"; Fun Shoe

I've used a system like that before, it works pretty nicely since you can still have some physics interactions but you don't have the player sliding all over the place like he's on an ice-rink. The only real issue is that the player can push physics objects around without them being able to push back, letting you do things like push boxes into walls so they completely freak out and fly off at high speed. You can see it happening when you walk into things in Dead Space 2 and it bugged the hell out of me.

# ? Mar 8, 2011 21:03

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

Does anyone have any examples of placing arbitrarily (ie, player determined) sized buildings on heightmap terrain?

For example, games like Evil Genius and Startopia allow players to drag out rectangular, gridded rooms, with each room serving a purpose. (Medical bay, armory, etc.) But in both those cases the terrain is completely flat so getting the walls to all mesh together is pretty simple (just make the mesh tileable.) I'd like to be able to place rooms on a terrain heightmap and have the mesh appear smooth.

I want to say that Black and White 2 did something like this with their walls, but I don't rightly remember.

It seems the simplest solution is to basically edit the heightmap and level the terrain whenever the player drops a building. So when the player puts down an entrance, every space they drag out from it raises or lowers the terrain as needed. And then I could just limit the amount of height differential that the terrain can be changed. That seems like it would work, but ultimately might lead to really bland looking player levels that don't nicely roll over hills and valleys.

Any ideas?

# ? Mar 9, 2011 19:11

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

One simple approach might be to make your building models with a thick "foundation" chunk of the geometry on the bottom that's intended to clip through the heightmap and make up for differences in levels. You'd still need to impose limits on how bumpy terrain can be, but it might look better.

# ? Mar 9, 2011 19:33

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

That is how Warcraft 3 did it.

# ? Mar 9, 2011 19:38

SlightlyMadman: Jan 14, 2005

SimCity 4 works the same way, and in fact when you see buildings being constructed, they're actually just a static model rising up out of the ground.

# ? Mar 9, 2011 19:51

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

That works fine for static models that are defined ahead of time, but I don't think it solves the problem I have. Although, maybe I could make my wall mesh taller than needed and just make sure the height of the tallest point isn't above, say 3 stories tall. Then I could have some variation on the floor levels of the buildings, but the walls are all the same 'height' at their peak.

Imagine that one player might make a 5x5 square, another player might make a 4x8, or a 12x16, etc. I want to run a wall around that perimeter and create a level floor within the interior of the shape. The player can then drop objects inside the area (say beds or trash cans). Like these buildings in Startopia http://en.wikipedia.org/wiki/File:StartopiaScreen.jpg. (I think they achieved their curve via vertex shader, and actually did all the layout on a flat plane, though I don't have any evidence of this.)

# ? Mar 9, 2011 20:07

Paniolo: Oct 9, 2007; Heads will roll.

In Starcraft 2, placing a building flattens the terrain underneath to the height at the centerpoint of the building.

Terrain flattening is the way to go, because that's how construction works in real life anyway.

# ? Mar 9, 2011 20:33

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

Paniolo posted:

In Starcraft 2, placing a building flattens the terrain underneath to the height at the centerpoint of the building.

Terrain flattening is the way to go, because that's how construction works in real life anyway.

That's what I'm leaning towards. Although I had no idea that Starcraft 2 had terrain heights beyond the 3 (or so) z-levels.

# ? Mar 9, 2011 21:19

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Paniolo posted:

Terrain flattening is the way to go, because that's how construction works in real life anyway.

Or buildings on stilts. Or, since he's talking arbitrary-length walls, just kind of curving with the terrain a-la the great wall of China. You could potentially do it that way by binding walls to a 'skeleton' based on the terrain heights, but you wouldn't want to do it that way if there's going to be a lot of walls, since then you'd be pushing skeletons back and forth all over. You could maybe do the same effect with a vertex shader and keeping the heightmap on the graphics card?

But flattening is certainly going to be the easiest way.

# ? Mar 9, 2011 22:23

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

roomforthetuna posted:

But flattening is certainly going to be the easiest way.

Sold.

I have a long history of starting projects and getting bogged down in some trivial detail that doesn't really affect the end product. ("Oooh... I bet I could make this character wall jump! I know our design doc doesn't have it, but I bet I could make it work." Three weeks later I'm still tuning the wall jump mechanic and I'm sick to death of the game project.)

# ? Mar 9, 2011 23:35

BizarroAzrael: Apr 6, 2006; "That must weigh heavily on your soul. Let me purge it for you."

I'm trying to lay down a basic 2D space physics system in Flash, so you have planets and asteroids and such moving around and changing each other's velocity and trajectory via gravity. Problem is, I'm not really sure I have a handle on the way this should work.

So everything that creates a gravity well will be added to an array, and on each frame I have it check each entry and see if any other objects are in it's gravity well and adjust their velocity on the x and y axis accordingly. My problem is determining how much that adjustment should be. What I'm thinking is that each object should have a size attribute, which obviously determines the size it appears to be, and mass-density attribute which can be used to give two identically sized asteroids differing gravity.

I believe that gravity to distance should look something like this:

So as an object is drawn closer, the velocity added each time increases, which I believe is correct. The mass density of the asteroid would increase the strength of gravity, so the surface gravity of a denser asteroid will be greater, whilst the asteroid's size will expand the reach of the field from the surface.

Will two objects of different mass-density but differing sizes have the same level of gravity on their surface, and will that gravity reach the same distance from their surface? And will the gravity of two objects of the same size but of differing mass-density reach the same distance and be equal on their surfaces?

Hope I've explained that alright, it's one of the more complicated programming problems I've dealt with so far.

# ? Mar 10, 2011 00:21

Gerblyn: Apr 4, 2007; "TO BATTLE!"; Fun Shoe

Why do you have a combined mass/density value? I think it would be better to just have a density value, and then derive the mass from that by multiplying it by the object's area. You can then directly tie the strength/reach of the asteroid's gravity to its mass.

That would answer both your questions:

Will two objects of different mass-density but differing sizes have the same level of gravity on their surface, and will that gravity reach the same distance from their surface?
The object whose mass*area is greater will have greater gravity at the surface and it will extend further.

And will the gravity of two objects of the same size but of differing mass-density reach the same distance and be equal on their surfaces?
The object with the greater density will have stronger gravity over a greater distance.

# ? Mar 10, 2011 00:36

HappyHippo: Nov 19, 2003; Do you have an Air Miles Card?

The physics of gravity is well worked out...

So a few points:
1) Instead of defining size and density, why not define the size and mass, since those are the two quantities you wanted anyway?

2) In reality, gravity works as:
Force = (constant) * M₁ * M₂ / (Distance between them)², where the M's are the masses. The force points towards the other object. It's best to keep track of the x and y values separately:
F_x = (constant) * [M₁ * M₂ / D²] * D_x / D
where D_x is the x component of the distance between the two objects. Similar equation for y.

3) From the force you get the acceleration:
a = (Sum of all forces) / M

Be sure to add the forces as vectors. Basically just add the x value and the y values of the forces separately, and get x and y values of the acceleration.
You can use acceleration to change the velocity each tick: v_x = v_x + a_x

Edit: One more thing
4) Technically gravity extends infinitely, but for practical purposes beyond a maximum there is little effect, so if you wanted you can save time but not looking at objects too far away. Also note that if two objects ever overlap the force is infinite (1/D² goes to infinity as D goes to zero). You'll need collision detection to make sure that they don't get too close or the numbers get arbitrarily large. Alternatively, just cap the maximum force at some reasonable value.

HappyHippo fucked around with this message at 00:41 on Mar 10, 2011

# ? Mar 10, 2011 00:36

ambushsabre: Sep 1, 2009; It's...it's not shutting down!

Pfhreak posted:

Sold.

I have a long history of starting projects and getting bogged down in some trivial detail that doesn't really affect the end product. ("Oooh... I bet I could make this character wall jump! I know our design doc doesn't have it, but I bet I could make it work." Three weeks later I'm still tuning the wall jump mechanic and I'm sick to death of the game project.)

This is the exact reason I love game jams to death. Honestly, I can't finish anything if it takes longer then maybe a week. For the games I have finished, there was a working prototype up in hours. I know I can't expect it to always be like that, but because I don't think I'll ever make games for a living and just do it as a hobby, that's the way I like it, it works, and I finish things I enjoy playing by myself. I think that's the key here: if you're not doing this for profit and only for your amusement, do it the way you want and the way you work best. For me, that's getting a core game down in hours and adding things as I think of them, that way it's kind of like playing it as I'm making it.

If I had to give a talk about the subject, I would say that I don't create procedural games, I create games procedurally. I get the basics down, if it's fun, I play it and play it and think "hey, it would be neat if I could add feature X." I then sit down and try to do it. If it works, hey my game just got a little more fun for me. If not, then no hard feelings I didn't really lose anything and I move on to the next thing. Get bored of a project? Spend a few hours getting a new one up. You might say I'll never get anything of any real value done, like minecraft. That's totally cool with me, because when I make games I have fun doing it and when I don't why should I do it? I mean, this is my hobby, if it's not fun I really don't need to do it, and I keep trying until something fun comes out and then I spend a week or two (or days, or hours sometimes) on that. My dodge the boxes games might not be fun for the masses, but I had fun developing them and playing them, so what the hell, right?

ps. I kind of went on a rant here, so please forgive any grammar / spelling mistakes.

# ? Mar 10, 2011 00:56

Bob Morales: Aug 18, 2006; ~~Just wear the fucking mask, Bob~~

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

ambushsabre posted:

I get the basics down, if it's fun, I play it and play it and think "hey, it would be neat if I could add feature X." I then sit down and try to do it. If it works, hey my game just got a little more fun for me. If not, then no hard feelings I didn't really lose anything and I move on to the next thing.

I'm like this with every project. Once I get the main feature down, I tend to shelve it because I'm not interested in the other stuff. It's like I'm interested in how to do something and not actually making a full game of it.

# ? Mar 10, 2011 14:45

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Bob Morales posted:

I'm like this with every project. Once I get the main feature down, I tend to shelve it because I'm not interested in the other stuff. It's like I'm interested in how to do something and not actually making a full game of it.

I've tried to avoid this by forcing myself to do the tedious menus and poo poo first, but all that happens then is I don't even want to start the project. I think for me that's what makes a mini-project like a competition game easier to finish - you're not expected to have all the boring crap like configuration and menus and save systems. And decent graphics.

# ? Mar 10, 2011 15:00

brian: Sep 11, 2001; I obtained this title through beard tax.

Like everything it really helps to have an external motivator like an actual deadline, or a self set deadline that coincides with something else important. After you've got the base idea down you really want to apply pressure on yourself to complete the project, either because you're tired of never finishing projects and want to finally have one completed, or because you want to sell it and make it cost efficient for the amount of time you've spent on it or whatever reason you can come up with that motivates you to continue with it when it's decidedly not fun to do so. The reason being that every project routinely hits points where it's not fun to continue but then become fun again later on.

The key part of competitions isn't the lower standards of what you're expected to do, it's that there's this hard time limit and everything you do manage to get in is an achievement and not expected. If you keep this attitude when just developing for fun in your spare time then you'll enjoy even the stuff you think might be boring because you can make it a challenge. For example I used to hate making menus and GUI widgets and whatnot, but after wanting to emulate good menu systems and learning how easy to do most transition effects are, it's probably my favourite part of writing a game past developing the main idea.

# ? Mar 10, 2011 16:13

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Bob Morales posted:

I'm like this with every project. Once I get the main feature down, I tend to shelve it because I'm not interested in the other stuff. It's like I'm interested in how to do something and not actually making a full game of it.

Mindcrime, lead of the Nehahra project, once said "there are two types of mod: The best mod in the world, and the one you can finish."

Focusing on things that are fun to develop over completion is probably the #1 cause of death of mod and indie projects. If you want to help yourself, there are three major things you should do:
- Cut plans for features that have long development time compared to their value to the final product, especially features that are "optional."
- Keep the design simple, not just for the sake of completion, but for the sake of users. Users tend to like games that are easy to understand, not "kitchen sink" poo poo.
- Commit to a feature freeze, ASAP. If it wasn't part of the original plan, then there'd better be a really good reason for adding it.

# ? Mar 10, 2011 16:24

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

OneEightHundred posted:

Mindcrime, lead of the Nehahra project, once said "there are two types of mod: The best mod in the world, and the one you can finish."

Focusing on things that are fun to develop over completion is probably the #1 cause of death of mod and indie projects. If you want to help yourself, there are three major things you should do:
- Cut plans for features that have long development time compared to their value to the final product, especially features that are "optional."
- Keep the design simple, not just for the sake of completion, but for the sake of users. Users tend to like games that are easy to understand, not "kitchen sink" poo poo.
- Commit to a feature freeze, ASAP. If it wasn't part of the original plan, then there'd better be a really good reason for adding it.

Interesting. Is there a way to combine the two? A disciplined approach to iterative never ending development? For example, can you apply these principles to each iteration, making development a series of small, tight, polished iterations?

# ? Mar 10, 2011 17:52

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Pfhreak posted:

A disciplined approach to iterative never ending development?

The first step to iterative development is to launch the first iteration.

It's not so much about process as it is about focus and speed. The longer the project goes on, the less likely it is to be finished. The two main things that ultimately land indie projects in the ditch are the lead losing interest, or talent losing interest and either stalling development or leaving followed by the lead not being able to (or not being interested enough to) recruit new talent. The odds of both go up with time. Burnout has basically the same effect on indie titles that running out of money has on commercial ones.

Ultimately, if you want to complete, then you really need to make completion a focus of the project, and a huge part of that is realizing what the enemies of completion are. Launch first, add cool poo poo later, or maybe don't even add cool poo poo because it actually makes your game too complicated.

OneEightHundred fucked around with this message at 18:11 on Mar 10, 2011

# ? Mar 10, 2011 18:02

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

OneEightHundred posted:

Launch first, add cool poo poo later, or maybe don't even add cool poo poo because it actually makes your game too complicated.

Though there is a cutoff point where if you release too early, the early-adopters think your game sucks and don't come back, and don't bring their friends, etc.

Also significant is that what constitutes "cool poo poo" to a common user is likely to be a really alien thing to a game developer (at least it is to me). poo poo like trophies, unlocks and collectibles that really add nothing to the actual game do a lot to make a game popular. poo poo like a half-decent AI, that seems important to me as a developer, hardly anyone gives a crap.

# ? Mar 10, 2011 18:22

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

roomforthetuna: I think it's less that people don't give a crap and more that important things are taken for granted. If you put a ton of effort into a great AI, it will generally fly under the radar. If the AI is awful, it will stick out and catch flak.

My general experience is that most game projects crumple after a few days of work. The trick is learning to reuse code and assets from old projects so you don't always have to start from zero. If I think I'm going to abandon a project, I try to pick out classes and modules that work, document anything that isn't straightforward and whip up a little test framework. It makes me a lot more confident reusing something 6 months later when I'm trawling my "leftovers" file.

I've also noticed that my likelihood of completing a project to my own satisfaction is nearly inversely proportional to how much I've mentioned the project to other people before completing it.

# ? Mar 10, 2011 18:33

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

roomforthetuna posted:

poo poo like trophies, unlocks and collectibles that really add nothing to the actual game do a lot to make a game popular.

In a way, indie projects have it worse than commercial projects because if you're on a commercial project, you know how much money you have left and you can at least assume people will stay for the paycheck. You can never tell when critical talent (including yourself) will burn out on an indie project, and if they burn out with bullshit features like achievements or extra skins unfinished, you can still launch or at least salvage a launch with minimal work. If they burn out and the game isn't playable because you were developing e-bling instead of playable maps, the project is probably hosed.

Because of that, it's not just that you want the launch date as early as possible, it's that you want a game that you could launch as early as possible. Once you have that, if you still want to delay launch and add nifty features, go right ahead. Just make sure you do them LAST, and realize that in terms of planning, every feature that you add that must be implemented before launch is a feature that may prevent the launch from ever happening.

OneEightHundred fucked around with this message at 18:52 on Mar 10, 2011

# ? Mar 10, 2011 18:48

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Internet Janitor posted:

roomforthetuna: I think it's less that people don't give a crap and more that important things are taken for granted. If you put a ton of effort into a great AI, it will generally fly under the radar. If the AI is awful, it will stick out and catch flak.

No, that's pretty much exactly what I'm getting at when I say how alien it is to game developers. It will stick out and catch flak from a tiny percentage of users, unless it's literally something game-ruining. A terrible opponent AI in an RTS might get mentioned in a review, but for most users they just won't care.

The only AI-related thing that will really be an issue with users is pathfinding for friendly units (and similar things like "not running into enemies" for escort missions). If enemy units run into walls all the time, or can be lured away from their group one a time, most people just note that as something they can exploit, and carry on - bad enemy AI is almost a feature, to the common user.

You're right though that I was exaggerating the point a bit - you don't want a bag of poo poo AI, but my point was, don't invest a lot of time making a great AI because almost nobody cares about how great the AI is so long as it's better than "dumb as rocks" (and even dumb as rocks is good enough for, say, World of Warcraft.)

In terms of making a game successful, the payoff for the much smaller time investment of implementing what I like to think of as "hats" (trophies, outfits etc.) is much bigger than the payoff for the much larger time investment of an AI that doesn't suck.

Edit: Also the thing that I always have trouble getting my head round, a juicy interface does a lot more to make a game look polished than anything actually game-related does. I hate trying to make interfaces juicy.

roomforthetuna fucked around with this message at 18:57 on Mar 10, 2011

# ? Mar 10, 2011 18:52

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

While we're kinda on the topic of menus and UIs, what sort of architectural approach do you guys usually take?

What I've been doing lately is something like the following:

- ViewModule is an interface that every menu screen and major (exclusive) game view implements. You can draw them, they are serviced with various mouse/keyboard events and they know about a ViewStack.

- The ViewStack contains a stack of ViewModules and dispatches events/redraw calls to the topmost ViewModule.

When the game starts, I push the main menu's ViewModule onto the stack, and whenever a menu is exited it can pop itself off and immediately transfer control to the module below. If I want to produce complex transitions I can wrap shim ViewModules around the "next" view that capture redraw calls and produce some kind of animation before popping themselves and pushing the "next" view.

In the game engine itself I often mirror this approach and build up the game and its UI in mostly decoupled layers, the main difference being that I make input events bubble down the stack until handled and service redraw calls to all layers, back-to-front. This makes it very easy to have dialog boxes, cutscenes and so forth where keymappings change completely and/or gameplay pauses without turning a "main game" class into spaghetti.

Thoughts?

# ? Mar 10, 2011 20:28

viewtyjoe: Jan 5, 2009

I hate not reading through a complete megathread, but unfortunately, my forum reading time is limited at the moment. I have two basic questions.

I'm going to be working in XNA simply because the framework is there and I have a full copy of it and Visual Studio 2008 thanks to MSN Academic Alliance or something.

Are there any solid books oriented towards an intermediately experienced programmer, and any tutorials more focused on the spriting and 2d aspects of XNA? After months of waffling, I'm finally going to get dirty and make a decent (hopefully) 2D fighting game.

Second, are there any sort of guidelines for setting deadlines? I know that having some sort of deadline can help when things get ugly, but I fear that I'm going to set arbitrarily harsh deadlines and abandon ship when I can't meet them and my inner perfectionist gets out of hand.

Also, I'm sure this is probably available on the first page or so, but other communities (especially with a slant towards XNA) I could go to in search of other people to work with or other resources to use?

# ? Mar 10, 2011 21:45

brian: Sep 11, 2001; I obtained this title through beard tax.

Internet Janitor posted:

While we're kinda on the topic of menus and UIs, what sort of architectural approach do you guys usually take?

What I've been doing lately is something like the following:

- ViewModule is an interface that every menu screen and major (exclusive) game view implements. You can draw them, they are serviced with various mouse/keyboard events and they know about a ViewStack.

- The ViewStack contains a stack of ViewModules and dispatches events/redraw calls to the topmost ViewModule.

When the game starts, I push the main menu's ViewModule onto the stack, and whenever a menu is exited it can pop itself off and immediately transfer control to the module below. If I want to produce complex transitions I can wrap shim ViewModules around the "next" view that capture redraw calls and produce some kind of animation before popping themselves and pushing the "next" view.

In the game engine itself I often mirror this approach and build up the game and its UI in mostly decoupled layers, the main difference being that I make input events bubble down the stack until handled and service redraw calls to all layers, back-to-front. This makes it very easy to have dialog boxes, cutscenes and so forth where keymappings change completely and/or gameplay pauses without turning a "main game" class into spaghetti.

Thoughts?

I mean that's more of a general architecture as it links into MVC (Model View Controller) style systems, but yeah that's generally how I approach it on a high level for dealing with different layers of GUI/input systems, it's pretty much the perfect situation for showing off consuming events too.

The key to making GUIs feel alive is just making as much of it as possible move when it comes to transitions, I tend to (and this varies depending on if it's a component based architecture like Unity or an inheritance based approach) have a series of menu panes that are essentially buckets of menu items, telling them when to start entering or exiting or when they're active and whatnot. That way you can switch panes by telling one to exit then bringing a new one in, add dialogs by having them sit on top and exit themselves when they're finished and overall simplify GUI transition writing to just enter and exit functions (e.g. scale/alpha/position interpolating).

Also if they all follow the same general approach of interpolating from invisible to visible then you can mess about with different interpolation/easing functions to achieve different effects. Add in a couple of delays where needed and you end up with a remarkably easy to use, extend and debug system. It has its limitations and isn't necessarily going to be super efficient, but in general menu systems don't need to worry about efficiency and with a component architecture you can separate stuff down to just enter or exit transitions and combine and layer them as appropriate.

Here's some old example thing from a year ago I did to show off the approach:

http://billyfletcher.com/unity/GUITest.html

# ? Mar 10, 2011 23:54

Gough Suppressant: Nov 14, 2008

roomforthetuna posted:

Though there is a cutoff point where if you release too early, the early-adopters think your game sucks and don't come back, and don't bring their friends, etc.

Also significant is that what constitutes "cool poo poo" to a common user is likely to be a really alien thing to a game developer (at least it is to me). poo poo like trophies, unlocks and collectibles that really add nothing to the actual game do a lot to make a game popular. poo poo like a half-decent AI, that seems important to me as a developer, hardly anyone gives a crap.

I honestly think that's more of a case of people still seeing things like trophies etc as something outside the game, rather than just another experience you can utilize. Looking at it from a traditional design point of view, and applying the idea of a design is perfect when you can't cut anything more out, you would be tempted to remove them, but if you see them as part of the core game you can acknowledge them as having tangible design benefits, this will also lead to better pacing of these features, as rather than just having them placed on top of existing progression, they can fit lulls in your game.

# ? Mar 11, 2011 15:52

Paniolo: Oct 9, 2007; Heads will roll.

MonsterUnderYourBed posted:

I honestly think that's more of a case of people still seeing things like trophies etc as something outside the game, rather than just another experience you can utilize. Looking at it from a traditional design point of view, and applying the idea of a design is perfect when you can't cut anything more out, you would be tempted to remove them, but if you see them as part of the core game you can acknowledge them as having tangible design benefits, this will also lead to better pacing of these features, as rather than just having them placed on top of existing progression, they can fit lulls in your game.

Achievements offer a nice way to give a player goals without railroading them towards specific objectives, especially in open-ended games like MMOs or sims where there isn't really a way to 'win' anyway. Just consider how much they could add to a SimCity-like game, for example.

# ? Mar 11, 2011 17:10

Cray: Dec 3, 2010

Paniolo posted:

Achievements offer a nice way to give a player goals without railroading them towards specific objectives, especially in open-ended games like MMOs or sims where there isn't really a way to 'win' anyway. Just consider how much they could add to a SimCity-like game, for example.

On the flip side, open games like that are all about setting your own goals. With a limited achievement set you can end up stifling player creativity by only rewarding actions you've been able to anticipate. "Oh, I'm supposed to be doing this and that... OK, all achievements unlocked, time to uninstall." Some sort of dynamic achievement system that automatically detects that the player did something cool would be nice, but I have no idea how that would work.

# ? Mar 11, 2011 17:25

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Cray: If you can come up with a good approach for something like you're saying, it would be a fairly compelling game mechanic, no?

# ? Mar 11, 2011 17:28

Cray: Dec 3, 2010

Internet Janitor posted:

Cray: If you can come up with a good approach for something like you're saying, it would be a fairly compelling game mechanic, no?

Sure, but how? Minecraft could reward you for building something really big, but how could it detect that you made it look like the face of Richard Nixon with a penis for a nose? You'd probably need to make it community-based so that your Penisface Nixon can be fully appreciated.

# ? Mar 11, 2011 17:33

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Nethack could probably do it - some sort of Bayes-style central database check at the end (upon ascension), supplied with all the items you used during the course of the run, then you'd get back a report of anything unusually extreme you did. "No monsters eaten, many shopkeepers killed, no melee weapons used, 5000 monsters turned to stone, 0 species genocided."

Edit: though this system would be a bit strange in that if lots of people did a vegetarian run it would no longer be considered unusual and the achievement would cease to be awarded. Essentially it would be a "coming up with crazy poo poo other people didn't already do a lot" achievement system. Like the Guinness Book of Records.

roomforthetuna fucked around with this message at 19:35 on Mar 11, 2011

# ? Mar 11, 2011 18:37

Paniolo: Oct 9, 2007; Heads will roll.

Cray posted:

On the flip side, open games like that are all about setting your own goals. With a limited achievement set you can end up stifling player creativity by only rewarding actions you've been able to anticipate. "Oh, I'm supposed to be doing this and that... OK, all achievements unlocked, time to uninstall." Some sort of dynamic achievement system that automatically detects that the player did something cool would be nice, but I have no idea how that would work.

This doesn't make any sense; if a player exhausts all available achievements, then they're in exactly the same position as if the game didn't have them in the first place. Unless you're suggesting that someone would say "Well, I enjoy playing this game, but since I've gotten all the unlocks I guess I have to stop playing now!"

Achievements might compel someone who would otherwise stop playing your game to play it a bit longer, but they aren't going to make someone who'd be willing to play without any objectives stop playing because they've all been unlocked.

# ? Mar 11, 2011 19:29

Adbot: ADBOT LOVES YOU

# ? May 12, 2024 21:30

Cray: Dec 3, 2010

Paniolo posted:

This doesn't make any sense; if a player exhausts all available achievements, then they're in exactly the same position as if the game didn't have them in the first place. Unless you're suggesting that someone would say "Well, I enjoy playing this game, but since I've gotten all the unlocks I guess I have to stop playing now!"

Achievements might compel someone who would otherwise stop playing your game to play it a bit longer, but they aren't going to make someone who'd be willing to play without any objectives stop playing because they've all been unlocked.

Actually, I think they can do that. Everything can be used to communicate with the player and a 100% list of completed achievements sends a different message than no achievements at all. I'd say if you're making a game that's all about players devising their own goals you're better off being honest about it and just not including any goals. If somebody starts playing your game and he sees no explicit objectives but notices a list of achievements instead it seems very much possible to me he'll just treat the achievements as objectives. If you still want achievements I'd try to focus on things the player will be doing anyway, like "kill X dudes", that won't detract him from his own plans.

Anyway, the real problem is that all players will be focused on the same achievements. Like the HL2 Ep2 thing with the garden gnome: it would be a great idea for a cool little self-imposed challenge, but the achievement just turns it into an optional objective. The appropriate response to "I sent the garden gnome into space in Episode 2" should be "You did what? Wow, I gotta come up with my own crazy thing like that". But instead it's just "Yeah, you and everybody else". The real "achievement" in the garden gnome challenge lies in the creativity of coming up with it, not so much in the execution. The achievement takes that away, now it's the designer being clever and not the player.

I'm not saying achievements cannot improve games, they sure can, but you need to think them through because they can backfire, particularly in more open games.

# ? Mar 11, 2011 20:35

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »