i just started developing in xna and c#, and it would have been a whole heck of a lot easier on me if somebody just pointed out the basics
it would have saved a lot of frustration, but would have gotten rid of the 'fool's gate' of getting the process started, so some experienced users are bound to find this post offensive

anyway, there was no really simple thing on how to get started totally from scratch

all i had was a new pc with vista home whatever installed on it

so here's a quick breakdown of the basics the way i do it - some will hate this and puke

old school style;
 i am an 'old school' programmer, hence i like small, light and fast rather than big and heavy
 this style isn't for playing around and trying things out, this is for getting out a working product fast and furious
 this style focuses on producing content for the xbox 360 by first developing a working version on windows then creating a copy for xbox 360 and rebuilding and deploying via creators club

xna and c# suit me and my style of small, light and fast
 some people really hate the way i program
 i code in straight xna and c#, using other tools only to help me along the way, doing multiple passes of the tools to get all i need
 i hate toolchains but so far i don't mind using them individually if they produce something i need out of a file they make
 i use torque x builder for layout, then steal the positions and other info from the xml level file and hardcode them into the c# code
 i hate the c# compiler's folder system, but its not worth the time to fix it, so i just run with it
 i hate programming rules, but i love best practices and try to follow the windows ones, and if you don't follow best practices on the 360 it will hang up or crash
 i hardly ever comment my code - the code is comment enough of you understand it properly, which you should begin to remember and understand after a few programming sessions
 i prefer one big code file rather than a bunch of little ones
 i sometimes write my code in notepad or wordpad rather than the ide, and then start up the ide to compile it, feels like the old days compiling and linkimg masm
 i follow the path of the snake climbing the tree and i duplicate my code ruthlessly to do what i want, not make reusable code, and if i need something from old code i cut and paste
 a one space indent is just fine by me
 scary, ain't it!

bare bones installation vista home whatever:
all of these are free downloads, and be sure to register them so they don't time out
 m$ visual studio 2005 c# express (not 2008 - not supported by xna game studio version 2 as far as i can tell, maybe xna 3.0 is for 2008, but 2005 works just fine)
 xna game studio express version 2
 working, networked xbox 360 with a hard drive
 working developers wired 360 controller
 xbl gold membership
 xna creator's club membership
 on the xbox 360 download the launcher and connector from the game store, genres, other, creators club and successfully start them once

exorcise the system
 start the ide and choose new project from the file menu
 single-click only on the windows project
 change the name to windowsbase
 change the folder to the desktop
 it will create the project folder on the desktop when you hit ok
close the ide and open the folder, double-click on the sln file
 you may have to get fista to start m$ vs c# ide when you double-click on it by using browse
 go through every menu in the ide, familirize yourself with what they do,and be sure all folder settings are pointing to this folder we are woking in, especially build and import stuff
 use the project configuration menu to set your base info like copyright and author
 test project build and fix any errors or weirdness
 hit play to run it on the computer - it should be a blank blue screen and quits when the back button is pressed on the controller and that's it
 i call it the 'select' button, but they call it 'back' and that is what it actually says on the 360 controller if you look close
open and view the game1.cs file in the ide code window from the solution explorer
add a image file to contents from the solution explorer by right clicking on contents and add exiting - choose some small image file to load
make sure the image file appears and it copies it to the contents folder ok - use right click on it and remove it
this is your base program, so be sure all is correct - it needs to be running right with no crashes, error or even warnings
'save all' the project
close the ide and make a copy of the folder - name it something 360base
open the ide with the 360base folder's .sln file
create a copy of the solution for xbox360 under project 
delete the windows part - make this one for 360 only
 set up the xbox device connection and make sure the 360 can connect to the computer and it gets the program
 build, deploy and test the xbox version
 fix any weirdness and make this .sln your 360base
 copy both base projects somewhere safe as backups

choose a project name or working title
 don't sweat it and get bogged down on this step
 you can rename the final project later with some cool name
 just choose a one word name and run with it

use the ide to create a windows project folder with the project name on the desktop
 right in front of your eyes and foremost your mind
 create a txt file in the folder somewhere - this is the pre-production project breakdown file
 name it [the project name].txt and start editing it before doing anything else

pre-production project breakdown file
 since we are developing a 360 product, we have to define what the product actually is
 to quickly do this i use a pre-production breakdown text file to flesh out the product before even writing the first line of code or drawing the first sprite
 the biggest game is just another computer program, with a basic flow from start to end, some variables and control structures to modify the flow based on stuff happening
 the 360 is just a computer with a fancy graphics card that runs a program from start to end and shows sprites and controls them via what we tell it to do
 the idea is to lay out your ideas in the txt file and see what's what and determine what you really want and can actually do
 proper code is not important here, but if you have the code already or are pulling it from here and there, just drop it in the breakdown file
 think like a composer writing a song on the back of a napkin - only you need to know what stuff means
 develop the program, not from inside the language, but from outside and the overview
 don't think about the whole program but think what you want on the screen and build up your whole sprites list
 if there are multiple screens or multiple levels, start small with just one screen and detail them each separately, duplicating whatever is needed to do them
 finally break down the program into the structure that xna uses: startup, levels, sprites, setup, load, show, contol, unload and end
 if you just use load content struff, you don't have to worry about unloading it, the content manager does it for you
 if you load anything into the program without using the content manager, like arrays or something, wipe it using unload before ending or you will pile up junk in memory
 just do the setup that xna needs and don't worry about it for now, focus on what you want the program to look like
 the best tool is a piece of paper and a pen - draw out the screenshots you want to be able to do later, then figure out what you need to have in the program to make them happen
 the sprites list is all the sprites that are ever going to be on the screen throughout the whole entire program
 you'll need to determine where they will be placed on the screen, then load them all at the start oif they are not too huge
 this is setup, then load - if you do it all at the beginning, say during a splash screen, it won't bog down the user experience later
 starting with a single level, detail out each section
 as you work with xna and the xna structure, you can find what you need on the internet - best i have found so far is:http://msdn.microsoft.com/en-us/library/bb194908.aspx
 
materials (artwork)
 after working the breakdown file for awhile, you'll start to get a fairly good idea about the artwork (textures) you need for the sprites
 2dsprites are just flat one-sided 3dsprites, and they have just one texture that needs to be loaded for each sprite unless you are going to use the textures on multiple sprites
 so far i just create basic shapes in paint then use gimp to flesh them out and finally save them as transparent png's or jpg's

my first program
 i chose to do a buttons program for my first one, so i could get the hang of user input and what words xna uses - xna is different than everybody else, but simpler in the end
 it is very easy to get bogged down in the xna object model and overcomplicate things - keep it simple stupid (kiss) rule applies here
 i want just a dumbo program to show a xbox 360 controller picture on the screen and flash the buttons when they are clicked
 in this case there should be a good controller pic somewhere on the internet that's not copyrighted that shows all the buttons, the sticks and the triggers
 to use the picture, i loaded it into paint and cut out the buttons, the triggers and the sticks, lighting them up and saving each as separate image file
 create the jpg's for each sprite and one for the controller with nothing highlighted - these will be the images that you will add into content and load into the sprite textures

using buttons.txt;

game overview
 show the pic of a 360 controller with buttons that highlight, driven by the buttons and sticks on the controller

template
 windowsbase

materials
 texture jpg images
  if your artwork is named differently its no problem, just fix when you load it in the load
  controller sprite - an image of a 360 controller
                  Controller.jpg
  button and stick sprite texture jpg's - individual sprites for each of the controller buttons and the sticks
                  X
                  B
                  A
                  Select.
                  L1.                 
                  L2.
                  L3.
                  R1.
                  R2.
                  R3.
                  Start.

 do buttons
  draw the sprites over the controller buttons when they are clicked

setup
  think: define the sprites
                  Texture2D ControllerTexture;
  button and stick sprites - individual sprites for each of the controller buttons and the sticks
                  Texture2D YTexture;
                  Texture2D XTexture;
                  Texture2D BTexture;
                  Texture2D ATexture;
                  Texture2D SelectTexture;
                  Texture2D L1Texture;                 
                  Texture2D L2Texture;                 
                  Texture2D L3Texture;                 
                  Texture2D R1Texture;                 
                  Texture2D R2Texture;                 
                  Texture2D R3Texture;                 
                  Texture2D StartTexture;     
                  etc...

load
 think: you've define the sprites, now load the textures for them
  ControllerTexture = Content.Load<Texture2D>("controller");
  ATexture = Content.Load<Texture2D>("a");
  YTexture = Content.Load<Texture2D>("y");
  etc...

 sprite positions
  xna uses a Vector2 which is x and y in one go
  if the sprite needs to be moved, you do that in update
  this is in screen coords in pixels from top,left to bottom right of the 800 * 600 screen
  think: define the sprite, load the texture for it, set where it will be on the screen
    Vector2 ControllerPosition = new Vector2(200f,200f);
    Vector2 APosition = new Vector2(488f,342f);

update (runs every few milliseconds - don't bog it down with a lot of long code)

draw (runs every few milliseconds - don't bog it down with a lot of long code)
  if the buttons are pressed, draw the button's sprite at the button's position
  the color is the alphablend or transparent mask - leave white unless you need to change it
  sprites are drawn in batches, signified with a batch start and batch end statement - all your draws must be between them
    spriteBatch.Draw(ControllerTexture, ControllerPosition, Color.White);
    if (GamePad.GetState(PlayerIndex.One).Buttons.A == ButtonState.Pressed) spriteBatch.Draw(ATexture, APosition, Color.White);

and that's it


an upgraded version of the buttons360 project will be available at: buttons360.zip with more stuff than just showing the buttons, like doing text and following the sticks and triggers

i did copyright the code, so don't bite me and say its yours, but you are free to use it to learn how xna handles the controller stuff

the controller image is not mine and i just saved it off the xbox 360 help site - thanks m$

enjoy!

gina (radlogic)
radlogic@live.com
radlogicgames@live.com
 

I think I have to seriously disagree with you about comments not needed because code is clear enough. Having worked with a lot of programming and scripting languages since before I even started with middle school, I get into that mindset at times. After a couple months of work goes by you find a huge bug that never shown up back when you created and rigorously tested a function or class. You go in to work out the bug by first looking for the obvious mistakes you know you make, don't find any, then look deeper and deeper, until you realize you just don't understand how exactly the code works anymore. When you realize the time you spent trying to find the bug is equivalent to the time you could have rewrote the code involved, it dawns on you that you need to comment your code. Even just short rushed comments are better than none at all because it will give you an idea of how you were thinking when you first wrote that code.

Of course the opposite is true too, to many comments can make it hard to see your code around the comentation and skew your mindset when your trying to come up with a fresh approach.

Forgive me if I sound overly critical saying this but... why should anyone care about all of this? You sound like a kid in a classroom justifying his homework to an unhappy professor, except there aren't any of those here. Everyone's got their own comfort level when it comes to writing code.

It sounds like you had some good stuff to say in your post (I think) but unfortunately without good use of white space and some formatting I was unable to force myself to read the whole way through it. Those things are pretty effective in helping deliver your message so you might want to do a little clean up on your post so the message isn't lost in the noise. I know the forum formatting can be a little wonky, but it's seriously worth the effort if you feel you have something important to say.

And since you apparently don't like comments, I would point out that often that's the benefit of well placed comments as well. Lots of code, much like lots of text can be overwhelming. However with a well placed comment you give the eye something to anchor on making it more readable. It also has the benefit of helping break code into chunks more easily digestible by the mind. So yes, code should be written to be self-documenting but there's more than one benefit to a comment.

like i said, some people hate the way i code, and i guess the 'wall o text' made some bail too - connents are for those who don't know the code - i never went to school for this, i just had a burning desire to make cool video games that i would like to play - oh well, think of it as a noobgate, but don't tell those without the patience to dig through walls and walls and walls of meaningless-to-them code, they won't make it far past drawing a single sprite - anyway, i was thinking that the 1st done program should be a written-from-scratch static window with a static sprite that you move around and switch on and off stuff according to controller inputs - i did 'buttons', which shows a 360 controller and highlights which buttons are being pressed and shows the thumbstick and trigger positions, and i made the source available in the first post - it turns out there are a bunch of different ways to get the gamepad state and code it, but i'm using this one as its the first one i found - the idea with the first program is to learn (and not just copy and paste)  the basic xna framework, loading and drawing code, and how to do controller inputs - really it should be built from scratch, with the folder, then the pre-development file where you lay it out in your own head, then actually typing in some of the code with a little cut and paste here and there - 2nd program,  after the first one is done and running right, should be to learn the drawing code inside-out, and so it should be some type of basic maze game - i've noticed a lot of people aren't creative anymore, they just copy what's been done before, or they rack their brains for something to do - anyway, whatever it is it should involve moving world coordinates and rotating textures based on inputs, animating textures (turns out to be timer driven), collisions (2d math), etc - i did 'pounce!' (copyrighted and trademarked - copyright office and trademark office are on the web now, sweet!) where you are a cat that moves around a scrolling maze and grossly eats wandering mice while trying not to get snakebit by wandering snakes - very old school 80's arcade - still checking the name and stuff for copyrights/trademark infringements, and awaiting testing reports before release - there was a problem with the snakebite happening when there were no snakes around - something in converting the snake's world coordinates on the scrolling maze map into local coordinates to check them against the cat's - it only happened when you first came into the level so it may have something to do with initialization of the snakes and the cat - mice are fine, collisions are working and the maze walls are solid and you don't get stuck in them anymore - the xbox 360 game is complete as a beta release, before being released on creator's club  for review - xbox deploy over local network is sweet and is even quick enough for fixing things, although you can't monitor what's going on inside the 360 very well, like the frame rate that's actually being put to the screen so you know if you are bogging down the processor with too much code - since that's done, i've started doing 3D now - the first problem was that i thought you could just use the free 3d models off the web but that was crap - they were too low resolution and looked horrible, plus they weren't designed for animation and just stood there and slid around when you moved them - the models you need are 'boned' as in they have a skeleton you move to mimic motion rather than the whole thing just sliding along, and to look like its moving right it has to be an 'animation' model - 'boned animation' models have to be made in something like anim8or or xsi, and they are far more than just a 3d shape in blender or 3dmax or maya or the like - these are the most painful programs i have ever seen, and i have yet to produce anything decent on them - i'm looking into generating boned meshes on the fly for developing my own animations - best program i have found so far for doing boned animations is anim8or, but it doesn't run well at all on vista, even in all the compatablitiy modes, or maybe it just hates this laptop or video drivers, whatever it is it doesn't work and that's a shame - i wish somebody would do a mesh object creator in xna pc where you can drop meshed primitives, extrude them and stuff, maybe like a modeling-clay-type thing that exports straight to xna .fbx - i may end up doing that one myself lol if i keep hitting the wall - the next step would be a 3d game of third person shooter type where one's boned mesh can wander freely about a terrain map (reacting to the terrain normals), then shoot at some wandering boned meshes with per-pixel collision, then add damage and health, etc., but that is a long way off yet

lol,
rad

 

formatting!

As soon as I saw M$ I switched off.

Fuzzy Bug:

As soon as I saw M$ I switched off.

Same here.

But I agree on the comment point. I would rather have self explanatory code, than commented mess.

Ever heard of paragraphs, grammar?

Rad,

It sounds like you haven't yet made a program with any complexity. Once you do, remember comments, indentation and project folder structure will still be there to help you manage this complexity.

Yratelev

The problem with comments is that too many people use them incorrectly. Comments should tell why your code does something or describe some useful/nessassary piece of information about that particular section of code. Yes your code should be readable, but that only tells you what it does. No matter how clean your code is, you can never tell the why from just looking at it.

So use comments, but use them right!

Coding style and post formatting have nothing to do with the individual.  They have to do with the team.

If you are coding something all by yourself, then feel free to use whatever style and methodology that you like. We don't really care.  Any understandability and maintenance problems that you have are yours to deal with.  And if you don't have any problems with your style, then great.  Keep at it.

However, if you plan to code and communicate with others, then you will want to learn good style practices.  There are numerous opinions on which styles are the 'best' and folks will try to sell you on this and that, but it really doesn't matter.  What is best, is what works best for your team.

You can also feel free to continue to post walls of text, if you so please.  However, be prepared for the complaints about it.  They make it very hard to read lengthy posts.  If you find yourself in a position where you actually need help, you may not get an answer or you may get it later than you would have if you had taken the time to format a little better.

Eckish:

Coding style and post formatting have nothing to do with the individual.  They have to do with the team.

If you are coding something all by yourself, then feel free to use whatever style and methodology that you like. We don't really care.  Any understandability and maintenance problems that you have are yours to deal with.  And if you don't have any problems with your style, then great.  Keep at it.

However, if you plan to code and communicate with others, then you will want to learn good style practices.  There are numerous opinions on which styles are the 'best' and folks will try to sell you on this and that, but it really doesn't matter.  What is best, is what works best for your team.

You can also feel free to continue to post walls of text, if you so please.  However, be prepared for the complaints about it.  They make it very hard to read lengthy posts.  If you find yourself in a position where you actually need help, you may not get an answer or you may get it later than you would have if you had taken the time to format a little better.