Discussion about "different game criteria"

[gene]

I read Mz per X's proposal for a new blog post about our handling of a "different game criteria" at Oregami. It would be great if we could discuss the proposal here in more detail.

My short feed back: I don't understand it completely
My longer answer follows below.

What I do understand:

• our concept of three layers "Game→Release_Group→Release"
• what others do
• the basic idea. If the differences between an existing release (existing in the database) and a "new" release are big, it will be a new Release Group entry. If the differences are very big, it will be a new Game entry. I like that idea.
• to evaluate the differences, we compare two releases according to several criteria
• some criteria are so central that differences immediately lead to a new game entry or a new release group

So that's like the first half of the blog post.
The second half of the post confuses me quite a bit.

This is a list of the things that I don't understand:

• what does that "As R3 went down two columns of our grid" thing mean?
• is the criteria list different for different game types?
• where is the connection between the concepts explained in the first half of the post to the game play explanations from the second half?
• what do you mean with the "... (core concept)" and the "... (implementation)" paragraphs?

A more detailed question about the things I understood is:
If there are already multiple ReleaseGroups and/or Release entries available in the database: with which do we compare a new entry? To one of the existing or to all of them?

It is imperative that we discuss the draft in more detail.
@Mz per X: Why did you start it as a blog post in the beginning and not as a concept document in our wiki? Don't get me wrong, we clearly need a concept to decide about the layer of new game entries, so it's good that you thought about it. So let's discuss it here first!

[MZ per X]

Thanks for reading and giving such detailed feedback!

what does that "As R3 went down two columns of our grid" thing mean?

R3 is combination of a story-based and a level-based game, so it goes down the two columns for these two game play types. Hence the doubling of the sum requirements later. I should make that clearer within the example table already.

is the criteria list different for different game types?

No, but the points per criterion may be different.

where is the connection between the concepts explained in the first half of the post to the game play explanations from the second half?

With "concepts explained in the first half of the post" you mean story-based and level-based? Yeah, I should use two of the fifteen gameplay concepts from the second half to avoid confusion.

what do you mean with the "... (core concept)" and the "... (implementation)" paragraphs?

First, I generalize game plays by their core concept, second I do so by looking at how this core concept is implemented. In the end, we get 5 times 3 generalized game plays like
Competition-based gameplay implemented with reflexes
Improvement-based gameplay implemented with thought
and so forth.

If there are already multiple ReleaseGroups and/or Release entries available in the database: with which do we compare a new entry? To one of the existing or to all of them?

That's a very good question which I didn't think about enough, yet, and which should get its own paragraph within the blog post.

Let's assume for now we would assess every new R getting into the database. Then, there would only be quite similar R's within one RG, so we would have to compare a new R with one (maybe the oldest) R from every existing RG within the G entry. Let's take a look at the possible result cases when doing this:

1) We can find one existing RG where the assessment doesn't yield enough points for a new RG ---> assign the new R to this existing RG.
2) Within every existing RG, the assessment yields enough points for a new RG, bot not for a new G ---> assign the R to a new RG
3) We can find one existing RG where the assessment yields enough points for a new G entry ---> new G entry.

I know this sounds utterly complicated and would eat up a lot of time, but these assessments will only be necessary for a minority of game releases. The majority of games runs through without such corner cases, I'd say. But if we encounter a game with such corner case releases, we have this assessment grid in the back, and can build up the G entries and RG's from the ground up.

Why did you start it as a blog post in the beginning and not as a concept document in our wiki?

That's easy. This blog post developed into much more than I originally thought it would be.
In order to avoid too long discussions, I can rephrase the post to not be the Oregami way for now, but to be a suggestion for a new model which we might or might not implement later.

Does that make any sense? I will edit the blog post based on your feedback, thanks.

[MZ per X]

I finished my re-write of the different game criteria blogpost.

I dropped the concept of the criteria grid for being too complicated and replaced it with something which would be easier to understand and implement. Please read and comment.

[gene]

...Please read and comment.

Thanks for the rewrite. I like this version much much more than the first one!

What I like about your post:

• The motivation works pretty well. This made it absolutely clear to me why our third level is necessary and useful.
• I finally do understand your suggestions about how to make decisions. That wasn't the case in your first version
• I do not only understand it now, I do like it as well! What a fortunate coincidence

What I do not like (sounds too hard maybe):

• Wouldn't it be nicer to explain the relevant criterions first, and afterwards list the ones that don't matter? Just a thought.
• I know that the post should not be too long. But wouldn't one ore two good (game) examples make the whole thing even clearer?
• To use your concept in reality we have to have a "finished" concept für genres. But I guess that's how it has to be then.

Please don't get the wrong impression because the two lists are the same length. For me the positive impression clearly predominates!


Small note:
As we noticed in the last weeks our discord channel is a good place for discussions. Let's give a link at the end of the article.

PS: In my opinion we should try to publish a German version of this post at the same time. We could use deepl.com to translate your post, that should make a good start and reduce the time needed for writing the German version.