Originally I loved the idea that the entire class could contribute a mini-game to a larger submission for the Christmas game search, however I also wanted to stretch my mind towards learning more about ActionScript and making games in Animate. The second Christmas game that Marc and I worked on together had certainly done that – more than once I was turning to our teachers or the internet in search of answers, if only to stop my inevitable hair-pulling and frustration that much sooner.
However, perseverance has (in our opinion) paid off and I think the game has turned out exceptionally well, given what tools we had at our disposal. I’m disappointed we didn’t get to include anything Sunderland-y in the final product, but we just couldn’t conceive of a way to do it nicely. Instead, Marc focused on producing some more visuals for the game, including a start menu, a final score display, and an instructions splash screen.
The game itself remains quite straight-forward and the player would understand the mechanics after one playthrough, but we still thought it was important to explain the premise and some of the finer details. I really do like the graphics that Marc came up with, but it was my job to try and get them into the game.
I decided to use the first three frames to make up our game. The first frame would be the start menu, the second would be the game itself, and the third would be for the instructions. The final score splash is actually a child that’s added to the second frame once the player loses, so it didn’t need it’s own game frame. I liked it that way and thought it was cleaner, as well as an interesting bit of code to learn, so we decided to leave it that way.
In the end, it was easier to split up the code across the three frames; having a stop on the first frame, to allow the player to click on the start or instruction buttons, before moving and stopping to the second frame to commence the actual game:
This was one of Ant’s recommendations, since I was trying to compress all the code into a single actions frame and it just wasn’t working. Doing the code for the first frame as a separate part made everything much easier, but I then was having trouble with glitching out after this point – I was then reminded I needed to remove my listeners, which I completely forgot about. I also realised, on top of this, I would need to remove the children that were created during the game (otherwise, the snow kept falling and then froze up once the player lost and was brought back to the main menu).
The above is a solid bit of code and a good reminder that ActionScript doesn’t necessarily work in the same way C# does – it’s important to keep in mind what your code is doing and why, but also when you need it to stop. I had to change around the functions of the Play again button so it would jump the player back to the main menu, but as you can see I also had to stop/remove a lot of other parts of the code to keep the game running smoothly.
The code for the instructions menu was thankfully no bother at all!
Overall, I enjoyed writing up this game. It started off as a result of a tutorial, but I think it turned into something much more. Marc and I work really well as a team (which shouldn’t come so much as a surprise); we divide up the duties well since we each have our interests. This certainly tested mine, but I look forward to dabbling more in some further tutorials and/or game-making in ActionScript after this. I think the more I practice it and manage to learn, the quicker I’ll understand what makes this a choice program for developing fun little games for the web (and some bigger games for mass-consumption).
While I’m not holding my breath that this game will be chosen, especially over the mini-games the whole class came up with, which might turn out to be more fun from a marketing perspective, I appreciate that this was an excellent opportunity to developing my programming and game development skills. It gives me hope and makes me eager for any future projects that might be thrown our way!