10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game
Go Back  Xtreme Visual Basic Talk > > > 10 Steps to Designing a Game


Reply
 
Thread Tools Display Modes
  #61  
Old 05-22-2004, 05:53 PM
Otac0n's Avatar
Otac0n Otac0n is offline
Junior Contributor
 
Join Date: Jul 2003
Location: Wichita, KS
Posts: 239
Default


i would say "Do all your algorithms in QB so that you can be sure a) you know how they should be coded, and b) you can prove that they work."

why in QB, so you HAVE to port it over, aka, write it again.

I find this helps, because i find bugs WAY faster when i have written the code 2 times and understand it.
__________________
You will be attacked by a beast who has the body of a wolf, the tail of a lion, and the face of Donald Duck.
Reply With Quote
  #62  
Old 06-02-2004, 11:28 AM
Linux_Chic Linux_Chic is offline
Newcomer
 
Join Date: Sep 2003
Posts: 14
Default C++?

What if I want to, er, need to write a simple game in C++ - like a roleplay or a text adventure? Are there any simple frames to get me started, any hints or suggestions? Or is there anyone with basic code that I can reference off of?



*"Ford, you're turning into a penguin. Stop it."*
Reply With Quote
  #63  
Old 06-03-2004, 11:06 AM
Machaira's Avatar
Machaira10 Steps to Designing a Game Machaira is offline
Jedi Coder

* Expert *
 
Join Date: Aug 2002
Location: Abingdon, MD
Posts: 3,438
Default

Quote:
Originally Posted by Linux_Chic
What if I want to, er, need to write a simple game in C++ - like a roleplay or a text adventure? Are there any simple frames to get me started, any hints or suggestions? Or is there anyone with basic code that I can reference off of?
PlanetSourceCode probably has something.

I wouldn't recommend doing an RPG unless you have plenty of programming experience. Even a simple RPG is difficult. For a text adventure, you could do something like Zork. You can work out a simple list of words that you recognize (look, inventory, N, S, E, W, attack), create a simple map stored in an array, and go from there.
Reply With Quote
  #64  
Old 08-24-2004, 11:22 PM
Linux_Chic Linux_Chic is offline
Newcomer
 
Join Date: Sep 2003
Posts: 14
Talking

Thanks so much! I actually designed a game kinda like "Drug Wars," if you've ever seen that. It's pretty basic, just tedious, and I learned about randomizers! It's great! Thanks!
Reply With Quote
  #65  
Old 12-04-2004, 09:08 PM
StressedGeezer's Avatar
StressedGeezer StressedGeezer is offline
Junior Contributor
 
Join Date: Apr 2004
Location: Cambridge, England
Posts: 259
Default

I've been working on a tile-based 2D engine for about 18 months now. Here's my two cents:

Do *NOT* start by designing your game first. If you try to adhere to a design before you've written one line of code, you will already be limiting your program's potentials without realising it.


1. Design a GAME ENGINE that is capable of doing whatever you want (have it load and save the map files, sounds, key bindings etc, add user input code etc). BEFORE you make any SPECIFIC game, save everything onto disk / somewhere safe, and use this as a STARTING POINT FOR ANY GAME YOU WANT TO MAKE. This saves a lot of time in the long run because you don't have to spend another six months (or whatever) building a new engine because your R-Type clone can't use the RPG engine, and another bonus is that you are already familiar with the code. Think about it...

2. Apply your design concept to the engine. Make the map code behave how you want (RTYPE:constant scroll, MARIO:Player is centred but walks to edges of screen when map ends, DEFENDER-map loops infinitively, etc, map shape - strip, square, 1 screen's worth etc), make the type declarations reflect your characters' skills etc, make the code for spawning / animating / killing the game's objects, make that RPG combat system, etc, etc...

3. *NOW* keep an eye on your design specs and start making the game. You will find, by now, that most of your work will be on sound and graphics, with only minor coding to perform here and there... Keep referring to your design specs while coding / debugging / testing your game. You will probably have a lot more versatility in your code than if you tried to adhere to the design specs from scratch. Maybe new things that weren't even visualised at the design stage could be easily added here because, during the design of the engine, you HAD NO GAME DESIGN SPECS AND THEREFORE CATERED FOR AS WIDE A RANGE OF FUNCTIONALITY AS POSSIBLE!

I know that EVERYONE says that you should design the game first, but I disagree. I even had a previous post removed for saying the same thing, so I am hopefully explaining myself better here - A great imagination (like mine ) can spawn incredible game ideas that may have to be scrapped in order to bring the game into realisation. A greater understanding of the technology involved (ie, the engine that YOU just spend 6 months coding) will enable you to better understand how the final product will be realised. That's what the head of Nintendo thinks anyay

PS Feedback is welcome, as I know that most people will disagree and say that you should design the game BEFORE coding. I would like to hear more about the pros/cons of these two very different methodologies.
Reply With Quote
  #66  
Old 02-02-2005, 04:43 AM
Mutos Mutos is offline
Newcomer
 
Join Date: Jan 2004
Location: Near Paris, France
Posts: 3
Thumbs up

Hi all,


Just wanted to add something that seems to me VERY important :

--- Search for engines, don't redevelop Windows all by yourself ----

I mean, concentrate your dev on game engines, game features and game art. Don't redesign a graphics engine when there are many over DirectX and OpenGL that can do the job. For physics it's a little more litigious. But it's the same, search, try engines and keep ur game design in mind. Then u'll know if any engine can fit ur needs. But if u can find stg, use it. If u can't find anything, THEN develop using the features, ideas and tricks u stored during serach... This engine does that and I want it, but this other feature I won't use so I'll not even try to develop it... I want such layout and such interface I've found in such engine, but with such feature that lacked here and were there...

Also, disagree w/ "Build no tools", but w/ same pragmatic mind :

--- Use existing tools, else develop easy to use specific ones ----

For instance, for editing graphics or 3D models, stick to the standard tools and never ever try to redevelop 3DS or even Paint ^-^ But I'm currently on a Solar System Editor, which I need badly and which no-one ever made w/ all the specifics I need... But I took much inspiration from Celestia as I basically use the same physics.

Third lesson I learned the hard way :

--- Code modular and multi projects ----

This one I already read it somewhere before on the thread. It can't be repeated too much... It comprise making simple projects, keeping track of versions and building a library of bricks. Now I'm on VB.Net but from my previous VB6 projects I took all orbital mechanics and some render procedures and there's still other parts I could salvage. Oh, and never ever run the !%£µ*ù&?! VB6=>VB.Net converter, it can take a clean project and make it an ugly mess no-one could ever salvage ^-^

Enough for today, see u later...
Reply With Quote
  #67  
Old 05-23-2005, 02:21 PM
oticon6's Avatar
oticon6 oticon6 is offline
Centurion
 
Join Date: Apr 2003
Location: Queensland, Australia
Posts: 98
Default

I agree with StressedGeezer. Design sets boundaries, and often throughout the process of coding you realise you want to make a large change, but can't because the code layout was made to fit the design.

My advice would be to make a draft version. Get the main functionality of the game going, don't worry too much about order and conventions, just make sure you can get a good understanding of the best method to code it -- and keep each process as independent as possible.

Then, create it again almost from scratch. Now that you know what is required for each process and the variations/similarities/differences between parts of it, you can order it properly in a way that works universally.

When you're doing the final version, use modules. Use lots of modules. If you're creating a complex game, have one module per process category; otherwise you'll get overwhelmed with the code when trying to find and modify functions.

The other thing to note is to use declared types and arrays. Keep everything in a logical place. For example, if you have people on the screen, they will have an X and Y position each. Don't have person1X, person2X etc, or even personX(personID). Have something like:
Type Person
X As Integer
Y As Integer
End Type
...and then declare an array of Person. That way, they're indexed by integer (good for loops) and each have their own individual X and Y -- and it's made obvious that they both belong to that particular person.

Oh, one more. If your game is going to use moving graphics then avoid the use of components altogether (other than timers). Work with your form.
- If you're bitblitting a tilemap, work out a way that will allow you to draw exactly what you want to be shown (rather than shoving it into a picturebox to cover up your crazy bitblitting to negative positions.)
- If you want a button, declare it as a type with an X, Y, width, height etc etc, and then detect a click using hotspots.
- For beginners: Forget putting your sprites into an image component and changing the X and Y of it to make it move. That doesn't get you anywhere. Learn to use the BitBlt API (or possibly even DirectX).

Sorry if I'm repeating what has already been said, I've only looked at page 1 and 4 of this thread.
__________________
It's better to let people think you are an idiot than to open your mouth and prove it...
Reply With Quote
  #68  
Old 05-23-2005, 10:11 PM
Mutos Mutos is offline
Newcomer
 
Join Date: Jan 2004
Location: Near Paris, France
Posts: 3
Default

Hi oticon6,


I'm rather the other way round when it comes to design before code. I tried sometimes to code without a solid design and the result was always a real mess...

Also, I know designing before coding limits your design. But 1/ You know it and 2/ Your design is not the Tables of the Law. This means that once you've made a good design, it's easier to code, but you know where you go and which features you've dropped and why, and if it ever comes clear that a particular feature is easied than foreseen, it can be reintroduced. But basically the GDD is a life saver because it prevents you from going ranting everywhere uselessly ^-^

I'm now completing my game's first version's GDD. It's kinda like your prototype version, oticon6. I once stuffed everything into my head, headed up into coding and once I stopped and thought "Hey, u're laughing about beginners who claim they'll make the best MMORPG ever, but u're basically doing the same !". So I paused and reworked y design to make it feasible. It sorted out my ideas and now I'm nearly ready to begin coding... or finding a programmer of a high enough level for what I want. I'm not sure of having either time or skill to do the job. But now I've got the opportunity to think about it, quietly and with actual elements to make my decision from.

This takes me to : another interest of the GDD is that it can be read by someone else. A headful of Ideas doesn't enable teamwork, a GDD will ^-^
Reply With Quote
  #69  
Old 05-24-2005, 03:02 AM
oticon6's Avatar
oticon6 oticon6 is offline
Centurion
 
Join Date: Apr 2003
Location: Queensland, Australia
Posts: 98
Default

I do agree that a certain level of design needs to exist before you start, but nothing formal or extensive. I'm a Year 12 student, and in IPT we're expected to make extensive pseudocode and N-S diagrams for every single procedure before we're allowed to start coding (plus heaps of other crap).

I've never been one to follow conventions like this, because when it comes to implementing from the design, you can't easily test it along the way -- so if your design has a flaw (and chances are it will), it can be difficult to fix. Not only this, but you're basically interpreting it from start to finish. Without a specific design, you start off by creating one particular function, test and improve it until it's flawless, then expand to the next. That way you gain a much better understanding of the code itself.

I haven't been programming for very long (few years on and off -- mostly off), and this is my third game, so you're probably right about designing, but in my experience -- as far as design goes, don't go past a simple structure, the graphical representation, the types of objects involved (sprites etc) and possibly a flowchart to depict the relationship between each area of the game.

"Third game" probably sounds like more than it is. For the record:

First: Snake -- my design phase: "I'm going to make a Snake game *opens VB*". It was quite a mess, but I didn't know what I was doing, and it was more for the ability to learn how BitBlt and have some understanding of the tile concept. It did end up functioning, but with a few errors when travelling through walls that I used a series of If statements to correct.

Point: If you find a bug, don't just mess with it until it works. Understand why it happened, otherwise it'll come back to bite you.

Second: Minesweeper -- my design phase: I worked out the method I'd use to check surrounding tiles, and how to expand if none are found, but that was about it. It worked out quite well functionality-wise, but the code was again a mess. I later rebuilt it using Delphi and I was happy with it at the time, but I'm guessing if I look back at it now I'll think "What the hell did I think I was doing? How stupid can you get!"

Point: Experience experience experience. The more you have, the better you get; simple as that. If you look back on a project you did a while ago and think "*** IS THIS?! Man I was dumb..." then good, you're improving. If a game is beyond you, make something simpler or in seperate parts to get a better understanding first, then go back. Don't compromise -- learn.

Third: This game is much bigger than the last two. It's a clone of the old classic "Raptor: Call Of The Shadows." Not much design really went into it, most was conceptional rather than functional, because that was all worked out in my draft/prototype. It's been rather flawless the whole way with this second version (I'm not finished yet), but all that's left is really detecting collisions.

Enough meaningless chattery, I'm done. But there is one thing that I have noticed with beginners who want to make the "best game ever." Tip: Don't make or link your levels until you have ALL functionality under control.
__________________
It's better to let people think you are an idiot than to open your mouth and prove it...

Last edited by oticon6; 05-24-2005 at 03:08 AM.
Reply With Quote
  #70  
Old 05-24-2005, 02:59 PM
Mutos Mutos is offline
Newcomer
 
Join Date: Jan 2004
Location: Near Paris, France
Posts: 3
Default

Hi oticon6, hi all,


My GDD is not really formal, but it is quite extensive. It's in a Word document that describes nearly everything the software will do.

Of course it was not there by magic ! I tried some parts w/o making documents before. I wrote a lot of things and tried to devise what would happen if I coded those. I coded some parts and watched the explode, then corrected and learned ^-^

So the GDD is rather the result from all this, the focus where my experience, tests and trials have joined, than a "Athena from Jupiter's leg" phenomenon ! But I do believe it to be essential at one point, when you try to build a team and need a concrete specs doc...
Reply With Quote
  #71  
Old 06-26-2005, 09:12 AM
StressedGeezer's Avatar
StressedGeezer StressedGeezer is offline
Junior Contributor
 
Join Date: Apr 2004
Location: Cambridge, England
Posts: 259
Default

Quote:
Tip: Don't make or link your levels until you have ALL functionality under control.
I couldn't agree more - for all you noobs out there, this one line is one of the best pieces of advice on the entire forum (IMHO). My game JUST WILL NOT LINK LEVELS UNLESS ALL FUNCTIONALITY IS PRESENT. Would not have even considered this back when I was starting out. I have been working on my game now for about three years, and I still only have just one level, so it MUST be true! (although it has to be said, there are varying degrees of truth to this depending on the complexity of the project)

Good work pointing this out Oticon6 !!!
__________________
Geezer
Reply With Quote
  #72  
Old 08-17-2005, 06:39 PM
Spodi's Avatar
Spodi Spodi is offline
Junior Contributor
 
Join Date: Oct 2003
Location: Washington, USA
Posts: 201
Default

Yeah, it is sooooooo important to create the core of the engine before the acual game. Reason being is that you dont want to have to constantly change your game files, whether it is map files, object data, or other such matters. This also makes sure you dont have to change so much when you want to impliment/remove features. Nothing like writing out 100 maps, then going back and writing them all over again since you want to add in one more variable to each tile...
__________________
vbGORE :: Opensource Online RPG Engine
Reply With Quote
  #73  
Old 10-18-2005, 11:54 AM
typhoonxjai typhoonxjai is offline
Newcomer
 
Join Date: Sep 2005
Posts: 3
Default

Ok... so I just read the entire 4 pages of this thread and some parts made sense, but I'm still completely lost. Say that I am trying to make a first person shooter game, I first draw out the map in paint, then.... how it would look like in first person? So then I would draw the objects you are shooting at and after all that drawing, I start programming and I have no idea how to make the cross hair move. Any help here?
Reply With Quote
  #74  
Old 11-16-2005, 02:01 AM
Agwan's Avatar
Agwan Agwan is offline
Freshman
 
Join Date: Nov 2005
Location: Australia
Posts: 45
Default Suggestion

All of the "*experts*" should start a thread on actualy programming a 3D game somthing like battlezone if you've heard of that or a first person shooter.
__________________
Agwan - EXtremeSolutions
Reply With Quote
  #75  
Old 12-20-2005, 11:18 AM
sandwich sandwich is offline
Regular
 
Join Date: Dec 2005
Location: London
Posts: 63
Default

If I was planning on a more complicated strategy game, would it be advisable for me to learn C++ or something similar? Do C++ or any of the other languages have an advantage over VB in terms of game programming?

Last edited by sandwich; 12-20-2005 at 11:25 AM.
Reply With Quote
  #76  
Old 02-15-2006, 03:52 AM
Prahaai Prahaai is offline
Newcomer
 
Join Date: Feb 2006
Posts: 6
Default Whoa

All those expert programmers... whoa... i want to be one of you too!

I want to make a game for 3 years already. I started learning C++, than Visual Basic. Then i searched lots of game engines, game libraries... stuff. Now i decided to come back to where i started... the years go so fast and i only have 10 lines of code written. I think about my game every single day: i wake up "I must work my game!" i go to sleep "****! I wasted another day and the game is still not ready."
I have 3 notebooks full of data... if i think about my game every day, i get ideas... i must write them somewhere. Experts say: "Dont make an rpg first". I am trying to do that. Experts laugh at people who try to make the best MMORPG ever. I am trying to do that
I have a lot of items, i have the races, i have skills, i know how my interface should look like, i can see how the game will be played (in my head)... but i find it very difficult to matherialise. The story is unbelivably cool, i know, cose i'm good at inventing stories.

This is so hard, baaah. But i'll finnish it some day. I have to. I haven't wasted 3 years in vane. If a truck will kill me today, i'll morph into a ghost and i'll only haunt Visual Basic programmers. I must finnish the game. Then, the truck can kill me :P
Reply With Quote
  #77  
Old 02-15-2006, 05:06 AM
AdrianDeAngelis's Avatar
AdrianDeAngelis AdrianDeAngelis is offline
Contributor
 
Join Date: May 2005
Location: Australia
Posts: 549
Default

I wish you all the luck in the world... Heaven knows that you will need it! No one laughs at you, we only want you to not get too far in over your head, fail and then never program again.

Want to make an RPG first? Go ahead, that is what I did... but I would suggest leaving the MMO part out until you become an expert programmer. At this stage in your programming career you would be much better served spending you time developing your skills with something more realisitically acheivable.

Quote:
Experience, experience, experience
Can't agree more, the more you code the easier it is to see data stuctures and how everything interweaves together. I find that the best thing that you can do for yourself is get a really good core engine working first off, tweak it, make it as efficient as you can and put off coding the game itself until you do. In those first few hours/days/weeks of excitement it is so easy to make the huge mistake of blindly rushing in and coding randomly. When you are knee deep in code and AI/mechanics the last thing you want to do is to have to worry about displaying objects etc... you want an engine that when you say, "render this here!" it is done with minimal fuss letting you get back to coding.

Has anyone else noticed that they can pick out their old code segments in their ongoing projects and relative to the newer segments, how poor they are?
__________________
Automation error... What do you mean automation error you %#@*&!$ thing!

Star Admiral: 3D tactical space sim *** New Version 0.38 10/01/09 ***
Damage, shields and special weapons systems

Last edited by AdrianDeAngelis; 02-15-2006 at 05:18 AM.
Reply With Quote
  #78  
Old 02-23-2006, 07:48 PM
StressedGeezer's Avatar
StressedGeezer StressedGeezer is offline
Junior Contributor
 
Join Date: Apr 2004
Location: Cambridge, England
Posts: 259
Default

Prahaai,

Adrian is absolutely correct. Try to build an engine and some editing tools first. Think of it as the base code that you will re-use in future projects, even if you have only the one project to write. Once things are written as they should be, you should then be able to create objects in the world with just one line of code each, if you have coded the engine properly. Otherwise, things will just be 'hard-coded' and it will be very difficult to modify.

The basic rule of thumb is to make your engine as flexible as possible within its limits, in order to achieve what you want to do. Don't hard-code ANYTHING unless it's the main game loop. Make sure that you can add or remove content at 'design-time' without disrupting or crashing the remaining game at 'run-time'. When the base code can finally bend over backwards for you without breaking, THEN you know that you can start working on a game with it.

If, on the other hand, you do not intend to use the code ever again, then fine; hard-code it, and do it the easy, noob way . But you won't learn much about making games that way. It's best to start off doing things the way they are meant to be done, because in three year's time you will still have the experience of a noob. Trust me, I learned this lesson the hard way.

Another golden rule is this: Make a simple game, but make it FINISHED. Write Tetris or space invaders, but GET IT FINISHED. This will put you in the habit of finishing a project, and you will also learn some very valuable skills that you can put to use in making your RPG. And of course, keep the code, and perhaps upgrade it for the next new game.
__________________
Geezer
Reply With Quote
  #79  
Old 02-28-2006, 04:45 PM
Rannath Rannath is offline
Newcomer
 
Join Date: Sep 2005
Posts: 1
Default

Since this is about designing a game (which is different from programming a game.) My suggestion is to write an IAQ (Infrequently Asked Questions) Which is a FAQ for a non-existant game. Your IAQ will need:

The Name of your Game, if you don't have one, stick in <Name> or something.

Your Name, and the name of EVERYONE who worked on the game (including the person who brought you pizzapockets every day). Every one who was not directly involved, such as the pizzapocket person, will be put in "Other" or "Honorable mention" or "Cateror(sp?)", what ever you'd like. Basically these will be your credits.

Your Game's Type (of the popular types already mentioned).

Your Control scheme, which is how you want the players to play the game, including a breif description of buttons, menu system, map system, combat system, etc

'Now we get into the meat of the info that will be in here.

Character Bios, including names, physical descpition or picture, breif backstory, any relations you can think of, and anything else you can add for sake of completeness.

The Walkthrough (if you need it)

Boss strategies

Databases (item, beastiary, magic spells, shops, etc.)

Extras, such as: programmer cheats, cameos and easter eggs.

Any idea that didn't make it through your creative process, trust me you'll be glad you kept it.

That's basically all, but remember this can be changed as you work on your game, or other events happen.

Here's a short (and stupid) example. The story is from 8-bit theatre if anyone doesn't know.
Attached Files
File Type: txt example.txt (3.7 KB, 19 views)

Last edited by Rannath; 02-28-2006 at 06:33 PM.
Reply With Quote
  #80  
Old 02-28-2006, 09:34 PM
Val's Avatar
Val Val is offline
Senior Contributor
 
Join Date: May 2003
Location: Vancouver, WA
Posts: 1,268
Default

"Build the engine and the tools first"

A logical way to of course, but spending too much time on the engine is not a good idea. If you are thinking up new cool things to implement every month or so, then you won't ever be done (I learned that the hard way... and still learning ) You should force yourself to not go too far over the basic feature list you started with.

DirectX/OpenGL/BitBlt

This was probably mentioned somewhere above, but here are my two bits:

* BitBlt/GDI - just fine for simple games where you DO NOT want to do alpha blending or rotation, only basic masking for transparent areas, and maybe vertical/horizontal flip provided by StretchBlt. If you design it carefully enough, it is going to run as fast as you would want it, with many tiles and sprites drawn at the same time.

* DirectX/OpenGL - the complex effects are speeded up a lot. Alpha blending is fast enough to do just about everything you can think of, rotations and flips are possible, as well as skewing, plus a whole load of other cool graphical effects that can easily run in real time (plus, you can do lighting, normal/bump mapping, overlaying 3-d geometry on top of your 2-d world, etc). My point: use DirectX or OpenGL only when you are dead-set on your game looking really really really cool graphically, with all sorts of nice effects and animations that are too slow to run realtime on certain Windows computers. If you are content with a basic interface, maybe just a tiny bit of alpha blending, use BitBlt/AlphaBlend and other windows GDI functions.

One other note - if you are going to learn DirectX, learn DirectX 9 - the latest. Don't let the absence of DirectDraw scare you, as DirectX 9 is *extremely* easy to use.

If you decide to convert your GDI rendered game to DirectX9, you will want to follow these steps:

1. Get DX9 SDK, that huuuuuge file you can download from microsoft's website.

2. Find DX9 tutorials, and learn how to initialize DirectX both window and fullscreen.

3. After you manage the initialization, you should learn about basic transformed coordinates - vertex FVF - XYZ-RHW. Learn how to define vertices in screen space so they render correctly. Create a triangle, then a box. Play with FVF - define diffuse color. Remember, you don't have to go into actual untransformed 3-d geometry, you don't need any projection or world matrices, ignore everything about that.

4. Learn how to apply texture coordinates - add texture tu1 and tv1 to your vertex FVF. Remember that textures CAN ONLY BE sized as a multiple of 2 - 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. The width and the height must each be a multiple of two. Otherwise, your texture may appear stretched when it shouldn't be, or it may not appear at all, or it may be automatically scaled by DirectX to be multiple of two.

5. Learn about matrices - transform, scale, rotate x/y/z. It's not too hard, you can get it.

6. Learn about vertex buffers and index buffers. Likewise - this is not too hard. Vertex buffer makes sure that all vertices in the buffer are kept in video card memory, instead of your computer's memory, so that video card can render them faster. Index buffer indexes the vertices in vertex buffer for the sole purpose of avoiding duplicates - the less vertices in the vertex buffer the faster video card can process. Do a test, rendering your box with index + vertex buffers

7. Now that you know how 2-d stuff is rendered (and believe me, it's important), learn how to use D3DXSprite interface. What it does, is it handles pretty much everything for you. The only thing you have to do is load the sprite texture, then call sprite's Begin function to prepare for rendering sprites (and if any of the sprites you want to render will do alpha blending, then specify the appropriate flag), then call Draw function for each sprite you want to render (you only need one D3DXSprite interface to render all of your tiles and sprites), then call End to commit them to the device. You may want to sort them by their texture, to improve the performance (the less times you have to change texture the faster it renders). If some of your sprites do alpha blending and others do now, then draw those who do alpha blending separately, with the flag, and those who do not separately, without the flag, to make it render faster. Sprites can also do transform (SetTransform function) with the matrices in the manner you learned in step 5.

8. That's pretty much all you HAVE to know. Now, you may want to learn about Surfaces. Basically, surfaces enable you to modify sprite's textures at runtime (including creating texture dynamically). If you have an in-game interface system, then this may come in handy.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
 
10 Steps to Designing a Game
10 Steps to Designing a Game
 
-->