a) Spend time developing a general set of routines to handle the display. You should cater for: -
Standard CRT monitors (4:3 aspect display, essentially 1:1 pixel aspect).
5:4 TFT's (many/all that have a native 1280x1024 res are this strange aspect).
16:10 TFT's (1440x900, 1680x1050, 1920x1200).
16:9 HDTV's (1280x720, 1920x1080).
Normal TV's (768x576 or 768x480 for PAL and NTSC) with an option to select a widescreen mode which is still the same res.
Plasma widescreens - same as the normal TV option, but may be hooked up via VGA at a resolution of 1024x768.
Essentially, create display routines that are independant of resolution, display aspect and pixel aspect.
Not an easy thing to perfect but once you've done it, you can re-use it in every project. You also ensure that your game will work on any display system past, present and future.
b) Depends entirely on your target audience and the time you want to spend developing your game. I've seen casual gamers spend less than 30 minutes on a game at any one time. If you haven't grabbed their attention within 30 seconds, you've lost them.
c) Tricky. Saving and loading should theoretically be within the user's home directory (i.e. 'My Documents'). Practically, it's often more useful to save to the local folder.
Regarding profiles... how many people actually bother to set up different Windows users accounts? Even then, how many people just use the profile of the person already logged in?
Implement a profiles system, but auto-create default profiles for each existing Windows user. Include an option to create more profiles (and handle the case where a profile is created and then a Windows user of the same name is created!).
Casual gamers do not want to have to re-play their way through a level to get to a certain point. Unless it's an absolutely necessary game element to not allow it, include a full game-state save option to allow players to carry on from exactly where they left off. This should be easy to implement if you already write code using a state-machine ethos.
Standard CRT monitors (4:3 aspect display, essentially 1:1 pixel aspect).
5:4 TFT's (many/all that have a native 1280x1024 res are this strange aspect).
16:10 TFT's (1440x900, 1680x1050, 1920x1200).
16:9 HDTV's (1280x720, 1920x1080).
Normal TV's (768x576 or 768x480 for PAL and NTSC) with an option to select a widescreen mode which is still the same res.
Plasma widescreens - same as the normal TV option, but may be hooked up via VGA at a resolution of 1024x768.
Essentially, create display routines that are independant of resolution, display aspect and pixel aspect.
Not an easy thing to perfect but once you've done it, you can re-use it in every project. You also ensure that your game will work on any display system past, present and future.
b) Depends entirely on your target audience and the time you want to spend developing your game. I've seen casual gamers spend less than 30 minutes on a game at any one time. If you haven't grabbed their attention within 30 seconds, you've lost them.
c) Tricky. Saving and loading should theoretically be within the user's home directory (i.e. 'My Documents'). Practically, it's often more useful to save to the local folder.
Regarding profiles... how many people actually bother to set up different Windows users accounts? Even then, how many people just use the profile of the person already logged in?
Implement a profiles system, but auto-create default profiles for each existing Windows user. Include an option to create more profiles (and handle the case where a profile is created and then a Windows user of the same name is created!).
Casual gamers do not want to have to re-play their way through a level to get to a certain point. Unless it's an absolutely necessary game element to not allow it, include a full game-state save option to allow players to carry on from exactly where they left off. This should be easy to implement if you already write code using a state-machine ethos.