A Concern with game-play design methodology


#1

Continuing the discussion from Waypoint and “Find” System for the Trapper:

I have been busy these last few weeks so I apologize if I am repeating anything already discussed. I did try and catch up before posting.

First I want to start by stating that I am a very big fan of this project. I think that team Radiant are an example of what we need more of in the games industry.

My concern is regarding @Tom’s comments above. I do think that the current design of the Trapper is counter to the game’s design as has been discussed fully already. My concern specifically is the apparent reasons for the current trappers design.

Firstly, @Tom mentioned the difficulty in coding the trapper to be automated. This is one of my concerns. Again I will re-confirm that I am a big fan, and this post is meant to be constructive criticism. I truly believe in one pinnacle of software design.

Program based on design - Not design based on a program

I have seen so much software (games included) whose design was clearly driven by how it was programmed. This is a very abstract concept so let me see if I can explain it a bit. Every program does something, using Stonehearth as the example and the thing it’s doing specifically as trapping. Radiant needs to design a way to have a worker trap animals for pets and food. It seems the current design was influenced by what was the easiest to program. In other-words the design of the Trapper character was driven by the program not by it’s concept or design. As a programmer myself I recognized this dilemma early on in my education. I realized very early the merits in having a designer who wasn’t a programmer to keep the software design focused on it’s function and not on how it is programmed. I could write a book on this subject alone so I will leave it there for the purposes of this post.

I believe that part of the problem here is the current pressure to continuously improve the alpha for us. While I enjoy seeing these improvements, anxiously awaiting news of a new update, I think that it can be detrimental to the games final design.

The need to have something to do while the workers are busy is extremely distorted right now as the game in such a primitive state. I’m sure once there is a full cast of character classes, resources, mob’s, blueprints, terrain features, and more in play there will be plenty to keep you busy without having to resort to giving you more micromanagement to take care of. In fact I think that having to click on individual tree’s and berry bushes will be too much micromanagement once the game is more complete.

I know that @Tom and @Ponder have fleshed out conceptually an awesome game. But I also know that during the development of a game a concept can morph and change quite a bit because of pressures from many area’s. The one mentioned earlier is one, but in the case of Stonehearth we have a relatively unique pressure, and that is of the widely distributed alpha. Normally alpha testers are part of the of the development team and / or privy to design and concept information. I know we as a community have quite a bit of information regarding this but nothing like we would if we were all employees of Radiant.

Now I am not suggesting that Radiant should stop adding content to the Alpha, only that they should keep the final design of the game in mind when adding this content. It would seem very counter productive to introduce content that makes the current version of the game more playable, but the final version of the game less playable. I know everything can be changed but once something is seen in one way it can be hard to see it another way. Hard to see the forest for the trees.

I know it’s easy for some (myself included) to praise anything that is done by a team like Radiant who we are fans of. This does not however help Radiant improve their game, or help it be the best it possibly could be. We need to think about the complete game when commenting on each small piece being added, and not just how it improves the current alpha version.

Just my 2 cents.


#3

Thanks for the concern but…no. :smile:

Adding direct unit control was actually more work that making a completely automated trapper. It exposed new cases in the AI code, like resolving automated behavior with user-driven behavior, and required new enhancements to the way we handle the mouse, the command system, etc.

We did all that work because now is the time to experiment, while the game is still establishing its pace and flow.


Improving the trapper
#4

@2_Zons, thanks for the feedback! :slight_smile: To Tom’s comment above, I would add this:

When we talked about “doubling the amount of work” it’s specifically w.r.t. avoiding implementing things twice–once in a directed fashion, and once again in an automated fashion. It’s not not because of the difficulty to create such a design, but because of the difficulty in maintaining and testing it… forever(everevereverever).

You know how at some point in your CS career you meet a professor, TA, or coworker who makes you refactor every bit of duplicated code out into its own function because otherwise, chances are that you’ll fix a bug in one version of it and then forget to modify the other one? This reluctance is conceptually related to that.


#5

Thank you for the quick replies. I’m always amazed to see how closely you guys monitor your community feedback, and it is very encouraging and one of the reasons why I am such a big fan of this project. I understand now what you were talking about with the programming concerns. I think my points are still valid though, and I still have complete faith in you guys (and gals) to do an awesome job. Just thought I would bring attention to these points and provide some encouragement for you in this direction.


#6

well said my friend…

i’ll refrain from attempting to add anything (specific) on top of @Tom’s or @sdee’s responses, suffice to say we are (to coin my 3rd favorite phrase of all time) “watching the sausage being made”… :smile:

we know that every decision Radiant makes wont be the best, either for the game or their use of development time… but that’s the nature of the beast, and its why we’re all here, praising and chastising… pointing out what is promising and what is flawed…

keep on providing your commentary, as it does provide a helpful perspective!


#7

also think of the trapper as a mini-game because what if you want to get fur and not have a pet how will the trapper know without you telling so


#8

The trappers interaction window could have check-boxes:

  • Trap for Food
  • Trap for Pets
  • Trap for furs / resources

If all are checked he would divide his work. Although if he is trapping for food, he would also be able to get furs and resources, so maybe just harvest, and pets check boxes.


#9

I was just thinking about @Tom’s response again. His response proves my point exactly. I know that this is not the final version and they are exploring and experimenting with things which is great, but it sounds like they programmed the trapper that way to expand the game from a programming perspective [quote=“Tom, post:3, topic:5662”]
like resolving automated behavior with user-driven behavior,
[/quote]

Now this is excellent for the game’s development and I do not want to criticize it per say, but it is an example of how design is being driven by the programming not by the overall games design. As this is a work in progress and the work done to implement the current version of the trapper may do a great deal to advance the programming of the game, I still think you need to be wary of the phenomenon of once something works one way, why change it when it works, and you end up with something different from your original design. One way in which a destination can be lost while on the journey to get there.


#10

2_Zons, I know you mean well, but you’re really putting words in my mouth with this programming-driven design thing.

We determined exactly how we wanted the Trapper to play on paper. The player should be able to issue direct commands like “move” and “trap” but the Trapper should also be able to initiate automated behavior, like eating, sleeping, and smartly harvesting a slew of traps that you have clicked on.

Once we have a design fleshed out, we implement it. For the case of the trapper, this required us to make programming enhancements in order to implement the original vision for the character. This is the opposite of what you’re suggesting. The programming is in service of the game design, not the other way around.

What you’re so worried about simply is not happening.


#11

will the solider play out like this too where there are way points and patrolling points available to you?


#12

Most likely. It’s been mentioned a few times. From what I understand they’ll be more autonomous though.


#13

I got ya @Tom, I wasn’t really worried, more just bringing up a general concern with a possible example for illustration.

Personally, I still think it’s a mistake to have to click on each animal individually, especially if there are key resources like leather, or fur gathered from trapping that will be used in crafting. This would mean that it would be part of your production and would constantly require micro-management even as your colony grows.

I think it would be fine to have the capability to direct specific animals, but there should also be an option to just let him trap on his own. I can’t imagine managing a city of 40 - 50 villagers, and constantly having to go back and click on a bunch of animals, move to another spot, then click on more, etc.

This is just my opinion, but I know it is shared by others.


#14

Everyone seems to forget that the upgrades to the trapper should be more autonomous as I beleive @Tom said on one of the livestreams. It’s like raising a baby, spend time helping them grow and then set them free.

Also don’t forget that trapping wont be the only way to get cloth and food, it’ll be one of many classes you can choose to get the materials you’ll need.

It’ll be easier to gauge how this works once the game is more fleshed out and a few tweaks here and there. Things might not make sense right now but if i’m understanding the reasoning and long term goals the team has for this like I think I do, I think it’ll work out better than you think :smiley: