• dans la partie "Designing how to read levels", il manque un s à la fin de seem
• dans la partie "Add some code" il manque un s à test -> "There's a bunch of test[...]"
• dans la partie "Add some code" il manque un s à read -> "Now the code read a [...]"
• dernière phrase implementating -> implementing

typos

The level

• in the level read -> in the level reader (missing 'er')

The list of states

• it something I tweak along -> it is something I tweak along. (verb 'is' missing)
• We can tem add the code -> Then, we can add the code (them -> then)
• to the state lists -> to the states list (misplaced s)

Suggestions

The Level

The first sentence is maybe too long. I find it difficult to understand.

In the first sentence, when referencing the first part, maybe add a link to it.

global

Would it be better to express what the elements of code are doing in the present tense? Example:

First the level contains data related to a a game level...

the the State represents a state of the game being solved.

I think that it makes the project more real. Like it's not only an idea but a real thing.

typos

Introduction

• has a feature that will -> has a feature that will make things much simpler (missing make)
• the changing rules features -> the changing rules feature ('s' not needed)

First the algo

• it something I tweak along -> it is something I tweak along. (verb 'is' missing)
• We can tem add the code -> Then, we can add the code (them -> then)
• to the state lists -> to the states list (misplaced s)

Then some code

• So being possible to go -> To be able to go

Suggestions

presenting the solution without code

Like me, some reader will probably not have played the game yet. Those people would probably benefit from a schema or a short video showing the actions on the game that you intend to implement. I count two of them:

• moving Baba
• pushing a rock

check if the state has not already been processed

It took me some time to figure out why this step is required. Maybe a reword and an example would add some clarity.

Also, I find it easy to miss the importance of this step, maybe should you add some emphasize?

Word about not yet implemented features

This article is already long and maybe that everything that's not necessary to the comprehension of it, should remain silent.

This idea applies to the features that are not implemented, like:

• changing rules in the introduction
• "things that can kill you" in the "First the algo" part.
• implementation of "pushing a rock" that will be done later while explaining three steps of moving "you".

Maybe you could just specify that this version of the solver implements only some basic actions, not every possible ones and explain why you chose to do so, like you did but much later in the article (in the "A solution" part).

calculate to the new board position

It didn't make sense to me what this expression means and I had to read the code to understand.

Here's some ideas for a reword:

• update board's elements position
• update board positions
• update board's content
• apply newly calculated positions to the board

the structure

I find the general structure hard to follow. I think the name chosen for parts are badly presenting their content. Here's a list showing parts and their actual content:

• first the algo
  • explanation of the moves
  • explanation of the already processed states
• then some code
  • implementation of the moves
  • explanation and implementation of the three steps required to go from one state to another:
    • possible move?
    • winning move?
    • calculate the new board position
• the solution
  • implementation of pushing a rock
  • implementation of the "already processed states" check

Maybe you can state what you're concretely implementing in the introduction:

• moving
• pushing a rock
• check already processed states

and explain why you are implementing the order you chose.

I find it important to remind the reader that "pushing a rock" is built upon "moving".

Maybe that implementing a move and pushing a rock would be better grouped together (not separated by the explanation/implementation of the three steps required to got from one state to the next one).

separation between puzzle solver algorithm and actions on the game

Maybe it would add clarity to separate the code that strictly concern the puzzle solver game solver, like:

• calculation of the already processed states
• three steps required to go from one step to another one

from the implementation of the actions of the game:

• moving
• pushing a rock

I think the solver's design should represent this separation as well.

Dans l'article sur les Oà5P :
"seul le fait d’avoir des personnes dédiées leur permet de communiquer est un mauvais signe car souvent."

Malgrais #1 et #2 la home et plain des faute !
http://archiloque.net/blog/

I'm proposing two titles :
either

Designing the level reader

or simply,

How to read levels