A few design questions...advice request

[Mideon]

A few design questions...advice request

I've recently become interested in the XNA framework, and had been working on a RunUO shard for years up until recently, and wanted to explore the potential of expanding the current concepts of the open sourced UO client developed on the xna framework.

People such as Chase, Popicola and Jeff have done some outstanding work, and I'm interested in starting out on a client as well. I realize this sounds as another "I want a client so ima lead a leet project to make one in my own image"... and it might very well be, regardless I want this to be a learning experience for myself as much as I wish to develop a quality end project (that being an open sourced UO client based off the xna framework).

I am not a programmer by trade....I'm actually a biologist, who happens to program for a hobby. This forum is full of coding/programming guru's alike so I figured I'd ask this here to get started.

I am currently in the process of diagramming what "layers" I'll require for my client. My goal with this project is to learn some quality coding practices... and I was wondering if anyone knew of any resources I could refer to for "good" client design.

I'm of the current mind that I should separate the graphical, input and networking layers of the client...but I'm wondering if I'm starting off on the wrong foot.

What practices will ensure that my code is readable, easily maintainable (not just by myself, but by anyone who wished to) and easy to modify/extend?

I'm new to higher end program development.....I've basically taught myself C# through designing a UO shard, and while I've learned many interesting design strategies during this... I really want to make sure I start this project off right.

Anyways all help/pointers/links are greatly appreciated.

Thanks

 

[Thilgon]

uhm i don't get what you are asking for...
if it's for the paperdoll layers themselves, i have some ideas, but those depends on what things you want to do...
I had some ideas for that, like having more than 1 layer for the base body, like 1 for the body itself, 1 for the face/head, 1 for tatoos, etc, or, since in the client itself are present "face pieces" for the paperdoll, have an "eyes layer", "mouth layer", etc, and using those bits to give variable expressions to the paperdoll... along that way, would easily be possible to have "arms", "hands", "legs", etc layers to assemble a body in various ways...
For the equipment, there should be some more layers around, like "internal/external waist", "socks layer", and thing like that...

 

[Mideon]

Oh no sorry....I was unclear.

I don't mean anything UO specific. I am just not familiar with good design practices when setting up a client. I just want to know what methods should be used when designing/implementing a client framework...so that it can be easily read/maintained/extended.

 

[Thilgon]

oh i see, in this case i can't be of any help

 

[Poplicola]

I am just not familiar with good design practices when setting up a client. I just want to know what methods should be used when designing/implementing a client framework...so that it can be easily read/maintained/extended.

Jeff would know better, but I believe that every organization, every project, and every individual has their own best practices for setting up a project so that it is easy to maintain and extend.

Ideally each well-named subroutine will be prefaced by a short summary of what inputs it expects, what it does, and what it returns as a result. Each variable should be well named, and lines should be commented when they appear even a little obtuse.

My advice to you would be to download several different XNA projects - RunUO, UltimaXNA, etc. - and then figure out what you like about each project's organization, and what you don't like. Then use these practices in your own work and see how they feel to you. I think that RunUO is well organized - you would do well to use that as your starting point.

Many of my projects just 'grow' organically until they approach unreadability, followed by a whirlwind of reorganization. Thus they are often less than perfectly understandable. But I'm okay with that.