# Coding a game in four languages: Arena
###### tags: `code club`

For various reasons, I want the same (or similar) game to run in four different programming languages. Running code clubs and programming workshops, it makes a useful example of the things you can do and the tradeoffs you have to make, and I've found it interesting in how it has forced me to think differently in some environments.

This is the first of the games I'll be doing this way and is a simple arena game which I will specify below. I'll do a space shooter (Spacewar) and a platformer (Heroic Journey) too, and see how it goes from there.

## Game specification

Arena is a single-player game with a simple computer opponent. Your character is controlled with the arrow keys and can run anywhere on the screen. Also in the arena is a wolf, which runs somewhat slower than you do, but always runs towards you. If the wolf catches you you lose a life and kill the wolf, and a new wolf is release in a random location. You have three lives.

As you run around, trying to avoid the wolf, the audience throws coins at you, which land in random parts of the arena. When you pick up a coin, they throw another. If you can pick up 10 coins before losing your final life, you earn your way out of the arena and win the game.

A hit sound is played when the wolf catches and a pickup sound is made when you get a coin.

## What are the pieces we need to think about?

Regardless of the programming language or environment there are things we need to do in all of them.

1. Create sprite graphics for the player, the wolf, and the coin, with enough variety for animation.
2. Create sound effects for the hit and pickup sounds.
3. Load the graphics and sound files
4. Decide how to structure code into files, functions, objects, etc.
5. Decide what variables you need and whether they need to be global or not? Structured or flat?
6. Respond to keypresses by moving the player sprite.
7. Move the wolf inexorably towards the player.
8. Move all the sprites and draw them (and decide how fast to animate them )
9. Detect collisions (wolf vs. player and player vs. coin).
10. Use randomness to place the wolf and the coins.
11. Detect when the player loses and show a different screen.
12. Detect when the player wins and show a different screen.
13. Show the current number of lives and the current number of coins.
14. Size to window to the size of the screen (not all systems support this)

## What else can you add?

Once you have all of this working, you have a game that is challenging and can be fun, even as simple as it is. But you can take any version of this game and continue adding features to make it more exciting and engaging. Here are a few things I've thought of, but I'm sure you can come up with lots more.

* Have multiple enemies or a variety of enemies (not just the wolf) with different properties (speed, amount of damage, difficulty to kill)
* Instead of coins, sometimes the audience can throw weapons or armour.
* Each time you "win" and escape the arena, you can choose to go back in to fight a tougher opponent.
* The wolf can always start from a gate in the wall (more realistic) but when you get enough coins to buy your way out, you still need to get to a gate too.
* Different shapes of arena, some with pits or walls or other obstacles.
* Not an arena at all, take the mechanics you have and make a dungeon crawl.

## What were strengths and weaknesses of various languages?

This would be different if I'd written each version as idomatically as possible instead of writing them as similarly and simply as possible, but there are still some good takeaways.

### Pico-8

Good: Integrated tools for editing sprites, maps, sounds, music. All assets packaged together. Exportable to the web for sharing. Clear boundaries, must stay simple or else. Built-in event loop and init function support, clear separation between drawing and updating.

Poor: Extremely limited palette, difficult to incorporate external tools or assets, need to buy and install for editing games, hard limits. Lua could be a plus or a minus, but I don't personally find it very re-usable elsewhere. No built-in vectors, no importable libraries.

### Scratch

Good: Great support for sprites, reduces code significantly. No need to code collisions (but collisions can be expensive, performance-wise). All assets packaged together. As of Scratch 3, easily shared online with no player needed.

Poor: Inter-sprite communication is confusing for newbies (one more concept to understand). Sprites have vectors internally, but do not expose them, making them difficult to re-use (and some things, like vector math, near impossible). All code (and sounds) must be added to a sprite or the background (one more concept) and sometimes it can be confusing why something you think should be there is missing (because you're editing a different sprite) and it makes for more hunting around. Some code blocks hidden by default. No importable libraries (beyond those built-in but hidden). Built-in tools are very limited and not especially easy to use.

### JavaScript + P5

Good: Built-in event loop and init function support, although no separation between drawing and updating. Good vector support. Much more flexibility around code organization (functions, classes, separate files). Full-fledged language with lots of library support. Web-native for sharing.

Poor: No built-in sprites or collision detection. Textual code only with no visual support or built-in editors (multiple concepts to understand, even syntax highlighting can be confusing). All assets must be managed externally and loaded asynchronously, with code to manage this (more concepts). Requires at least rudimentary understanding of objects (more concepts). Syntax can be confusing and inconsistent. Built-in UI from the DOM (and especially Canvas), but that has its own baggage.

### Python + PyGame

Good: Most advanced sprite support, with grouping and collision detection, among other features. Clean syntax with few mystery characters (fewer concepts). Full-fledged language with lots of library support.

Poor: Must understand objects fairly well. No built-in animation for sprites, tends to be added via subclassing (more concepts). No built-in editors for assets. No web-accessible editors for code. Both Python and PyGame must be installed (and on at least one machine, there was a PyGame bug that crashed the code instantly). Difficult to package for sharing/distribution, cannot be shared on the web.