Jump to content

  • Log In with Google      Sign In   
  • Create Account


How much planning do game programmer before writing a single line of code and how do they plan it out


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
28 replies to this topic

#1 warnexus   Prime Members   -  Reputation: 1368

Like
1Likes
Like

Posted 31 January 2014 - 09:27 PM

Despite the planning, are there situations that results in too many "parameter passing" from one class to the class the programmer wants to be in?

 

As a self taught game programmer who has been writing the codebase for one month and 2 weeks for a role playing game, I also want to know the thought process of how game programmer think or approach a codebase they are about to write.

 

Do they write psuedo code just to spot as much future problems in implementing a feature that would make their life easier?

 

Do they talk to every programmer on the team about how to build their side of the codebase or is this abstracted away from the other programmers?

 

What exactly would they talk about before writing a single line of code?

 

How do they put the codebase together before writing a single line of code if they never written the code before? 

 

What is the process like? Is it necessarily

 

1) communicate some. write pseudo code on whiteboard to spot bad code design.

2) everyone build their side of the codebase

3) merge the codebase together

 

Repeat the above steps

 

Since I never worked on a team before, understanding how a team of programmer works in terms planning and approaching the codebase design of a game would be super useful to me. It would probably make me a better programmer so my code can actually work well with the other programmer codebase.

 

On a side note: When does one start joining a team? How many games does one need to write before joining a team to gain team experience? I heard joining a team can be pretty complicated.

 

I made 5 games so far in a year time(the role playing game being the most complicated thing I have ever done The DialogueSystem being the most complicated I ever build for a game and took many days before it worked the way I wanted it to work despite some improvement that can be made on the code design ).

 

I feel I have much to learn before joining a team. I fear I need team experience before I can join the game industry as a game programmer intern.

 

Any feedback about the above would be appreciated. biggrin.png


Edited by warnexus, 31 January 2014 - 09:36 PM.


Sponsor:

#2 TheChubu   Crossbones+   -  Reputation: 3600

Like
2Likes
Like

Posted 31 January 2014 - 09:55 PM

Have you read a bit of systems engineering? System analysis? Requirement engineering? UML? Software lifecycles?

 

There are a lot of moving parts on project planning. And for software development, there have been a lot of things made to start planning and experimenting without writing a single line of code.

 

For example, this "parameter passing" is something you would define in an UML class diagram (having beforehand established each class responsibility and collaborators), you'd define what fields such class would have and what methods it would need to fullfil its responsibility.

 

But what if you don't clearly foresee all the methods you might need? Well, there are sequence diagrams that can demonstrate all the "messages" the different objects would need to know to make a certain interaction with the system work.

 

All of this is often interweaves with other methodologies (not so much about planning but development, like the trendy "agile" methodologies).

 

Most often not all of the programmers are involved in this process, programmer do the coding, the grunt work, software design is a different thing altogether, in these design processes is where software architects are involved, not all programmers.

 

In short, "planning" is a very broad subject, you can do lots of it before starting to code, and there are been lots of people studying exactly what you're asking, how to do software planning.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


#3 L. Spiro   Crossbones+   -  Reputation: 11881

Like
21Likes
Like

Posted 01 February 2014 - 12:02 AM

This is one of those questions that should never be asked.
The main reason being, “If you have to ask, you will never know.”
The second reason being that there is not a lot anyone else can do to help you here. It is extremely subjective.

A coworker recently expressed exasperation on a similar subject and after asking for some help he found out that I get a whole mental image of how all the interconnected parts work before I code anything. As he began to praise me for being able to hold that all in my head without drawings etc., I told him to sit down and shut up. I translate things into a format that works for me, and it won’t work for anyone else. And the downside to the format that works for me is that I can’t understand UML diagrams at all. There are a lot of things that others grasp easily that I simply don’t.

A very simple example:
In a UML diagram, arrows point the wrong way.
A base class points up to the class that inherits from it.
Whose idea was this? How does this make sense in any universe? “I inherit from you, thus I take properties from you, thus the arrow should point from me down to you.” This makes so much sense to me I can’t see it any other way, but whatever idiot who designed UML decided, “You inherit from me, thus I give you properties, thus the arrow points from me to you.”


The only way to answer your question is to not answer it.
While my world view may not be compatible with UML, I have figured out how to get by; so has everyone else whose views are different from mine.
Even if we did answer, what are you going to do? “Okay I’ve thought about it for 10 minutes now. Oh shit I was only supposed to think for 9 minutes.”
Get real.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#4 frob   Moderators   -  Reputation: 18363

Like
11Likes
Like

Posted 01 February 2014 - 01:19 AM

I think L Spiro got to the heart of the matter.
 
 
>> are there situations that results in too many "parameter passing" from one class to the class the programmer wants to be in?

Sure. A quick refactor fixes that. Don't think about it.
 
>> I also want to know the thought process of how game programmer think or approach a codebase they are about to write.

Read the designs, talk to the designer. Use your own brain and make up your own plan, iterate with the designer, and do whatever you want. It doesn't matter what other people do.

>> Do they write psuedo code just to spot as much future problems in implementing a feature that would make their life easier?

Some people do. If it works for you then do it. If not, do whatever helps you.
 
>> Do they talk to every programmer on the team about how to build their side of the codebase or is this abstracted away from the other programmers?

Approximately never. There might be team meetings about broad design concerns, but they are rare and typically only during the first phases of development. After that there are discussions between individuals working on common code, or between the leads and the implementers.

>> What exactly would they talk about before writing a single line of code?

Whatever they think is useful.

>> How do they put the codebase together before writing a single line of code if they never written the code before? 

That's why you have experienced people on teams, and why they ramp up from a small group of highly experienced experts to larger groups of general programmers.
 
>> What is the process like? Is it necessarily ...

Not usually. Designers make designs. Producers and team leads discuss the design, iterate over them, discuss the costs of the ideas, and eventually resolve on a design that mostly works okay. Then designers take the designs to the people who will implement them repeat the process, and make adjustments. Then the implementers just do whatever works to implement the design they agreed on.
 
>> When does one start joining a team? How many games does one need to write before joining a team to gain team experience? I heard joining a team can be pretty complicated.

The day you are hired in the workforce you are part of a team. Somebody is assigned to help mentor you, get you set up, and hold your hand until you get comfortable. The more experience you have the less hand-holding is expected. Entry level workers may get 3-6 months, senior-level workers get 3-5 weeks before hand-holding ends.
 
>> I made 5 games so far in a year time(the role playing game being the most complicated thing I have ever done The DialogueSystem being the most complicated I ever build for a game and took many days before it worked the way I wanted it to work despite some improvement that can be made on the code design ).

Good. Put it down on your resume under "personal projects", if you weren't paid for it then it doesn't count as work experience. 

>> I feel I have much to learn before joining a team. I fear I need team experience before I can join the game industry as a game programmer intern.
 
You have a stronger background than many others who have joined the industry. Your fear is listed in Tom Sloper's site in the list of stupid wannabe mistakes: stupid overpreparedness.
Check out my personal indie blog at bryanwagstaff.com.

#5 lask1   Members   -  Reputation: 623

Like
1Likes
Like

Posted 01 February 2014 - 02:09 AM

At my work we always try to structure things out before we begin coding...of course you can not catch everything! We also are mostly working with php and mysql when working together and planning.

It looks like you have some of theright ideas and im wonderimg if you are gettimgto the point where you should be working with a small team on a small project to continue your learning.

I also am not sure if you are familiar with using git but it might be worth your time taking a look at learning it for a version control system while working in a team. I say this cause eventually you will run into version control and will need a way to merge with your other team members code.

I guess I didnt answer anything reslly specific but I hope you find my post useful.

#6 Poigahn   Crossbones+   -  Reputation: 516

Like
4Likes
Like

Posted 01 February 2014 - 03:23 AM


This is one of those questions that should never be asked.

If a leader never ask for input, Then they never have any opinion or idea other than their own!  I think all of his questions are relative, Maybe not to me but definitely to the asker. Thus, no answer given should be taken as final, just food for thought.

  When working on any project, after the project is defined, I like to make notes on a large index card for different parts.  As with most games, you will find a core set of functions and data parameters.  What comes to mind in a roleplaying to me first are the PCs & NPCs.  Figuring out what they can and cannot do will help define some of your programming requirements ( 1 small step ). By putting these definitions onto 1 or 2 index cards you begin to develop some flow.  < At least this works for me!  You will have to find what works best for your team, this may be a "Trial & Error" type system.

  Older programming teams used to develop a "Top Down" program Flow Chart.  I find now, for me, a core design with many outflows and returns type "Road Map" presents a better representation of a program, Like the Circle of traffic flow around the "Arch de Triumph" roadway in Paris.


In a UML diagram, arrows point the wrong way.
A base class points up to the class that inherits from it.
Whose idea was this? How does this make sense in any universe? “I inherit from you, thus I take properties from you, thus the arrow should point from me down to you.”

 Maybe I am reading this wrong, but is this not the same thing, with the flow pattern inverted.  If I inherit from you, should not the arrow point from you to me ?


Since I never worked on a team before, understanding how a team of programmer works in terms planning and approaching the codebase design of a game would be super useful to me. It would probably make me a better programmer so my code can actually work well with the other programmer codebase

Everyone will have strengths and weaknesses and their own ideas.  When working with a team, and leading a team, I think it would function much better as a team if everyone feels they were able to contribute to the team.  Get input and ideas from everyone.  Discuss everything.  Keep an open mind!!  Come to a consensus, Not everyone will get want they want, but if they feel that they were at least listen to, they will more likely give a better effort.  Remember, the team leader has they final say on what direction to go.

  The Team leader should also be ready to take "Full Responsibility" for anything that goes wrong, and "Share Credit" for when it goes right.


Your Brain contains the Best Program Ever Written : Manage Your Data Wisely !!


#7 kseh   Crossbones+   -  Reputation: 1788

Like
3Likes
Like

Posted 01 February 2014 - 04:20 AM

In general, I believe confidence is the quality that you're trying to identify (not to be confused with arrogance). Confidence that what you're about to write will do what you want it to and that it will be as extensible as you need it to be. Also instilling that confidence, most likely by communications in writing (design docs, diagrams, whatever), in your co-workers and clients. It may be that confidence comes from discussing things with co-workers or clients or it might come from research, experimentation, or past experience.

 

That is not to say that confidence will necessarily generate a result that follows best practices. Of course this is also a desirable quality but I don't think it could come without the experience of writing code.



#8 ZeroBeat   Members   -  Reputation: 511

Like
6Likes
Like

Posted 01 February 2014 - 05:09 AM

Doing something for the first time is always the hardest.

Hence no amount of planning can trully prepare the developer for a solution to the problem. 

 

Planing/Design is a very subjective thing.
Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better. 

Rather than having talks with people of what could be and what not.

 

Sometimes there will be a lead designer/programmer who will decide how things will work.....

Some people are very visual, some are less.. so some tools for planning will not be equally effective to get the point accross the whole team.

 

Its really dependents on the team of individuals and how their work well together.  Once one member wrote a design in psuedo code and I just expanded it

while he was expaining to me what he wanted the code to do.

 

Sometimes a whole task is given to an individual with pre-defined list of tasks the code needs to do. eg write the whole MySQL code to get the data from a database.

 

I guess what I am trying to say is, as soon as possible try to get some experiance working with other people and you will understand smile.png.


Edited by ZeroBeat, 16 May 2014 - 04:04 AM.


#9 richardurich   Members   -  Reputation: 1187

Like
0Likes
Like

Posted 01 February 2014 - 06:43 AM

Others covered that there is no magic approach used in planning, but I want to urge you to fail. You're holding yourself back trying to avoid failure, but failure is part of success. My previous job was obtained by failing at the interview, but impressing just one manager so much that he created a position for me. And it was a way better job as a result. It didn't really have a job description, so I just got to do insane and amazing stuff without worrying if it was in my job description. I got to work with the driver guys, the UI guys, QA, the build team, the team in India, and everyone in between. Most projects I've worked on failed to achieve the original goals, but still succeeded in achieving amazing results. Every bug I ever closed involved failing on every single solution attempted except the final one.

 

So start working with teams even if you don't think you're ready. Apply for every job you think would be a blast whether or not you meet the qualifications. And tell people straight up that you don't have the experience yet, that you're going to make mistakes, that you're going to learn a lot as you go, but that you're going to work your ass off to make up for it, and you're going to love the work and the challenge.



#10 Olof Hedman   Crossbones+   -  Reputation: 2617

Like
0Likes
Like

Posted 01 February 2014 - 09:13 AM

I never write proper UML.

 

I do though often write boxes with arrow between them to map out classes and dependencies.

 

It borrows from UML, but I basically just use 3 kinds of arrows. inheritance, component (class directly owned by another class) and general more loose "depenceny" (dashed arrow). 

 

For all of them though I read them as "A depends on B", and then all the arrows go the right direction in my mind...

 

I find it easier and more persistant to have it on file, and it helps to spot when where and how to refactor.

 

It's very much a living document in the beginning of a project, until the general infrastructure of it all solidifies.

 


Every bug I ever closed involved failing on every single solution attempted except the final one.

 

How could it be any other way? :)



#11 warnexus   Prime Members   -  Reputation: 1368

Like
0Likes
Like

Posted 01 February 2014 - 11:45 AM

Others covered that there is no magic approach used in planning, but I want to urge you to fail. You're holding yourself back trying to avoid failure, but failure is part of success. My previous job was obtained by failing at the interview, but impressing just one manager so much that he created a position for me. And it was a way better job as a result. It didn't really have a job description, so I just got to do insane and amazing stuff without worrying if it was in my job description. I got to work with the driver guys, the UI guys, QA, the build team, the team in India, and everyone in between. Most projects I've worked on failed to achieve the original goals, but still succeeded in achieving amazing results. Every bug I ever closed involved failing on every single solution attempted except the final one.

 

So start working with teams even if you don't think you're ready. Apply for every job you think would be a blast whether or not you meet the qualifications. And tell people straight up that you don't have the experience yet, that you're going to make mistakes, that you're going to learn a lot as you go, but that you're going to work your ass off to make up for it, and you're going to love the work and the challenge.

I would not say I never failed. Every feature I wanted to get right in my rpg game was a failure because it never works the first time. It was only after many hours of thinking was I able to improve the code design and got the feature to work. 

 

Great tip! Thanks!



#12 L. Spiro   Crossbones+   -  Reputation: 11881

Like
0Likes
Like

Posted 01 February 2014 - 07:45 PM

Maybe I am reading this wrong, but is this not the same thing, with the flow pattern inverted.  If I inherit from you, should not the arrow point from you to me ?

UML being just an example to illustrate a point, I am not willing to go too much further with it, but I will at least just respond to this.
This is exactly my point. The mental image you have constructed tells you to have the arrow pointing one way, while my image tells me it should be pointing the other way. I think the arrow should indicate what is being taken, but you think it should indicate what is being given.

Obviously I’ve learned to deal with it, but the conversion process from one line of thought to my native line of thought takes time, and that is the end result any time you tell anyone else how to think.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#13 Trienco   Crossbones+   -  Reputation: 2038

Like
0Likes
Like

Posted 02 February 2014 - 12:16 AM

Every UML diagram I've ever seen has inheritance arrows point from the derived class to the base class. If you have co-workers that do it the other way round, hit them over the head with the thickest UML book you can find.

 

In terms of planning, don't overuse UML. It's neat to "get the point across", but to do that, you need just a very basic subset. No point in cluttering up a diagram with tons of obscure symbols to describe unimportant details. Nobody will want to look at that complicated mess and that's where the whole point of using UML in the first place is utterly defeated. For the most part, I'd stick with class diagrams and flow charts.

 

Tempting as it might be to just start hacking away to get stuff to show up on screen, nail down as many requirements/features as you can in advance. Adding stuff to a code base that isn't prepared for it tends to be messy. At the same time, trying to prepare it for everything you imagine may or may not be needed 10 years from now is even worse.


f@dzhttp://festini.device-zero.de

#14 Felix Ungman   Members   -  Reputation: 888

Like
0Likes
Like

Posted 02 February 2014 - 03:27 AM

If I understand the question of the OP, it's how to deal with the problem of bad dependencies in code, especially working in a team.

 

There's a lot of written material on agile development, but I think the key here is communication. A large enough system will consist of several subsystems, and this usually makes for a natural division of labor. Team planning should focus on the boundaries between the subsystems, because these are the large scope dependencies. 

 

A little planning will help you avoid some of the bad dependencies. But more importantly, you have to constantly keep looking for them, and take the time to refactor the code whenever they pop up. It's just as important as fixing bugs.

 

As for UML, I find it invaluable for high level brainstorming, and worthless for low-level specification. As for the arrows, it's only a language, like some feel subject-verb-object order is more natural while others prefer object-subject-verb.


openwar  - the real-time tactical war-game platform


#15 L. Spiro   Crossbones+   -  Reputation: 11881

Like
3Likes
Like

Posted 02 February 2014 - 04:05 AM

classdiagramno3d.gif

 

This means something to someone, but that someone is not me.  I have no clue what is happening here.

 

Which way the arrows actually point in a UML diagram is beside the point; I just recall them rubbing me the wrong way (or perhaps because base classes are displayed above inheriting classes, which is a fundamental violation of the idea that base classes are below their superior classes) and if a “superior” was to impose them upon me then it is exactly the same as asking me to reduce my efficiency by half.

 

We all have our own way of thinking.  That is the lesson the original poster needs to understand.

 

 

L. Spiro


Edited by L. Spiro, 02 February 2014 - 01:03 PM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#16 Felix Ungman   Members   -  Reputation: 888

Like
0Likes
Like

Posted 02 February 2014 - 04:54 AM

There's a different between thinking and communicating. If a superior would impose UML it would be for communication purposes, and it's what UML was designed for. One of the key features of UML is precisely the arrows, which represent the various kind of dependencies that occur in a complex system, and I think that's why it's was brought up here.

 

UML is just a language, and it's efficient for some purposes, but not for others. I find it easy and natural to think in UML but thats me, and just because I've been doing it for a long time. But again, in a team environment communication is important, and it's only possible with a common language, whatever that language may be.


openwar  - the real-time tactical war-game platform


#17 Poigahn   Crossbones+   -  Reputation: 516

Like
2Likes
Like

Posted 03 February 2014 - 05:29 AM


This is exactly my point. The mental image you have constructed tells you to have the arrow pointing one way, while my image tells me it should be pointing the other way. I think the arrow should indicate what is being taken, but you think it should indicate what is being given.

This is the point of this thread.  Everyone will have separate opinions on how things should be.  This is fine as long as you are working alone, you can have things the way you want.  While I respect your point of view, you should also respect mine.  As part of a team, the direction of the arrow could be part of the planning discussion.  If the group decides, based upon your vast experience, (which I am willing to concede) or your leadership qualities that having the arrow point your way is better, I am fine with that.  If not then maybe I should not be part of the team.

  This is why you need to have team meetings,  everyone needs to be on the same page, or you will be singing 1 song while the choir sings another.

In the end, it is all positive.


Your Brain contains the Best Program Ever Written : Manage Your Data Wisely !!


#18 Hawkblood   Members   -  Reputation: 712

Like
0Likes
Like

Posted 03 February 2014 - 11:45 AM

Nothing beats your own experiences in determining how much forethought and planning you need before you start the actual programming process. With that said, I would start with the basic premise of the application: List the features that you would like to have, categorizing them into “needs” and “wants”. Weed out the “wants” until you get something manageable—keeping in mind that some of the “wants” you weeded out can be placed back into the final product. At this point you should make a structure that everyone in the team can understand—this is the key. Now you are ready to code. How much detail involved in the planning phase is up to the team. Don’t let any convention block you from starting you coding.

#19 warnexus   Prime Members   -  Reputation: 1368

Like
0Likes
Like

Posted 03 February 2014 - 06:12 PM

Nothing beats your own experiences in determining how much forethought and planning you need before you start the actual programming process. With that said, I would start with the basic premise of the application: List the features that you would like to have, categorizing them into “needs” and “wants”. Weed out the “wants” until you get something manageable—keeping in mind that some of the “wants” you weeded out can be placed back into the final product. At this point you should make a structure that everyone in the team can understand—this is the key. Now you are ready to code. How much detail involved in the planning phase is up to the team. Don’t let any convention block you from starting you coding.

I see. Thank you!



#20 Subtle_Wonders   Members   -  Reputation: 225

Like
0Likes
Like

Posted 10 February 2014 - 12:31 PM

Despite the planning, are there situations that results in too many "parameter passing" from one class to the class the programmer wants to be in?

 

As a self taught game programmer who has been writing the codebase for one month and 2 weeks for a role playing game, I also want to know the thought process of how game programmer think or approach a codebase they are about to write.

 

Do they write psuedo code just to spot as much future problems in implementing a feature that would make their life easier?

 

Do they talk to every programmer on the team about how to build their side of the codebase or is this abstracted away from the other programmers?

 

What exactly would they talk about before writing a single line of code?

 

How do they put the codebase together before writing a single line of code if they never written the code before? 

 

What is the process like? Is it necessarily

 

1) communicate some. write pseudo code on whiteboard to spot bad code design.

2) everyone build their side of the codebase

3) merge the codebase together

 

Repeat the above steps

 

Since I never worked on a team before, understanding how a team of programmer works in terms planning and approaching the codebase design of a game would be super useful to me. It would probably make me a better programmer so my code can actually work well with the other programmer codebase.

 

On a side note: When does one start joining a team? How many games does one need to write before joining a team to gain team experience? I heard joining a team can be pretty complicated.

 

I made 5 games so far in a year time(the role playing game being the most complicated thing I have ever done The DialogueSystem being the most complicated I ever build for a game and took many days before it worked the way I wanted it to work despite some improvement that can be made on the code design ).

 

I feel I have much to learn before joining a team. I fear I need team experience before I can join the game industry as a game programmer intern.

 

Any feedback about the above would be appreciated. biggrin.png

To answer your question, it is best that you become familiar with the SDLC (Software Design Life Cycle) and the AGILE-Scrum process of this cycle, including what stories, sprints and backlogs are.

 

There is something called the Technical Design Specification. It is a book, created by the designers and in part, the developers of the SDLC. It encompasses just about every diagram you can think of: Use Case UML, High Level Class Diagram UML, Database Design, ERD, Dataflow Diagram - Flow Charts.

 

Before a single code is worked on, the Technical Design Specification should be completed. The reason is because of the first page of this book, being the contents regarding its Purpose and Description of the Requirements.  In a nut shell, if either the Purpose or the Requirements are breached or not met, then you either have one really passive and generous client or... you can't adequately define your sprints, which results in project failures (and people start losing their jobs and companies start losing a lot of money). All the pages there after the first page, break down what the program should do.  And that breakdown, allows a sprint log to be created, which allows management for the overall project.

 

As a one man programmer, yes, you can get away with not using this.  As a two or three man programmer, you might be able to get away with not using this. But as the numbers increase, so does the unlikeliness of succession from not using the Technical Design Specification.

 

 

Hope this helps.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS