My experience with the basic command-line project I did my son, has taught me that he is not as averse to text-mode (AKA "no-graphics") as I had previously thought. I also learned that text-mode graphics is an easy and intuitive way to do I/O. It's also quite powerful - just think back about some of the early games :-). It is really important for me to show my son that there is no magic in programming. That he can create a games with bare-bones tools. That he understands how everything is done. No physics engines, no sprites, no magic.
I decided that the next project will be a text-mode tank fighting game: two tanks fighting each other in a 2D terrain. Something like this, only using text-mode graphics.
There are plenty of features we can develop, so this gives a long runway for this project alone. I wrote down some of the features we might develop:
- A 2D map which might be larger than the screen
- Animation of shooting a tank shell
- Animation of moving a tank around the screen
- Different types of walls: some impenetrable, some not
- Different types of ammunition
- Game levels with different maps and different challenges
- Animation when moving to the next level
- Blast/explosion animation
- Colors
- Sound
- Damage level and replenishment
- Ammunition level and replenishment, through picking up "ammunition presents"
- Different types of ammunition
- Hidden walls, keys and other tricks that add surprises
- Multi-player mode
- Multi-player mode - over the network
- Control from an Android application
- Score display
- Opening screen
- Console interaction
- Sprites, threads, collision detection
I can go on and on, but the point is that this is going to be interesting.
After making the list, I shared it with my son. I wanted to get him excited more than I was. Everything is designed to pique his interest: the theme, the game, and even the project name.
I decided to stick to my bottom-up approach. That is, I decided to teach through "doing" instead of teaching him in a structured manner. Instead of teaching about classes, objects, control structures, variables, and the lot, we will just dive in. This is how I learned to program and it was plenty good :-).
Each sit-down session is going to be self contained. That is, I don't want to quit in the middle of a feature. The application should always work. For this to work, we need to program in small increments. Another principle is that we both program: I show him how I do something and then ask him to implement something similar. And, as before, keep things lean and bare-bones. For example, if I can refrain from using functions for a few sessions, then I'll prefer to have one long 'main' function than to confuse him with functions for the sake of correctness.
We are using github to manage the source control and you can follow our progress there.
The first session was around the basic input/output:
The first session was around the basic input/output:
- We used Console.WriteLine to create a 2D map. To add some excitement, we added a title to the screen and played with the colors of the foreground/background.
- The main loop waits for user key presses and interprets them. This introduced some basic control statements ('if', 'while') and their syntax. Again, I introduced these non-nonchalantly: "we need to loop on the key press and this is how we do this. Do you understand why we call this a loop? Can you explain why we loop forever?"
- My son understands the Cartesian coordinate system from school, so introducing the Console cursor location attributes was pretty straight-forward.
- I first showed him how to handle a right-arrow key and then asked him to write the code for the other three arrow keys. Of course, I sat next to him while he was doing this. Some guidance was still required here and there.
- After he finished coding the basic loop, we player with the "tank" a bit and I showed him that nothing stops the tank from going off the map (or even the screen). We discussed how to fix this (boundary checking) and I again added the code to handle this in case of moving to the right, and then asked him to add the code for the other cases.
- Finally, we added the option to quit the game.
- He told me that today's games display "GG" (good game) when exiting, so I showed him how we can add some ASCII art.
- Of course, because the exit is so quick, we didn't see the GG displayed so we worked out a 2-second delay.
And that was it. A good first session. I ended by committing the code to a new repository in Github.
I felt my son enjoyed himself, so I might have done it right this time :-)
I felt my son enjoyed himself, so I might have done it right this time :-)