The Breakout Games Anti-IF Challenge
Have you ever noticed how many IFs have usually been used in the sourcecode of a simple arcade video game like Pong or Space Invaders developed in an Object-Oriented Language? Collision detection, input handling, etc. Have you noticed that every game has its own codebase?
In this Challenge Francesco Cirillo develops a series of arcade video games with an evolutionary design process with three goals: (1) Not to use the "IF Strategy"; (2) To generate more games from the same objects; (3) To reduce the cost of change in software development.
Structure
This course is organized in six sessions.
SESSION 01 - Development of the Original Kata
Let's start with the analysis of the problem defined by the Kata.
Let us read together the text of the original Kata proposed by Bob Martin. Francesco Cirillo will work on User Stories, Scenarios and Requirements of the Bowling Score App.
Before starting software development, Francesco Cirillo and the participants will define by which criteria to evaluate the effectiveness of software design.
Francesco Cirillo develops Bob Martin's original Kata functionality in TDD, one scenario at a time.
At the end of the session, we evaluate the result achieved in terms of design. What abstractions emerged? Was the TDD effective?
SESSION 02 - Completion of the Original Kata
In this session Francesco Cirillo will complete the development of Bob Martin's original Kata functionality in TDD.
A series of slides will help participants understand the evolution of our TDD-driven emergent design.
At the end of this session, we will assess the design emerged one test at a time.
SESSION 03 - Development of New Requests
In this session Francesco Cirillo will complete the development of Bob Martin's original Kata functionality in TDD.
A series of slides will help participants understand the evolution of our TDD-driven design.
At the end of this session, we will assess the design emerged one test at a time.
SESSION 04 - Let's Unleash our Imagination
Let's free our imagination and define new requests!
As usual we will work on User Stories, Scenario and Requirements together.
Francesco Cirillo will develop some new scenarios in TDD.
In this final session space will be given to understanding the various evolutionary steps achieved through emergent design.
Have we been able to reduce the cost of change in software development? Is the software "simple"? How can we define "simple"?
About this Software Development Challenge
Francesco's Software Development Challenges are journeys in which Francesco, you and the other participants will develop one or more features of a real application. Francesco will lead the development of the feature to be created and show you how he makes software design decisions, how he applies principles and tools, why he chooses one pattern over another and why he prefers certain practices in specific contexts.
|
The Arcade Games Challenge was born in a peculiar way. Students from one of my university courses at HWR brought me to develop a simple video game: Pong in Typescript. Just to see how to develop objects incrementally. I have to admit that video game development never really appealed to me, but it was fun to get to Pong along with them.
Doing a bit of research on video game development books I had, projects on Github and tutorials on Youtube, I realised that one thing was recurring: a disproportionate amount of IFs and "IF Strategy" to manage complexity, change and growth:
- Collision detection with a new character? "Let's add an IF".
- A different key for a new action? "Let's add an IF".
- Different sounds for different collisions? "Let's add an IF".
- A special animation when the space invader enters the attack state and tests our defences? "Let's add an IF".
- And so on...
I could go on for a long time, because pretty much every possible aspect of change or evolution, in that code and in those tutorials is handled with the "IF Strategy."
You already know what the first goal of this Challenge is:
- Not to use the "IF Strategy"
But there's a second aspect that struck me. Each game had a different codebase. Space Invader code in one project and Asteroids code in another. All separate. Hm... Hence the second goal of this Challenge is:
- To generate more games from the same base of objects and classes
Too easy... let's add a dash of adaptive approach...
- Without knowing which arcade video games we will be required to develop.
If we already knew the video games to be developed, someone might say that we work in an anticipatory way... Never!
We'll start with the smallest possible video game (I have to think about that...) and figure out a way to grow it into numerous video games. Maybe we'll come up with some new video games. Or maybe we can ask for outside intervention with a poll.... We'll see.
It would be very useful to have some participants from the Product Analyst and Product Design courses to make the user stories harder to deliver.
The last objective is the one I hold most dear:
- To reduce the cost of change in software development.
Otherwise why use an adaptive design and development process ;)
What are arcade games for me: 2D games like Pong, Asteroids, Donkey Kong, Mario, Snake, Frog, Zelda, ...
Note
|
I must admit that following the idea of this challenge I ran to Ebay, bought a NES and the above mentioned games. Just for work :)
|
—Francesco Cirillo