Archived

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

kirkd

What about architecture??

Recommended Posts

kirkd    505
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
RobTheBloke    2553
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
Red Ghost    368
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
WayfarerX    130
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
Shannon Barber    1681
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
LessBread    1415
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
Oluseyi    2116
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
Oluseyi    2116
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
Red Ghost    368
daerid: I am not a Relisoft advocate. I learnt a lot of tricks from them though I must confess that my realisations are not at their level of architecture .
Oluseyi and Magmai Kai Holmlor explained it better than I did: a software architecture is the result of the integration of constraints (maintenance, speed, reusability, formats, ...) and required end-user functionalities in a design.
Thus your software architecture reflects the constraints and the functionalities you have to deal with.

This is why I always plan before since the soft architecture will be my answer to my set of constraints and functionality (set which may not be the same as yours. This is especially true when developping professional software).
Hope that helps.
Red.

Share this post


Link to post
Share on other sites
LessBread    1415
quote:
Original post by Oluseyi
I mean, how often do you read the words differential equation in a product pamphlet, or hear linear regression in TV advertisements?


Everyday!

Thanks for the clarification.

So let me see
- Client-Server is an architecture
- then would Peer-To-Peer also be an architecture?
- Model-View-Controller is an architecture (or is it a pattern?)
- Model-View-Presenter is an improvement on MVC - (according to this page:Model-View-Presenter Framework ) - and that in turn introduces another term - "framework" - Is framework synonymous with architecture? This page also introduces the term "Component Architecture"

I suppose there are many different "schools of thought" in regard to the issue of architecture and they don''t always agree on the use of terminology. I''ve read through the GoF pages on the web and I''ve found the Huston DP pages helpful too - but the "architecture" part still gets me. Perhaps because I''m still learning that part of it and most information found on the web pertains to specific tasks and not so much "how to fit them all together". Even most of the programming books I have are organized that way. Anyway, thanks again.




"Beautiful maiden," answered Candide, "when a man is in love, is jealous, and has been flogged by the Inquisition, he becomes lost to all reflection."

Share this post


Link to post
Share on other sites
Red Ghost    368
Lessbread:
I would propose an analogy with house building. Below is an english definition of architecture:

1 : the art or science of building; specifically : the art or practice of designing and building structures and especially habitable ones
2 a : formation or construction as or as if as the result of conscious act
b : a unifying or coherent form or structure
3 : architectural product or work
4 : a method or style of building
5 : the manner in which the components of a computer or computer system are organized and integrated

Definition translated from a french dictionnary:
resulting formation or construction from a conscious spirit (or soul ? I do not know which is best) which imagines artistically the organisation of space to favour the physical and spiritual development of man, to answer to man''s desires and which expresses itself through the creation of volumes and shapes, and through the choice of colours and materials.

From these definitions, I can say that software architecture is the art or science of designing and coding software to answer end-user desires and to favour the end-user efficiency.
(You can apply this to a video game architecture: art or science of designing and coding a game to answer end-user desires [like fun and suspension of disbelief] and to favour end-user efficiency [the game must meet transparently the end-user desires without adding other problems])

Going back to your examples keeping the previous definition in mind:
- Client-Server is an architecture
- Peer-To-Peer is also an architecture
- Model-View-Controller is an architecture
- Model-View-Presenter is an improvement on MVC and also an architecture

Now as to what distinguishes a pattern, a framework from an architecture. Patterns and frameworks concepts are both subsets of architecture concepts.
When you look at the building analogy, you find out that there are classical houses that share the same building map (the kitchen is always on the right when you enter, the living room on the left, the house is built in concrete, etc ...). These houses are an answer to customers specific needs: a compromise between a low cost house and a comfortable and well designed house. When you look at recent developped countries suburbs you can see rows and rows of identical houses. You can say that this is a design pattern for suburban houses.
Going back to the software, design patterns are a set of code architecture answers defined to meet recurrent needs in software development (like code maintenance or reusability especially in industrialized software production like video games).

I would say that the framework concept is between the architecture concept and the pattern concept. Looking back at the building analogy, everybody may not want to have a completely original house which is designed from scratch. Some customers want to have classic houses which they tune to their taste or specific needs. The builder will use a framework design that he will adapt to the customer needs and constraints. I would say that in the case of the MVC architecture, the aim of the web page was to present the MVP-MVC framework which can be adapted to more specific needs and constraints.

To sum up a rather long post:
Software Architecture: art or science of designing and coding software to answer end-user desires and to favour the end-user efficiency.
Software Framework:general code architecture defined to meet generic needs. To be used they need to be adapted to the specific constraints of the end-user.
Software Pattern:set of code architecture answers defined to meet recurrent needs in software development.

Hope that helps.
Ghostly yours,
Red.

Share this post


Link to post
Share on other sites
LessBread    1415
Ok - so the software architect lays down the specifications - the program should do this and perform to these expectations - but he doesn''t say how that should be done or how it should meet those expectations - the programmer makes those choices using patterns as if they were tools from a tool box.

The edifice metaphor works ok for me - but having looked at blueprints and having spent some time in the construction industry - the correlation between the two realms doesn''t seem quite so exact. For instance, many times blueprints explicitly call for particular materials to be used - not so often with houses - but certainly with bridges and the like. But I suppose that when the blueprints call for a specific material, they don''t specify which brand should be used - just that the material should meet a particular standard. So to unravel that metaphor a little - the blueprint represents the architecture and the material standard would represent the performanc expectation and a pattern would then be like a part specification - a 2x4 or a 12 guage wire - ack! - those terms probably don''t mean much in France. A 2x4 is a piece of lumber 2 inches wide, 4 inches across and however many feet long. That would be about 5 x 10 cm.

Hmm - this changes my initial "tools from a tool box" metaphor - but that makes sense - the tools are the compiler etc. The patterns are the parts the tools are used to construct a program out of.

Thanks.

Share this post


Link to post
Share on other sites
Red Ghost    368
LessBread:
Of course in a steelwork company, the materials and the way they should be welded together are explicitely defined because of the constraints imposed: you have here a pattern to solve the elasticity vs resistance for the bridge project. (I am more used to steelwork )
Thus when an architect is asked for steel bridge, when drawing the blue prints, he looks at all the constraints and the needs of his customer, see if there are existing patterns that can solve his constraints while trying to solve the needs of the end-user. This is why it is also called an art: because to satisfy all the constraints and the desires, you need to be creative, there are no pre-existing magic solution.

Sorry kirkd, even an architect may not follow religiously the book on Design Pattern if his constraints and the needs of the end-user are not adressed by the book.

Ghostly yours,
Red.

Share this post


Link to post
Share on other sites
Taulin    100
I am sure most of you already know this, but I thought it might be good to give a real life example to go along with this discussion.

On a less metaphorical note, it is always good to be aware of the existance of many patterns before designing your architecture.

I heve heard, practiced and read many times the best thing to do is to just read the basic introduction to each pattern in your pattern book of choice, and understand its reasoning. Then when its time to develop a piece of software, you have a better place to start. Once you know the problem, and hopefully can relate it to one the patterns you read about, you then go back and read up on it in more detail. At this time, you start designing your true architecture, adapting to the pattern as much as you want.

For example, I am familiar with all the patterns in "Core J2EE Patterns". When a client comes to me with a web application they want to make, I can relate the problem to one of them. I don''t know them all in detail, but I know them enough I can do this. It then makes it much easier deciding how big of a project it will be and an estimated cost.

Share this post


Link to post
Share on other sites
Shannon Barber    1681
I could go at length, but it''s be easier just to plug a book

"Software Architecture in Practice" by Len Bass, Paul Clemments, Rick Kazman
While hardly a "final word" on the subject, they present a well-organize treatise (it is THE most boring book I have ever read though - well, maybe mpeg2 ISO docs were worse)

Share this post


Link to post
Share on other sites