Results 1 to 8 of 8

Thread: Coding has started

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

    Coding has started

    It was announced in the private developer forum, but I think it should be out in the wider community... we have started coding

    We spent a bit of time getting our thoughts together and have come up with what we think is a pretty flexible architecture which we hope will allow us to create a great engine upon which we can build some great games.

    We'll keep you posted with progress etc.

    Since the project was announced, it's been decided that we will use Github to host the source code and other related items, including the feature tracking, so the feature request and issue reporting forums are going to be removed.

    The project repository can be found at https://github.com/PascalGameDevelop...ommunityEngine

    It's not too late to sign up as a developer... if you want to get involved follow the instructions in this thread - http://www.pascalgamedevelopment.com...264-Sign-Me-Up
    :: AthenaOfDelphi :: My Blog :: My Software ::

  2. #2
    I've only taken a brief look at the design documents so I might have more questions later on but for now I have one question. I hope you don't mind me asking about your design decisions

    Would you care to elaborate on the thoughts behind the Entity system? To me it seems like a peculiar mixture between traditional inheritance based object hierachy (TCEEntity, TCEPositionableEntity, TCELightEntity...) and then some component design. What makes the destinction that you inherit from TCEEntity to add positionable data but you must add a component to add a mesh to your entity?
    I'm sure you guys have discussed this design in your private forums and have your reasons but I'm not quite getting it yet. Some clarification on how you envision entities will be used in your engine would be appreciated? IMO how entities/actors (whatever you want to call them) are handled in a game engine is the most important so I would like to understand how PGDCE will handle them?
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  3. #3
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,205
    Blog Entries
    2
    I'll try and do my best to explain, but I didn't write that part of the design.

    An entity within the engine could be many things. An in-game object for example. But to become those things you attach components to it. So for example, if you want an in-game item, it is an entity that has a mesh component attached to it and a material component. Thus you could have multiple instances of an item, they all look identical, whilst at the same time they have their own properties such as location and orientation.

    That's about the best I can do at the moment in terms of an explanation/clarification. If you need more, hopefully one of the other's will provide it.
    :: AthenaOfDelphi :: My Blog :: My Software ::

  4. #4
    What you describe is a entity/component design. I get that.

    However this design seems to me to be a hybrid of entity/component design and traditional inheritance based object hierachy. If someone could explain me the reasoning why e.g. positional or light data is a core part of an entity and not added through another component it would be appreciated.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  5. #5
    Quote Originally Posted by pstudio View Post
    However this design seems to me to be a hybrid of entity/component design and traditional inheritance based object hierachy. If someone could explain me the reasoning why e.g. positional or light data is a core part of an entity and not added through another component it would be appreciated.
    There is no any strong reasons to not making light data as a component. So it may be implemented like that.

    Position data is not as simple.
    Positionable objects should be stored in a spatial data structure using their positions.
    Also a transformation hierarchy should be maintained efficiently.
    According to preliminary analysis having position data as a core part of each game entity will cause less indirect references to the data.
    But during actual implementation this may be revised.

  6. #6
    Ok, sounds fair enough. Curious to see the final design though it's obviously a long time away.

    Btw. I'm sure some of you are aware of this site but http://gameprogrammingpatterns.com/ is a good first source for patterns to consider when implementing a game/engine.

    I wish you good luck and hope you will keep us other nicely updated with any progress on the engine
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  7. #7
    erm... so... GOOD LUCK
    le programmeur

  8. #8
    Great. I hope we can see a demo soon.
    No signature provided yet.

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
  •  
Comodo SSL