Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

kirkd

What about architecture??

This topic is 5743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Howdy. Reading through the various posts and tutorials it seems there is one thing that doesn''t always get emphasized - architecture. What is the theme regarding your game''s (application''s) object model, process flow, etc., etc. Does everyone follow Design Patterns religiously? My applications tend to look for like AntiPatterns. 8^) I would be very greatful to hear any comments of the importance (lack thereof) for architecture considerations. -Kirk

Share this post


Link to post
Share on other sites
Advertisement
quote:
What is the theme regarding your game''s (application''s) object model, process flow, etc., etc.



Generally as flexible as possible. I don''t tend to use virtual functions very much (unless absolutely needed, ie types change at run-time), instead prefering to use template classes to prevent re-writing large chunks of code.

quote:

Does everyone follow Design Patterns religiously? My applications tend to look for like AntiPatterns. 8^)



Most of the time patterns are used fairly frequently. Sometimes they are ammended or altered to fit the actual requirements, but they are usually templates to enforce a standard way of doing things across the code base. I suppose you could say that I use patterns a lot, but they may be different to those in the Gamma, Helm et al book.


quote:

I would be very greatful to hear any comments of the importance (lack thereof) for architecture considerations.



I use templates a lot. The main reason is to allow the underlying code to be altered without affecting the higher level code built out of it. For example, if components of the engine need to communicate, then I standardise the way in which this communication occurs by wrapping up the objects in a specific template.

I think the biggest thing I''ve learnt is to force the same standard interface across the entire engine to allow you to focus on the core interesting bits like ai, physics etc. I try to make my engine as data driven as possible by use of factories and node management classes that are pretty much fully automated. There is a scripting language that is internal to the engine, however you don''t ever see it because it''s all hidden away, for example,

new TNodeManager< MyType >;

The above code initialises the scripting engine information for the node type MyType and will generally wrap it in a class

Node< MyType >

which will define all of the extra stuff I need.

Kinda simplified, but hopefully you''ll get the idea.


Share this post


Link to post
Share on other sites
Architecture is central to my programming. I always plan everything I need before developping. My emphasis is on code reusability and ease of derivation. Design patterns are one tool that may help me refining my code architecture, but it is only one of the tools.
In my game, I distinguish a Model - View - Controller type of organisation. Then I cross this with the objects that interact within the game: Agent(Player and non players), Map and so on.
Of course you need to strike a balance between architecture and speed for your game:
- Your game runs the fastest when all the code is optimized towards the result of your game
- Your game has the best architecture when every entity is defined and reusable.

Hope that helps.
Ghostly yours,
Red.

Share this post


Link to post
Share on other sites
quote:
Original post by kirkd
Does everyone follow Design Patterns religiously?

Design Patterns are not something to be followed religously, but used to address problems in a specific context. Remember that there are no magic bullets in programming. You have no idea how many times I''ve seen popular patterns like View-Model-Controller or Command Objects applied in the wrong context or used when they''re not needed.
quote:
My applications tend to look for like AntiPatterns. 8^)

AntiPatterns are a very interesting topic, one I think is deserving of more attention. Unlike your standard GoF-like patterns that refrence vauge problems, contexts, and consequences, AntiPatterns start with a recognizable problem and follow through to a refactored solution. I look for AntiPatterns in my code all the time.

Share this post


Link to post
Share on other sites
Design Patterns are below the architectural level of abstraction.
Architecture begets design begets implementation.

Architecture focuses on software qualities, e.g. Performance, Availability, Code Maintainability, Time-To-Market, Buildability, & Conceptual-Integrity.

''Unit Operations'' are performed on a problem domain to factor the complexity into manageable chunks. The order of the operations is important - meaning the same unit operation applied in a different order result in a different architecture.

A classic architectural style is Client-Server, which if memory serves me, is achieved by applying the decomposition unit operation first. This results in a clear separation of responsibilities between the resultant pieces.

There is a forum here which is dedicated to the topics of design & architecture (Software Engineering).

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
Design Patterns are below the architectural level of abstraction.
Architecture begets design begets implementation.


I seem to recall that the Design Pattern movement found initial inspiration from a similiar Architectural movement (architecture as in building design). So I don''t quite follow this statement. Is it that the Architect builds a design using a set of patterns? And then that ''blueprint'' is handed over to the programmer who fills out the implementation details?

quote:
Original post by Magmai Kai Holmlor
Architecture focuses on software qualities, e.g. Performance, Availability, Code Maintainability, Time-To-Market, Buildability, & Conceptual-Integrity.


Um, sorry, that statement seems a bit buzzword laden. Can you clarify a little as to how performance falls under architecture? and also code maintainability? In some cases design patterns come off as being codeless abstractions. Is the idea then that any code can be used to fill in the details? Any code that is suited for the purpose that is - which probably makes more sense is the word ''language'' is used in stead of code.

quote:
Original post by Magmai Kai Holmlor
''Unit Operations'' are performed on a problem domain to factor the complexity into manageable chunks. The order of the operations is important - meaning the same unit operation applied in a different order result in a different architecture.

A classic architectural style is Client-Server, which if memory serves me, is achieved by applying the decomposition unit operation first. This results in a clear separation of responsibilities between the resultant pieces.


A little better - still seems somewhat buzzwordish to me.

Share this post


Link to post
Share on other sites
quote:

Original post by Magmai Kai Holmlor
Architecture focuses on software qualities, e.g. Performance, Availability, Code Maintainability, Time-To-Market, Buildability, & Conceptual-Integrity.

Response by LessBread
Um, sorry, that statement seems a bit buzzword laden. Can you clarify a little as to how performance falls under architecture? and also code maintainability? In some cases design patterns come off as being codeless abstractions. Is the idea then that any code can be used to fill in the details? Any code that is suited for the purpose that is - which probably makes more sense is the word ''language'' is used in stead of code.

Performance is a software quality. So are predictability (will performing the same set of operations yield the same results), reliability (is the software expected to be available and operational at all times), code maintainability (is the code comprising the software logically structured to promote and permit easy extension, and are logically distinct modules equally distinct and abstracted from each other in code), etc. Performance is a question of how long it takes the software to perform a task on a regular basis, or how frequently tasks are completed. The architecture of the software can have a tremendous impact on this. My best and most ready example of architecture affecting performance, however, comes from hardware.

Pipelining is a technique that restructured CPU datapath architecture, and resulted in an improvement in performance from having one instruction finished every total-datapath-delay to one instruction per longest-datapath-stage-delay. Reorganization of software modules, interface, data access strategies and so forth can massively affect software performance.

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
Design Patterns are below the architectural level of abstraction.
Architecture begets design begets implementation.

Response by LessBread
I seem to recall that the Design Pattern movement found initial inspiration from a similiar Architectural movement (architecture as in building design). So I don''t quite follow this statement. Is it that the Architect builds a design using a set of patterns? And then that ''blueprint'' is handed over to the programmer who fills out the implementation details?

I think the Architect builds a design using a set of principles. Patterns are common solutions to the problems of turning those abstract principles into concrete implementations. So, for example, an architect may decide to use an overhang principle (or concept) for a portion of a building - a balcony, for example, which would allow for a wider floorspace at an upper level than was physically available at ground level. The use of cantilevered designs is then a common architectural pattern for solving the problem posed by an overhang - how do you make it sufficiently stable and well supported that it can bear weight without apparent buttresses?

A lot of the ambiguity is due to the nature of language itself. We use the word "design", for example, for pretty much any non-concrete principle or philosophy that relates to tangible construction.

quote:
Original post by LessBread
A little better - still seems somewhat buzzwordish to me.

Unfortunately, my limited software engineering educational experience seems to indicate a hierarchical system of definitions, meaning you need to understand certain "lower" or more fundamental terms to comprehend the intent of higher ones. While this is true of virtually all fields of study, software engineering has the disadvantage of having to share its terms with slick marketing brochures. I mean, how often do you read the words differential equation in a product pamphlet, or hear linear regression in TV advertisements?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!