|
Are you sure you actually need to keep the assets (storage) separated? Functionality, which you mentioned, isn't really a reason.
Just stating that because MTA is difficult to implement.
|
|
|
|
|
I have used the N-Tier architecture approach where the Business Layer delivers the client specific requirements. You could use the Decorator Pattern to complete.
Thanks
JD
http://www.seitmc.com/seitmcWP
|
|
|
|
|
I have client specific overrides for business rules. We run the industry standard & compliance related rules first and then the client specific rules. We are currently having main biz class having the standard rules and client specific rules as a decorator over that. Then we detect the client id passed and load the appropriate decorator.
Assets are loaded through a CMS due to different branding elements.
|
|
|
|
|
Hello,
I'm wondering about the logic behind Tribalwars, Travian, and similar browser games.
Basically, how to time an action, how to use DB to store those, handle sch a massive number of actions in DB and clients, use service vs a program or the website itself to handle the back-end requests after the time comes, and how actually to realize that the time came.
Note: I'm not asking about the programming language or DB type, Just the logic behind this.
Take this topic as a brainstorm topic to get the best ideas.
Thanks in advance
|
|
|
|
|
Have a look here[^]
Veni, vidi, caecus | Everything summarizes to Assembly code
|
|
|
|
|
The question isn't clear.
The games are just applications just like any other application. There are specific technologies and methodologies used to achieve that.
And doing it requires that one learn about those. Doing it well requires that one learn about other technologies as well so that one can choose the best ones to implement it.
In general the term used to describe what the above encompasses would be referred to as the "architecture".
Member 10508854 wrote: Take this topic as a brainstorm topic to get the best ideas.
Large games will not work unless one knows quite a bit. So the best idea would be to start learning the basics of some technologies including databases, web server architectures and perhaps browser based user interfaces.
|
|
|
|
|
Hi all!
I'm working on a UML / ER modeling tool, and I need some opinions.
My C# solution currently has the following projects/assemblies:
Core - defines basic stuff like logging, a hierarchy of elements (and operations on that hierarchy), what a model is, and that a model may contain model elements
Content - defines subclasses of model element, ie concrete stuff that a model may contain, like Class, Attribute, Table, Column, and how these elements relate to each other
Engine - defines operations on the content, for example building a model from an external file, conversion from conceptual model (classes) to ER-model (tables)
ViewModel - an MVVM implementation
Application - A WPF UI.
Random comments:
- Most classes in Core, Content and Engine are public, because ViewModel needs direct access to them.
- I want to somehow define Services provided by Engine. ViewModel will call these services.
- This will be a desktop solution, but I might want to make it browser-based later. Would it in that case make sense to implement the "services" using MCF, which I'm new to?
- I am currently not using interfaces (as in public interface IMyInterface {}) for the purpose of handling dependencies between assemblies.
So my "problem", then. Content references Core. Engine references Core and Content. ViewModel references Engine, Core and Content. This just doesn't seem like a working separation. I'm just now starting on the Application level, and I notice it will definitely reference ViewModel, but that I also potentially need to introduce elements to both Engine and ViewModel that should be available to ViewModel and Application (Commands and services). So I feel I need to redesign a bit. The question is whether to split more (create CommonXXX -assemblies containing, for example, interface declarations used by other assemblies) or to combine assemblies. I think combining in this case makes more sense, although I generally like to split things.
Engine operates directly on Core and Content objects, so it might make sense to combine these three into the same assembly, as they are really quite tightly integrated. In that case I could make all classes non-public, and publish them for ViewModel to use through interfaces. Then the question is whether these interfaces should be declared in a Common assembly or in the same assembly as where the implementing classes reside.
An attractive alternative to publishing the data objects using interfaces: I thought I might allow selective access to data objects and services through scripting, in which case I could have wrapper "API" objects (think Engine returns new ClassAPI(aClass)). These would be declared in the current Engine assembly, and the view model objects could then use those instead of the actual data objects defined in the Content assembly. Then I could implement a scripting language which could use reflection to access all the API objects' methods and properties. Using these API objects, I could easily publish, for both scripting and UI, any aspects of the core data classes (and "services" as methods) I want/need, and I would not need any separate interfaces, and there would be no need for currently public Core/Content/Engine classes to be public.
So, after a possible merge I would then have:
Core - Defining both data model and services, contains old Core, Content as well as Engine. Either the "API layer" or some sort of service implementation, or a combination of these, would be the only public view into this assembly.
Common - Stuff like Logging and genuinely commonly used items, possibly including interface declarations
ViewModel - Uses Core's API or service layer, and some Common elements
Application - the WPF UI
Sounds better, or does it?
If this admittedly superficial description evokes any kind of reactions, I'd really like to hear them
Cheers,
Kim
|
|
|
|
|
Hi Kim,
It is a bit difficult to give you some concrete advice, but here are my thoughts. I think they are classic 3 tier'ish.
The easiest is the lower layer aka the data layer e.g. a simple API that stores data types in a storage (memory, disk, db, whatnot). This can certainly be within its own project (with its own unit tests) - it doesn't need commands or similar. For abstract data classes, etc. I prob. would make a "Core" namespace within this project.
Another easy layer is the top layer aka the UI layer. Whether or not you tie the Application together with the UI layer in 1 assembly/package is a flexibility matter. In any case I would probably make a "Core" namespace within this layer too, but it has nothing to do with the data layer classes - only the UI.
The hardest part is how you design control from the top layer to the data layer and how the top layer is updated indirectly by updates in the data layer. In MVC its the C, in SOA it is the services. I would create a middle layer aka the service layer that knows the data layer, but doesn't know the UI layer. In here you can make a lot of Controllers e.g. Commands that modifies the data layer. If you have a pull design, you can make some poll/query commands too. If you have a push design, you can register a general listener pattern that the UI layer can use, or fire commands going upwards to be consumed by the UI layer (not so popular in these client-server days). This middle layer also will have its own "Core" namespace with abstract Commands and whatnot.
In above way you have a very clean division. It is pretty simple to avoid dependencies from the data layer to others, and it is doable to avoid a dependency from the control layer to the UI layer. One thing to consider is, if the UI layer should have direct access to the data layer. I find this decision hard to make - many cons and pros.
If it makes sense for you to have a common assembly then go make that and let the 3 layers depend on that. Otherwise, just pull in logging, etc. in each layer. A common layer can easily mud your clean dependencies; before you know it there is a utility class that knows how to calculate some business data and it is used by both the UI and the Data layer.
I hope it makes sense and triggered some thoughts.
Kind Regards,
Keld Ølykke
|
|
|
|
|
I'm not a project manager, i'm just a developper. But i wanna know yours opinion for coding together in a team. Here will listes my coding habits which i think is good. This article is partially on the opposite of another article of mine "Several Easy WPF Teamwork Tricks"
Unify naming convention. We'll encounter some Here is a paragraphe of the reply of a friendly member of CodeProject :
While some people may not like switching coding styles, it does not take very long to get used to coding a different way. There is a huge benefit to having a standard coding style. On my development team, we adhere to a somewhat strict coding style. It doesn't matter what file you look at, it is written the same as every other one. It is very easy to read other peoples code since it looks like your own. I know immediately when I look at an identifier whether it is a member field, public property, or local variable without having to go search for where it is defined. If I did have to search for where it is, it would be in the same spot in the file as it is in every other file because there is a standard.
Unify comment humain language. I'm a Asian guy who lives in France. My main language is not french nor english. But i read only English technical books and i speak French everyday. It's sure that i don't write Chinese in my project because all my other collegues won't understand it. But should we comment with English ? Or French (Native humain language) ? One point i'm sure is that comment with both English and French could be a very terrible thing. (At least, it makes me very angry sometimes).
Version control of third party libaries. I use DevExpress, mysql and so on in my project. I'd like to update them once they published their new version. It cause sometimes a very big change in my project. But i'd prefer to update it all the time. Because we can track its changes without missing some important things. But if work with team? I think we should negociate it. I prefered to suggest them to update versions frequently. Because we can always keep the same version for the same project. I know it cause us lot of work in every update.
Length of Method. I don't like methods which contains more than 30 lines. It makes code urgly. It's my style. Because i found that it's more clear when we read method with less than 30 lines. We could find the function module quickly. We watch a function module with F12 instead of scroll our mouse. Method's name could also be used as a comment. It sometimes forced us to write more reusable methods.
public void RunSome()
{
try
{
if (!PrepareEngin()) throw new Exception("No usable engin");
if (DoWeHaveAnCat())
{
PlayWithCat();
}
else if (GoToBuyAnCat())
{
RunSome();
}
}
catch (Exception exp)
{
throw exp;
}
}
private bool PrepareEngin()
{
return true;
}
private bool DoWeHaveAnCat()
{
return true;
}
private void PlayWithCat()
{
}
private bool GoToBuyAnCat()
{
return true;
}
Don't have too many empty line in a method. It wastes my time to read it and positionning!
A teamwork should be harder than a solo work. I'll work with a team in 2014. I'm not project manager, but i wish we'll have a good 2014
History
An opposite article of mine ("Several Easy WPF Teamwork Tricks") was criticized by members. I'accept that it wasn't a good article. But it's also an other way of thinking.
modified 7-Jan-14 2:21am.
|
|
|
|
|
comiscience wrote: Unify naming convention. Guidelines for Names, .NET Framework 4[^]
comiscience wrote: Unify comment humain language English.
comiscience wrote: Version control of third party libaries. Yes.
comiscience wrote: Length of Method. The compiler does not care about ugly, I not about your style. If it breaks the single-responsibility principle, it's probably a candidate for refactoring.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi, thanks for your suggestion
But how could you read other's code which has 100 lines more in a method? It wasted me lot of time to scroll and positionning..
|
|
|
|
|
comiscience wrote: But how could you read other's code which has 100 lines more in a method? With a sad face.
Then I'd refactor the code, and ask the other if the change is acceptable. The compiler doesn't care about the length, nor do I - but I do care about readability and maintainability. Code that's complex is harder to support, so one would strive to keep it as simple as possible (one responsibility!)
Sit down with the other, and take the time to make it more readable; it'll help the other with writing better code, will lower your frustration-level, and will lower the cost to support the code, since simpeler code contains less bugs. Demanding that a method has a maximum length of, say, 10 lines would simply mean that coders start to divide that code over multiple methods that get called consecutively. You'd end up with the same code, but now divided over multiple methods.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks Eddy
|
|
|
|
|
Install StyleCop across the team, and adjust its rules to suit the team. Then make sure that people review the output - I find that running it as part of the CI process is a great way to pick things up, plus it could form of your code review checklist. I'm pleased to see that you dropped your stance on not commenting - meaningful and well maintained comments are an absolute must.
|
|
|
|
|
|
Refering to the following two pair of classes:
public class Person
{
protected string ssn = "444-55-6666";
protected string name = "John L. Malgraine";
public virtual void GetInfo()
{
Console.WriteLine("Name: {0}", name);
Console.WriteLine("SSN: {0}", ssn);
}
}
class Employee : Person
{
public string id = "ABC567EFG";
public override void GetInfo()
{
base.GetInfo();
Console.WriteLine("Employee ID: {0}", id);
}
}
public abstract class animal
{
protected string ssn = "Poultry";
protected string name = "Mostly flying creatures";
public abstract void GetInfo();
}
class Seagull : animal
{
public string id = "ABC567EFG";
public override void GetInfo()
{
Console.WriteLine("Name: {0}", name);
Console.WriteLine("SSN: {0}", ssn);
Console.WriteLine("Specimen ID: {0}", id);
}
}
Implementing them:
Public class A2Implementation {
public A2Implementation()
{
Employee E = new Employee();
E.GetInfo();
Seagull A = new Seagull();
A.GetInfo();
}
Question
I get the exact same result in the implementation of the two pairs (unclear, albeit intentionally).
Now what are the pros and cons of using an abstract definition here (the animal-Seagull track), or what is best; just using ordinary base class Access (the Person-Employee track)?
Could I be mistaken in assuming that there is a concordance here.
modified 5-Jan-14 4:48am.
|
|
|
|
|
Not sure what you try to achieve, but from the example you made it's clear that the base-class approach is better for you.
When using abstract class you was unable to put Name and SSN into the abstract (no room for this), but if these properties are common to all then it's much better to put it in some base (that's why it called base!)...
|
|
|
|
|
Alright. I've managed to cram it in there, the abstract Properties, and I've changed the Whole lot to look a lot more similar With regards to content. Now here is what I got:
public class animal1
{
protected string name1 = "Poultry";
protected string ssn1 = "Mostly flying creatures";
public virtual void GetInfo()
{
Console.WriteLine("Name1: {0}", name1);
Console.WriteLine("SSN1: {0}", ssn1);
}
}
class Seagull1 : animal1
{
public string id = "ABC567EFG";
public override void GetInfo()
{
base.GetInfo();
Console.WriteLine("Specimen ID: {0}", id);
}
}
public abstract class animal2
{
public abstract string name2 { get; }
public abstract string ssn2 { get; }
public abstract void GetInfo();
}
class Seagull2 : animal2
{
public string id = "ABC567EFG";
public override string ssn2
{
get { return "Mostly flying creatures"; }
}
public override string name2
{
get { return "Poultry"; }
}
public override void GetInfo()
{
Console.WriteLine("Name2: {0}", name2);
Console.WriteLine("SSN2: {0}", ssn2);
Console.WriteLine("Specimen ID: {0}", id);
}
}
The implementation and output follows:
public class implementation
{
public implementation()
{
Seagull1 E = new Seagull1();
E.GetInfo();
Seagull2 A = new Seagull2();
A.GetInfo();
}
}
Resulting text output:
Quote: Name1: Poultry
SSN1: Mostly flying creatures
Specimen ID: ABC567EFG
Name2: Poultry
SSN2: Mostly flying creatures
Specimen ID: ABC567EFG
It seems to me that the use of abstract classes in this case is redundant, and the first track is sufficient, let alone more efficient. I am wondering then when the abstract classes kicks in with their possible advantages?
Could it be, if I introduced the Penguin which is not able to fly, that the flyingability becomes an issue urging the use of abstract classes?
modified 5-Jan-14 9:18am.
|
|
|
|
|
It get me back exactly to the same point...
netfed wrote:
public virtual void GetInfo()
{
Console.WriteLine("Name1: {0}", name1);
Console.WriteLine("SSN1: {0}", ssn1);
}
This code is common to all classes based on animal1 , you never write it again.
In the abstract version you have an empty GetInfo method (it's abstract so it must be empty!), and in every instance inherits this abstract class you must implement Name and SSN ...
You see base classes used when you have a certain amount of common functionality that known. Abstract class are more like interfaces as they declare the structure of the class inherits them, with the addition of some common functionality...
Again - based on your sample base class is better for you...
|
|
|
|
|
Abstract class provides you with an option to declare a non-instantiable base class from which your concrete classes inherit. You cannot instantiate an abstract class, you must instantiate one of your concrete classes.
But if you wish to be able to instantiate the base class, then do not declare it abstract. If there is shared logic that can be generalized, use an abstract base class. If the base set of functionality is complete on its own, then you can use a concrete base class.
|
|
|
|
|
Well yes. But what would be really cool is, if someone would be willing to take the time, to suggest a new code block, which could show where the abstract track is better. Anyone?
|
|
|
|
|
There are plenty of example explanations of this all over the internet.
Veni, vidi, abiit domum
|
|
|
|
|
This[^] article might help you.
|
|
|
|
|
Thanks for that link. The article showed some variation there in the end, that brought in some ideas on how abstract classes could be useful (the IEnumerable). I think I will play With several code blocks and compare the use of them. I will read some books on the subject.
I can also now can conclude on of my problems:
- abstract classes without any implementations just look like Interfaces
- It seems to me that using abstract classes in a small context is shear silliness, but in a larger "code-stretch" they are beneficial, as my second code post and it's answer shows.
- A class that inherits from an abstract class cannot access the original implementation of a method
modified 12-Jan-14 7:29am.
|
|
|
|
|
Quote: A class that inherits from an abstract class cannot access the original implementation of a method
Actually it can, just call base .MethodName(...) to call the base implementation, even if you have overridden it. Works for overridden properties too.
|
|
|
|
|