Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 67

Thread: PyroGineび「 Game Engine

  1. #21

    Re: PyroGine™ Game Engine

    No problem. I wanted to touch a bit on some of the major parts so readers could get an idea of the range and depth of the engine. I would like to round out things with a list of all the classes available in the SDK.

    • TPGObject
    • TPGObjectList
    • TPGDLL
    • TPGActor
    • TPGActorList
    • TPGActorScene
    • TPGAIState
    • TPGAIStateMachine
    • TPGAIActor
    • TPGEntity
    • TPGTimer
    • TPGDisplayDevice
    • TPGApplication
    • TPGAudio
    • TPGAudioPlayer
    • TPGList
    • TPGSparseArray
    • TPGSQLQueryBuilder
    • TPGDatabase
    • TPGDatabaseTable
    • TPGFont
    • TPGFontStudio
    • TPGGame
    • TPGRenderDevice
    • TPGTexture
    • TPGSurface
    • TPGPolygon
    • TPGPolyPoint
    • TPGSprite
    • TPGImage
    • TPGBezier
    • TPGHighscore
    • TPGInput
    • TPGIPCServer
    • TPGIPCClient
    • TPGMath
    • TPGNet
    • TPGPersistentObject
    • TPGLogFile
    • TPGConfigFile
    • TPGStream
    • TPGMemoryStream
    • TPGFileStream
    • TPGExeResourceStream
    • TPGArchive
    • TPGUnzipArchive
    • TPGIniFile
    • TPGXML
    • TPGStarfield
    • TPGTestCase
    • TPGGraphicalTestCase
    • TPGTestCaseMenu
    • TPGStartupDialog
    • TPGMenu
    • TPGUtils
    • TPGDirList
    • TPGExeMod
    • TPGPersistence
    • TPGPlugin
    • TPGPluginManager
    [br]Some things I did not yet mention was support for making game plugins, doing test cases, the game framework, the basic menuing system, XML support, configuration file support, various stream types, math routines, directly modifying exe data and much more. ECOM allows it to work with all 32 bit versions of Delphi, C++ Builder 2010. There is even a API layer exposing the major features of the engine allowing easier bindings for other languages. Out of the box comes bindings for Delphi and C++.
    Jarrod Davis
    Technical Director @ Piradyne Games

  2. #22
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25

    Re: PyroGineび「 Game Engine

    Woah thats quite the list. Hope the documentation is really extensive.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  3. #23

    Re: PyroGineび「 Game Engine

    Amazing. This library will give me idea's on how to design my own engine.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  4. #24

    Re: PyroGineび「 Game Engine

    @WILL
    Documentation will be a beast unto itself, sigh. But I'm committed to providing great docs.

    @chronozphere
    Thanks. 10+ years of continual growth and refinement.

    It grow out of a need to make my own projects, a vision for a robust solution that gives you a platform for growth. It's higher level than using DirectX alone, but still low enough that you can build on top.

    Also over the years I've been learning about component based development and how it can help with building and managing complex systems. Combine this with some agile methodology and you can streamline your development efforts. Ok, what does all that mean? I've asked myself these questions many, many times. It certainly sounds good, but how can it be applied on a practice level? Well, the idea is that as your software project continues to grow and become more complex, are you able to make changes without the whole thing exploding or you finding that it's just easier to start all over because that would be easier than making the needed changes? Son, I can not tell you how many times I've been in that position. I just started over because what I had was working, but there was no room for growth and to change things became to much of a mess.

    The idea is that if you design your project around the notion of components where you have a tree for example that you can hang functionality on, this functionality is more or less an independent logical entity. The TPGActorList can be that tree and the TPGActor object can be that logical entity that can perform some functionality. The ActorList can send messages to actors and actors can respond to those messages. For example, you dropped a nuke and it's time for all actors in a certain range to die, you can broadcast a message that you need to go away because a nuke just went off. In this case they respond by terminating themselves. In cases where you need to send a message and wait for response, the SendMessage function will return the actor that responded or nil if there was no response. My point is that there is a logical way that you can now communicate with all the fruits of functionally hanging on the vine so to speak.

    Now if you design things in such a way so that the actors can be independent, yet they can interact with the rest of the design then if something goes wrong where a particular functionality is not needed or need to be replaced, just remove it or change that actor without having to change the whole tree. By rapidly iterating, changing your design in the areas that need change without effecting everything else you can push development forward in a logical and consistent manager. Note that is can be much more complex than what I've outlined but the concept is the same. Your project can be broken up in a logical fashion where you have a tree and you hang functionality on it. You should be able to add/remove/change thing without adversely effecting everything else. Now when change is needed you can replace this logical functionality rather than having to tare down your whole tree and starting over.

    In PG the ActorList is the stage or the playground and the Actor is the player. An actor can have children. Again the tree-functionality concept, where you can add functionally to each actor and those children will be updated when the actor's Update method is called and if the children need to render their Render method is called when the parent's render method is called. So very complex design is possible yet be handled in a logical and consistent manager.
    Jarrod Davis
    Technical Director @ Piradyne Games

  5. #25
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25

    Re: PyroGineび「 Game Engine

    Quote Originally Posted by PyroGine Development
    @WILL
    Documentation will be a beast unto itself, sigh. But I'm committed to providing great docs.
    I know that it's not 100% Lazarus or FPC ready yet, but FPC has a great tool called fpcdoc (I think) that will generate html files for your units all you have to do is fill in the description text and details for each...?
    Jason McMillen
    Pascal Game Development
    Co-Founder





  6. #26
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,245
    Blog Entries
    2

    Re: PyroGineび「 Game Engine

    Quote Originally Posted by WILL
    Quote Originally Posted by PyroGine Development
    @WILL
    Documentation will be a beast unto itself, sigh. But I'm committed to providing great docs.
    I know that it's not 100% Lazarus or FPC ready yet, but FPC has a great tool called fpcdoc (I think) that will generate html files for your units all you have to do is fill in the description text and details for each...?
    And there is PasDoc (my personal choice) and DelphiDoc... unfortunately they both have slightly different comment formats. PasDoc also generates a CHM project to make a CHM from the code, and will if you install GraphViz allow you to produce a couple of dependency charts (non-clickable).
    :: AthenaOfDelphi :: My Blog :: My Software ::

  7. #27

    Re: PyroGineび「 Game Engine

    @WILL, @AthenaOfDelphi
    Thanks I will check them out.

    One I just found is DelphiCodeToDoc.

    Jarrod Davis
    Technical Director @ Piradyne Games

  8. #28

    Re: PyroGineび「 Game Engine

    I played with DelphiCodeToDoc a little and it seems to be pretty cool too. Let me know what you think of it.
    Jarrod Davis
    Technical Director @ Piradyne Games

  9. #29
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,245
    Blog Entries
    2

    Re: PyroGineび「 Game Engine

    Quote Originally Posted by PyroGine Development
    I played with DelphiCodeToDoc a little and it seems to be pretty cool too. Let me know what you think of it.
    Actually I think that was the one I was thinking of (I've bought a new laptop since I tried them, and I preferred PasDoc so I only have that installed now). Of the two, I preferred PasDoc because it had a better range of supported tags and the resulting documentation was, IMO better.
    :: AthenaOfDelphi :: My Blog :: My Software ::

  10. #30

    Re: PyroGineび「 Game Engine

    Ahh ok I see. There is one in fact called DelphiDoc, which I tried, but I was getting AVs. I will check out PasDoc too.

    On another note I just updated the PGNet unit with a new class that support network object persistence. I simply derived a new class from PGNet, override the OnRecive event handler to handle processing objects, finally added a new event handler to received the object rather than the data pointer and size. Now you will be able to send live objects across the wire.

    Deceleration
    [code=delphi] TPGNetObjects = class(TPGNet)
    protected
    FPersistence: TPGPersistence;
    procedure OnReceive(const aHost: TPGString; aPort: Integer; aData: Pointer; aSize: Integer);
    public
    constructor Create; override;
    destructor Destroy; override;
    procedure OnReceiveObject(const aHost: TPGString; aPort: Integer; aObj: TPGPersistentObject); virtual;
    end;
    [/code]

    Implementation
    [code=delphi]procedure TPGNetObjects.OnReceive(const aHost: TPGString; aPort: Integer; aData: Pointer; aSize: Integer);

    function GetObject(aData: Pointer; aSize: Integer): TPGPersistentObject;
    var
    stm: TPGMemoryStream;
    begin
    Result := nil;
    if aData = nil then Exit;

    stm := TPGMemoryStream.Create;
    try
    stm.OpenBuffer(aData, aSize);
    Result := FPersistence.LoadObject(stm);
    finally
    PG_FreeAndNil(stm);
    end;
    end;

    var
    obj: TPGPersistentObject;
    begin
    // check if incoming data has a possibly valid persistant object
    // signature
    if (aData <> nil) and (aSize > FPersistence.ObjIdSize) then
    begin
    // try to get object instance from incoming stream
    obj := GetObject(aData, aSize);

    // if we got a valid object then pass it to the event handler
    if Assigned(obj) then
    begin

    // call event handler
    OnReceiveObject(aHost, aPort, obj);

    // free object
    PG_FreeAndNil(obj);
    end;
    end;
    end;

    constructor TPGNetObjects.Create;
    begin
    inherited;
    SetReceiveEvent(OnReceive);
    FPersistence := TPGPersistence.Create;
    end;

    destructor TPGNetObjects.Destroy;
    begin
    PG_FreeAndNil(FPersistence);
    inherited;
    end;

    procedure TPGNetObjects.OnReceiveObject(const aHost: TPGString; aPort: Integer; aObj: TPGPersistentObject);
    begin
    // handle received objects here, override for your own derived classes
    end;[/code]
    Jarrod Davis
    Technical Director @ Piradyne Games

Page 3 of 7 FirstFirst 12345 ... 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
  •