Levels of Programming

[Sabre]

Another one for the vets. When I first started this XNA programming lark, I found it almost impossable to comprehend (still do) at a low level of getting stuff to bump into each other and drawing graphics to the screen. To me the more 'advanced' stuff is easier. Is that normal?

Currently I am just starting to use multiple components, all seperate, but working together to do stuff. Then basicly flip them on and off to do things. Is basicly where I'm at if you wonder what I mean by 'advanced'. Games with more then one screen (or scene as the book calls them. Makes sense in context). I've yet to create anything like loot or stat table yet, but hopfully it shouldn't be to long.

Also, the next 2 chapters are online play, 3D basics and 3D physics. Personally, I wanted to stick to 2D single player games (for the time being anyway) and was wondering if anyone knows whether I can skip that stuff without missing something important?

[Asper Sarnoff]

Well, 3D and online gaming is the future whetever one likes it or not. It would definatively be the wisest tactical move to go trough them.

But I have little to no experience of programming. I know the process, how it is done, but not how to do it. Advice from me should be taken with a grain of salt, and some pepper.

[Sabre]

Well, 3D and online gaming is the future whetever one likes it or not. It would definatively be the wisest tactical move to go trough them.

But I have little to no experience of programming. I know the process, how it is done, but not how to do it. Advice from me should be taken with a grain of salt, and some pepper.

Indeed. I'm not looking for a job, just to make my own stuff. 3D is a pain in the arse and time consuming. Plus it looks a bit naff when done on the cheap. On the otherside, what you said is true. Also I could go through them at any point, but I'd rather not waste time on them unless there is stuff in there I can use.

[Mr. Krystal]

When you know the tricks that you use to do 3D games, it allows one to make more interesting and mechanically clever games in 2D. But 3D math is not required. Just note that some of it DOES carry over. Collision detection is simpler, but mostly the same, between 2 and 3D. Graphics are a lot different. Physics is typically very different (simpler) in 2D games. Game scripting and AI tend to be the same in two or three dimensions.

[Sabre]

When you know the tricks that you use to do 3D games, it allows one to make more interesting and mechanically clever games in 2D. But 3D math is not required. Just note that some of it DOES carry over. Collision detection is simpler, but mostly the same, between 2 and 3D. Graphics are a lot different. Physics is typically very different (simpler) in 2D games. Game scripting and AI tend to be the same in two or three dimensions.

Ok then. I'll do it. What of online play? Anything in their I'll need for SP?

[Mr. Krystal]

Ok then. I'll do it. What of online play? Anything in their I'll need for SP?

LOL, online play is like... super advanced. More difficult than 3D programming, anyway. I would just avoid it until you've made two or three games.

Otherwise, networking needs to be the very first thing you make in a game, other than the core architecture. It's not something that can be added on later and work.

[Sabre]

Hmm. Odd because that's the order they are in the book. A quick flick through shows that the excercise is adding netplay to the asteroid rip off you make as the first game. I'll give that chapter a wide birth then. Thanks for the advice. Well, back to it.

[Mr. Krystal]

Hmm. Odd because that's the order they are in the book. A quick flick through shows that the excercise is adding netplay to the asteroid rip off you make as the first game. I'll give that chapter a wide birth then. Thanks for the advice. Well, back to it.

It's probably one of two things:

1. The author is very good at networking, making it an easier subject for him/her than 3D graphics.

2. XNA provides a "use networking" checkbox that handles all the details for you.

[Sabre]

It's probably one of two things:

1. The author is very good at networking, making it an easier subject for him/her than 3D graphics.

2. XNA provides a "use networking" checkbox that handles all the details for you.

I don't know, but I assume so. Given that the game in question will work on PC or Xbox, I assume it uses live. The default component has

using Microsoft.Xna.Framework.Net;

which I assume is that.

Plus, unlike the rest of the book, I think 3D requires none microsoft tools. (You can't rig in paint for example)

[Mr. Krystal]

I don't know, but I assume so. Given that the game in question will work on PC or Xbox, I assume it uses live. The default component has

using Microsoft.Xna.Framework.Net;

which I assume is that.

Plus, unlike the rest of the book, I think 3D requires none microsoft tools. (You can't rig in paint for example)

So it's the second option then.

[Sabre]

Seems I've run into issues and graphics level code, it acts like you know whats happening and what to do, but I don't. I'll re-read the earlier bits, but I fear I will have to eather get another book or search online. Other then that, things are going well. I'm already spotting ways to improve the examples, even if that is about my current station.

For example. To stop the game going mental when you press a button, it considers the button unpressed if it was pressed in the previous update. Wouldn't a better idea to be to have it count how many millesecods the button has been pressed, and only have it do something every half second or so? It would be a bit more code-y, but be alot more powerful componant wise wouldn't it?

[Mr. Krystal]

For example. To stop the game going mental when you press a button, it considers the button unpressed if it was pressed in the previous update. Wouldn't a better idea to be to have it count how many millesecods the button has been pressed, and only have it do something every half second or so? It would be a bit more code-y, but be alot more powerful componant wise wouldn't it?

Depends on what you want. I prefer to think of button states like this:

Inactive (not touched)

Pressed (was pressed down this frame)

Active (held-down)

Unpressed (was released last frame)

Repeated (what you describe, held down call after time delay)

All have their meaning and use. Repeated is less useful in games. Consider Mario games: when B is pressed, he shoots a fireball, and as B remains active, he is state-changed to running (versus walking). Unpressing the B button removes the running state. The A button responds to the pressed to cause a jump, and uses how long it was active to determine the height of the jump, up to a certain time maximum.

On the other hand, in Star Fox 64, pressed begins a laser charge. Immediate unpress results in a single shot laser, but active time held causes a charged shot to occur, but only after the unpress.

If we apply repeated to Mario, you're talking about an auto jump or auto fireball feature, where as you hold down the button, every 0.5 seconds or so, Mario will attempt to jump or fire a fireball. This isn't very interactive. I can't think of many situations where a repeat check would be very useful. It's useful in computing though, because people often want the ability to repeat keys during active holding.

So, repeated button activation during a hold can be done just fine, I don't know what you would use it for.

[Sabre]

I was refering to what you call active. I was thinking more of a charge beam or grenade toss. eg. the longer you hold the button, the more powerful the blast, grenade toss. You could also do the halo thing of "tap for X, hold for Y" Your mario example is prefert. Press it for firebox, but hold it down for half a second and you get running.

[Mr. Krystal]

I was refering to what you call active. I was thinking more of a charge beam or grenade toss. eg. the longer you hold the button, the more powerful the blast, grenade toss. You could also do the halo thing of "tap for X, hold for Y" Your mario example is prefert. Press it for firebox, but hold it down for half a second and you get running.

If you want a timed active state, the simplest way I can think of to do it is to store the system-time at the point you first pressed the button, and then on the unpress event, or any time during active, get the system-time and subtract it from the start time, to give you the time since pressed. You can then use that value, normalized, as a modifier in whatever system you're using, be it grenade toss or something else.