Translated from French to English - www.onlinedoctranslator.

com

Gustave Eiffel University

Computer Science License

Technical Development Report

Java: Baba Is You

3rd year
January 2021
Authors
• Jimmy TEILLARD

• Lorris CREANTOR

1
Happy
1 Introduction 3
1.1 French ................................. 3
1.2 English. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Architecture 4
2.1 Overall structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 LevelBuilder and GameObjectFactory. . . . . . . . . . . . . . . . . . 4
2.3 App and GameController. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 The engine package. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Package board. . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Package rules. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.3 Package property. . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.4 Operator and its implementations. . . . . . . . . . . . . . . . 8
2.4.5 RecordType. . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.6 Package manager. . . . . . . . . . . . . . . . . . . . . . . . 9

3 Improvements and Difficulties 10

3.1 Post-beta improvements ........................ 10
3.2 Difficulties encountered ......................... 11

4 Conclusion 12

2
1 Introduction
1.1 French
The main purpose of this technical report is to describe the following project; that is to say
a description of the architecture of the project, our implementation choices as well as the
difficulties that we may have encountered during development.

The goal of this project was to create a clone of the game Baba Is You by Arvi “Hempuli”
Teikari in Java.

1.2 English
The main purpose of this technical report is to describe the following project; that is
to say a description of the project architecture, our implementation choices as well as
the difficulties that we may have encountered during development.
The goal of this project was to create a clone of the game Baba Is You by Arvi
”Hempuli” Teikari in Java.

3
2 Architecture
2.1 Overall structure
• The program sources are located in the packagecom.notkamui.jaisyou in
the filesrc:

– the packageappcontains the entry point of the application as well as the

game controller
– the packageenginecontains the main engine of the game whose state is
controlled in order to run the game and perform the necessary operations
– the packageutilscontains utility classes for creating levels and
entities in a controlled and secure manner.

• Project resources (levels and images) are kept in a folder resources

2.2 LevelBuilder and GameObjectFactory

LevelBuildercontains only one public method which is responsible for

constructing a level from a file name as well as rules (execute) given in the
form of String. Indeed, the interest of having a class that takes care of this,
coupled withGameObjectFactory,makes sure that each type is only created
once for the entire level. (All BoardElements of the same type have the same
Type instance).

4
 The given file is traversed from top to bottom following type declarations followed
by their instances

• oNAMEmatches an operator

• pNAMEmatches a property

• nNAMEcorresponds to a “name”

Each type declaration is followed by one or more lines starting with an angle
bracket describing the x and y coordinates of an instance to be created. In the
case of a "name", two options are added: 't' (for text) or 'e' (for entity) describing
whether the instance to be created is a name type in its word form or its entity,
followed by its coordinates.
For each new type encountered which is not yet stored in theGameObjectFactory, it
is created, otherwise it is linked in order to keep the consistency of the types. This
system allows, among other things, to very easily add new properties and operators
(just define a new type in the corresponding interface and add it to theMapof
GameObjectFactory).There is no need to create a class for entity or name types: they
are defined by their unique instance.
In the same way, theGameObjectFactorycan create rules (which will be the
default rules of the level) with the already created types or by creating new ones.

2.3 App and GameController

These two classes are used to launch the game as well as update the state of the
current level each frame.

5
 Appreads the command line arguments in order to ask theLevelBuilder to
create each level.
GameControllerwaits at each frame for the user to press a key and is
responsible for moving all the YOU entities as well as updating the rules of the
board

2.4 The engine package

The packageengineis the package which, as its name suggests, manages the
progress of a level of Baba is You. It is divided into three sub-packages, the package
boarding,the packageruleand finally the packagemanager.It also contains an Enum
Directionrepresenting the 4 cardinal directions, a recordMovement representing a
motion vector and an interfaceHasImagerepresenting an object that has an image.

6
2.4.1 Package board

The packageboardingis the package which contains the classes and interfaces
used to represent the elements of the board of a level of Baba Is You. It thus
contains two interfaces, the first,LocatedObjectsimply representing an element
with x and y coordinates, the secondDisplayable,inheriting fromHasImage And
LocatedObject,which therefore represents a displayable object. These two
interfaces are implemented by the classBoardElement,class representing the
elements of the board. This class is responsible for knowing its coordinates, its
state (alive or dead) as well as its type (baba, wall, water, etc.). It also contains a
lastTurnMove field used to display the board elements in the order of last
movement. Finally the rulePart field contains a unique instance of the RulePart
represented by theBoardElement,property, operator, type or in the case of
entities, nothing.

2.4.2 Package rules

The packageruleis the package containing all the incoming classes managing the representation
and operation of a rule (sequence of at least 3 words) from Baba Is You.

The main package file is the recordRulerepresenting a rule, made up of 3

elements, a left operandleftOperandan operatoroperatorand a right operand
rightOperand.ARulealso has the methods used to carry out the actions
generated by the application of the latter.
The package also contains the interfaceRulePartrepresenting part of

7
rule, or one of the three interfaces inheriting fromRulePartand entering into the
composition of an instance ofRule toknow oneLeftOperand, OperatorAnd
RightOperand. Thus, the interface contains 3 methods used to retrieve the
representation of theRulePartin its 3 possible forms as well as a constant
representing the RulePartnull and implementing default behaviors (used by
BoardElementsrepresenting an entity and therefore not containing an effective
rulePart) and returning for each method the “null” constants specific to each
Interface and implementing by default the methods of said interfaces.
The three interfaces inheriting fromRuleParttherefore have a static constant and
own methods,LeftOperandwhich represents the object that follows the rule has a
unique methodgetAsTypeused to interpret the object as an instance ofKind. The
interfaceOperator,which is in charge of transmitting or not the application of the rule
to the right operand. Finally the interfaceRightOperandrepresents the party who will
apply the rule, it therefore has the methods of action according to the event.

2.4.3 Package properties

The main file of this package is the interfacePropertyrepresenting the
properties. Indeed the properties are alsoRightOperand,whose responsibility
is to know their type and image. Each property can then implement one or
more methods amongonMove, onRuleCreationOronSuperpositondepending
on the effect it takes and when (we then speak of immediate, passive and
active properties). Being a sealed interface, the different implementations of
the properties are stored in this same file as records.

2.4.4 Operator and its implementations

Operatoris the interface which is responsible for describing the different operators of
the game. Each operator is therefore responsible for knowing the method to be
carried out when putting them into effect amongonMove, onRuleCreation,
onSuperpositon OronDeath.An operator must also know if its operands form a
prohibited rule or even a prohibition (ROCK IS ROCK, for example, which indicates that
ROCK can never change type). HasOperator and IsOperator implement Operator

2.4.5 RecordType
Kindis a record that represents a type of element, both as an entity (for ROCK,
the ROCK object) and name (for ROCK, the word ROCK). Each type is unique
and is thus simply determined by its instance (it only has two images, one for
the text and one for the entity). Being able to be both a left operand or a right
operand, a type is capable of giving itself to a BoardElementto modify its type
(BABA IS ROCK, for example).

8
2.4.6 Package manager
The packagemanagercontains the classes distributing the management of the game
during a game, as well as theModelclass used to access and modify the elements of the
game.

THEModelas explained previously is the class which contains the list of

BoardElementof the part as well as the methods used to access and modify
this list.
The classDisplayManageris the manager in charge of display. At each frame it
retrieves the list of displayable elements provided by theModeland displays them on
the board
THERuleManageris responsible for analyzing the board, finding the rules
formed by the elements in its current configuration and providing this list of
rules to theLevelManager.
Finally the main file, theLevelManageris the manager coordinating the information of
theModeland those ofRuleManagerin order to apply the current rules of the game on the
elements of the board and move the elements having the YOU property according to the
player's instructions.

The package also contains interfaces used to respect the principle of

encapsulation in order not to provide Manager parameters to classes whose
responsibility is not

9
3 Improvements and Difficulties
3.1 Post-beta improvements
The main comments about the project during beta were its size and
complexity, both of which were deemed too large.

Indeed, as we can see in the image, we had created unnecessary and very
numerous interfaces, and tried to represent differently elements which were
semantically identical (separations ofBoardElementsinto several classes,
separation ofPropertyinMovementPropertyAndPassiveProperty...). Likewise
another problem was the way of storing theBoardElement,they were
previously stored in separate lists, one list perWrapper,and these lists were
combined into a single list for display, which was described to us as too costly
and illogical. Finally, the last point covered was our rules management
algorithm, which we stored between each update and differentiated between
the list of old rules and the new ones, which was more complicated than
simply recreating the rules with each update.
Following the beta, we took these comments into consideration and, in agreement
with them, made the following changes to the project:

• Bring together different types of properties in a single interfaceProperty

• Bring together the 4 subtypes ofBoardElementin a single class, namely

BoardElement

• Gather all theBoardElementsin a single list so as not to have to bring

them together for display each frame

• Modify the rules management algorithm so that they are no longer stored but
simply recreated

Thus, we obtain the following diagram:

10
3.2 Difficulties encountered
The main difficulty encountered was the obligation to carry out numerous refactors in
order to be able to manage and add the new features of the game, while respecting the
principles of object-oriented programming and this without falling into redundancy or
unnecessary overload of classes in the goal of wanting to define as many concepts as
possible in vain.

11
4 Conclusion
This project was an excellent opportunity for us to develop and apply Design
Patterns that we did not know before, and thus to enrich our experience in
object-oriented programming. Indeed, in addition to being an interesting
game, Baba Is You is very conducive to the design of a code architecture which
must be rigorous and to polymorphism. We therefore prioritized modularity
while maintaining encapsulation and maximum security. Indeed, it is now
quite easy to add new operators or properties to the game with very little
modification to the project.

12