Well, I want to make a certain part of my game design more accessible. In my game you can hire laborer to do some tasks for you. At the moment each laborer has a class which consists of 2-3 skills.
Examples:
- a cook has the skills butcher and cooking
- a hunter has the skills butcher and tracking

As you can see skills are not class unique and you can choose from different classes to get a task done. To make it even worse, each skill has its own level and not every class can max-out each skill. Eventually products, which could be crafted by a laborer, refers to skills and skill levels and not classes, that is, to create a sword you need someone with the smithing skill at level 2.

Although the game is designed for non-casual gamers, I got the feeling that it is getting too complex.

Options which comes to mind:
1. classes,no skills
I get rid of skills and use only classes and laborer "levels": master smith, novice butcher etc.
Pro: very easy to understand
Con: I fear that you need too many classes, classes could be difficult to balance, no variance or choices

2. no classes, only skills:
Each laborer has the ability to learn every skill.
Pro: removed the complexity of classes
Con: you need to remember which laborer is good at which skill, laborer will be divided into 'unskilled' and 'omni-potent'

3. multi-classes, no skills
An extension to 1,but you can combine two classes, i.e. lvl 10 paladin = lvl 5 warrior + lvl 5 healer
Pro: skills are gone, you can directly see that laborer A is a warrior/healer
Con: ??

Any comments, ideas, sugguestions ?

- a cook has the skills butcher and cooking
- a hunter has the skills butcher and tracking [/quote]This "feels" wrong.

I would say, make it like in Pizza Tycoon. Each class has separate group of skills and you can put only the person of a certain class into a certain task.
Only cook can make food. Only waiter can deal with clients. Only manager can boost labourers efficiency. Only guard can deal with misbehaving clients.

They all could get same named stats (like health, motivation) but these are used only for different tasks.

In short, you don't hire labourers but you hire cooks and waiters. These are separate groups that can not be interchanged.

- a cook has the skills butcher and cooking
- a hunter has the skills butcher and tracking

This "feels" wrong.

I would say, make it like in Pizza Tycoon. Each class has separate group of skills and you can put only the person of a certain class into a certain task.
Only cook can make food. Only waiter can deal with clients. Only manager can boost labourers efficiency. Only guard can deal with misbehaving clients.
[/quote]
This would be feasable for a large scale simulation where you need dozens of employees. My game is small scale, I plan to use only up to ~20 employees, on the other hand I got many different tasks (currently >10).

As far as I can see your original idea doesn't really have any classes, the class is just a name for a collection of skills?
If so, then I don't really see a problem with it. It's basically the second option, only with class names to help the player remember what they are good at.

The problem is, that it is too complicated. When you want to train an animal you need the train_animal skill. When you take a look at the employee screen showing only classes, you need to know that a druid,a hunter, and a beastmaster have this skill. The train_animal skill seems quite simple, but other more industrial skills aren't that easy and whenever you want something special you think "hmm... who could provide this skill ...".

If you make it skill based then you could assign class names based on the skills like Dwarf Fort.
A newbie with no real skills is a labourer. If they chop enough wood they become a wood cutter. If they carve then they become a wood carver. they can do anything but the class tells you at a glance their strengths.

The basic idea sounds interesting, thought I'm not a great friend of everyone-can-learn-everything apporach.

At the moment I think about using a simplified multi class approach. One main class and a secondary class. Maybe the secondary class could be limited to crafting classes only.

I'd probably the have it so that all labours can learn any skill but only have on specialty. If all skills go from 0 to 10 then I'd make its the max of none specialty skill was 4 or 5.



The task assignment issue sounds like you just need to fix your ui. When you select a task it would make sense to only seen unassigned workers who have the needed skills order by ability.



You could also potentially add some cross skill bonuses. Every task might have a primary skill required but secondary skills that give a bonus to the task.

[quote name='Ashaman73' timestamp='1310970565' post='4836665']
The problem is, that it is too complicated. When you want to train an animal you need the train_animal skill. When you take a look at the employee screen showing only classes, you need to know that a druid,a hunter, and a beastmaster have this skill.

That doesn't sound complicated, it sounds like a problem of clarity.
If you have an employee screen, why not let the player filter it by skills? Let the skills be the important factor, and the class names just a way for the player to sort the characters in their head.
[/quote]

This. But maybe let the player have the option of separating by both skills and classes. As well as adding either a guide within the game to the classes, or something similar. Such as a hover-over on the skill, showing what classes have that skill, and hover-over the class shows what skills it has.

This would be feasable for a large scale simulation where you need dozens of employees. My game is small scale, I plan to use only up to ~20 employees, on the other hand I got many different tasks (currently >10).

20 is a lot, maybe not massive scale but not a small scale either. Plus, don't forget that for a player to get these 20 employees he needs to check through 100 or more potential candidates and that's not few for sure. With these numbers you would benefit from having clearly defined classes.