Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Getting started

  1. #1

    Getting started

    Hi folks,

    I have been programming Delphi for about 8 years now. I want to get started in creating 2D and 3D worlds, not necessarily for games, but maybe later.

    What do I need to read?
    What do I need to get for Delphi?
    What do I need to know?
    How do I get setup to start?

    Thanks in anticipation.
    Peter

  2. #2

    Re: Getting started

    Hi Peter!

    I'm always happy when people choose Delphi as a game development platform so let me tell you that you made a wise choice.

    Here are a few answers to your questions:

    > What do I need to read?
    Tough one! It all depends. With 8 years of Delphi experience I'd say you should get yourself a book covering the basics of game development which is intended for advanced programmers. Now what book you should get all depends on what API you choose for graphics and sound, etc. Unfortunately (tell me if I'm wrong) the best books on OpenGL and DirectX are written for C++ programmers. I got a bunch of those and I don't think it really matters if they're written for C++ or Pascal. Maybe somebody else can recommend something because I live in Germany and thus tend to get books which are written in German (duh!)

    > What do I need to get for Delphi?
    Once again that depends on a bunch of things. If you want to go the hardcore way (which is probably most rewarding), I'd recommend that you get yourself the JEDI DirectX and OpenGL header translations for Delphi and start playing around with them. Here's a link: http://www.delphi-jedi.org/
    If you want to go the more comfortable way, get DelphiX, PowerDraw, Omega, GameVision or *COUGH* XCESS. Links to all these game development kits can be found in this forum.

    > What do I need to know?
    Probably the best way of getting started is just to get started! Get yourself all the tools you need and start playing around. Study examples, etc. With your kind of experience you should be writing your own games in no time. Plus, there are few things in life that are more fun than writing your own games so learning how to do it is actually a lot of fun.

    > How do I get setup to start?
    I recommend going to http://turbo.gamedev.net and http://www.delphigamer.com. These are two excellent resources for Delphi game developers. On both sites you'll find tons of links to open source games which you can reverse engineer and study.
    Then make sure you have the DirectX/OpenGL headers installed properly and just go for it. Accessing graphics/sound/etc. APIs may be a bit different from what you've done so far as for example DirectX uses the COM (common object model) which is a bit different to how Delphi normally works. But other than that, game development is not all that different from application software development. If you haven't done much object oriented programming yet, this is the time to learn it as game programming is a lot easier when you know your objects.

    A bunch of additional tips:
    This forum is awesome. I wish I had access to that kind of website when I was getting into game programming. So don't be afraid to ask questions.

    Also, http://groups.google.com is an excellent place to look for information.


    Have fun and good luck!
    Ask me about the xcess game development kit

  3. #3

    Getting started

    Thanks Harry for providing so much info from the little I posted. I'll have a play and see how it goes.

    As far as choosing Delphi goes, why would you use anything else?

    Peter

  4. #4

    Re: Getting started

    Quote Originally Posted by pmetcher
    Thanks Harry for providing so much info from the little I posted. I'll have a play and see how it goes.

    As far as choosing Delphi goes, why would you use anything else?

    Peter
    Wise words!

    I'm working on a small and (relatively) object-oriented little game. I'll send you the source code so you can get a feel of one way of making a game. I'm not sure when it'll be done (maybe by the end of the week if all goes well).

    The first decision you'll face when starting to code is the component sets/libraries to use. Let's take a look through some of them.

    Graphics: starting with the fun one! The easiest method for graphics is the VCL with TBitmap/TCanvas, etc. Of course, this ain't the quickest for fancy graphics (it's just a wrapper for the GDI), but for quick prototyping it's very useful. Note that transparency is enough to bring the GDI to a major slowdown -- not good, not even touching on translucency (alpha blending)!

    You can also use DirectDraw. This a (getting on a bit) technology that's part of Microsoft DirectX. It was last updated in version 7 of DX. DDraw has a really straightforward interface once it's been encapsulated. It's good for drawing and pixel manipulation. It also gives you colour-keying (removing one colour from a picture when drawing, like with TBitmap.Transparent) but at a decent speed. However, it doesn't do alpha-blending, which is pretty annoying. DDraw is pretty compatible and will run on older machines.

    You can also use a 3d API such as OpenGL or Direct3d. There's a trick with these to render as if you were using a 2d API. The advantages here are that you get all sorts of nice features (e.g. alpha blending, anti-aliasing) without difficultly, and it'll be quick on newer PCs. Of course, it may well be slower on older PCs. A disadvantage is the annoying power-of-two sizes requirement of textures.

    Of course, there are tons of component sets out there to wrap up the graphics side of things. However, they'll all use one of the above APIs behind the scenes, with their respective advantages and disadvantages. Here are some, in no order of preference (note that Harry wrote one of them, hence his slight coughing fit )...

    Xcess GDK
    PowerDraw
    GameVision
    Project Omega
    GLXCess
    DelphiX
    WDirectX
    FlegelX
    DOT

    ...and lots more. Everyone and his dog has written some sort of Delphi component set for games! You can either do it the hard way (get the DirectX or OpenGL headers, then write the framework yourself) or use one of the above. Check out the tutorials section here -- there are a few tutorials on some of the above (e.g. one on using TCanvas, some for DelphiX, yadda yadda).

    Sound: there are a few choices here (apologies if I forget one)...

    Directsound/music (part of DirectX)
    FMod
    Bass
    OpenAL (a good complement for OpenGL, plus Noeska has some tutorials on it)
    ModPlug

    Some of the above have restrictions (e.g. free only for freeware games, pay licences when selling your game properly).

    Input: basically, every uses Win32 or DirectInput AFAIK. I don't know of other libraries for this, but then I've not looked...

    Physics: Open Dynamics Engine (ODE) is a good bet here.

    Network: No idea. I'd probably use sockets (winsock 2) myself, but I guess you could also use DirectPlay (again, part of DX).

    You're probably better off writing VCL games rather than Win32 API ones to begin with, since it's far more productive. I'd recommend getting a few small games under your belt (maybe start off with a simple board game, then a remake of an old game, then work your way up from there). Traveller's site has a ton of game projects for you to look at.

    If you decide what route to take then we can let you know where to get the relevant files and how to get started.

    We try to make this forum as helpful as possible, so ask as many questions as you need!
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  5. #5

    Getting started

    Cheers mate. I have found a OpenGL basic engine that uses ODE.
    That is exactly the sort of thing I am looking for.

    Two things;
    1. the example includes a map file. I inderstand the basic layout and content, but not the vertices or faces values - see below;

    52 vertices
    -3.0 0.0 -3.0

    17 faces
    1 2 27 26 1 1 wall // starting wall

    2. the example does not include collision detection. Know any good sources of info about collision detection?

    Peter

  6. #6

    Getting started

    Could you say where you got the engine, please, so we have an easier time?

    Also, when you mentioned about faces and vertices, did you mean that you didn't understand the concepts in general or just that you didn't understand their use in this particular file?

    EDIT: Oh, and gametutorials.com has some OpenGL tutorials about collision detection, IIRC. They'll be in C++ but I am willing to convert them to Delphi on request if you need them.
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  7. #7

    Getting started

    Sorry mate - tough day at the office.

    The vertices come out of a map file that came with the sample project. Now that I have had a chance to have a better look at the code, I understand what is going on.

    The tutorials on gametutorials.com look good. I am sure I will be posting more questions when I get a chance to have a closer look.

    cheers
    Peter

  8. #8

    Getting started

    I've got enough of the game finished so that you can see where it's going (design decisions, etc.). Unfortunately it's not finished yet!

    The game is going to be a worms-a-like thingy -- the only down side at the moment is a complete lack of collision detection, so you can't actually hit the other player.

    Anyway, take a look at it from here:
    http://www.alistairkeys.co.uk/downlo...unfinished.zip (about 300K).

    You need to install the "CNDXTimer.pas" file -- a timer component (I believe it's nabbed and modified from DelphiX's timer, but I don't remember where I first got it!).

    Things to note:

    The state system - definitely think about using this design for your own tasks. It lets you work on work part of the game at a time (for example, the high score menu, or the main game, etc.). Go to "unitState" and take a look at the last line of TStateRouter.Initialise -- this is the state the game initially starts in. You can change this to go directly to a given part (e.g. view the intro at the start, which is just some random text at the moment).

    The state system also makes menus a cinch. Here's an example snippet from one:

    [pascal] TMainMenuSelection = (mmPlayGame, mmOptions, mmHighScores, mmQuit);

    //----------------------------------------------------------------------------

    TMainMenuInfo = record
    Caption : string;
    NextState: TGameStateClass;
    end;
    PMainMenuInfo = ^TMainMenuInfo;[/pascal]

    Then, you can just have one of the above per option, stored in your state. Initialising it is pretty simple too -- you can use a const array like this, then just assign each option...

    [pascal]const
    MenuStuff: array[TMainMenuSelection] of TMainMenuInfo =
    (
    (Caption: 'Play game' ; NextState: TPlayingGameState),
    (Caption: 'Options' ; NextState: TOptionsState),
    (Caption: 'High scores'; NextState: THighScoreState),
    (Caption: 'Quit' ; NextState: TQuitState)
    );[/pascal]

    Changing states in the menu is then simply a matter of keeping a TMainMenuSelection variable for the current selection, plus an array of the above options. When the user selects one with the return key, the following code is all that's needed to go to the right state:

    [pascal]Result := ChangeState(FOptions[FSelection].NextState.Instance(FRouter));[/pascal]

    You can't really get simpler than that!

    The progress meter - I find this class to be quite handy. Feel free to nick it (and proof-read it for bugs, of course!).

    Note how relatively barren the main form's unit is. This is intentional and is usually a sign that you're going in the right direction. You want the main form to say "start this game", then let the appropriate classes take over -- no point in meddling with it there! If the main form receives anything important then it should pass it to the state system to be dealt with, rather than messing around with the internal state of the game.

    Oh yeah, there are a few hacks in there of course since it's a WIP. But it's mostly clean-ish at the moment.
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  9. #9

    Getting started

    A quick note: you might have to change the directory for "unit output directory" in project|options|directories/conditionals. It's set to the temp sub-folder of the source folder, so it will get the .dcu files out of the road. Just point it to your own directory (unless you have an e:\ali stuff\... directory!).
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  10. #10

    Getting started

    Cheers. The state idea sounds like a good one.

    Any ideas where I can get collision detection code in Delphi - all I have found is in C++?

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •