The Challenge
The 20 game challenge is a website that, you guessed it, challenges you to make 20 games. This challenge is an entirely self-imposed set of rules to follow while making 20 small games on your own.
To summarize how this works, you decide on a game engine ( or engines you wish to use ) and watch tutorials before starting the challenge if you need them. Then you can begin making up to 20 games on your own. Start with the first 10 recommended games as they will teach the fundamentals. The next 10 games you choose to design yourself based on what you have learned. After 20 games are done, end the challenge with a capstone project that is either larger than the other games or more difficult to complete than the previous 20 games.
Why do this?
Ok, so why am I doing this challenge when I already have experience making games? Well, there are 3 simple answers I have for you.
You can never do enough practice. Making small games regularly helps keep me in practice, and as long as I'm not practicing bad habits It will only help me out.
I want to code games from scratch outside of a game engine (i.e. using a framework )for the first time. I have made games in engines like Unity and Unreal for most of my career, but I don't want to feel limited to their platforms. So I want to expand my horizons and use this 20-game challenge to learn how to use the MonoGame framework to make games.
I'm trying to develop better habits and be more present on social media. I am an extremely introverted person, and for me, this is also an excuse to post about this experience online. It's like a small rung on my ladder to socialization. Right now I am a feral and easily spooked introvert. I'm hoping to create a habit of online interaction by posting about my progress on this challenge, thus getting used to putting myself out there and feeling less self-conscious about it. This is important to me as a game dev because I want to be able to interact with and cultivate a community for those who like my games.
Resources
Real quick before I dive into the code, or the game itself, I want to link to some helpful resources I've used so far to get started with MonoGame.
- Coding with Sphere is a small YouTube channel, and right now he is making a MonoGame tutorial series that is very well-paced and easy to understand. His tutorials were very helpful to me, and I highly recommend you check him out.
- MonoGame Mastery is a book you can download or grab a physical copy of. It was published back in 2020 and is a great reference for getting started and understanding the core concepts of MonoGame.
- Game Programming Patterns is an opensource free to read book. It's great to use if your looking for more efficient or effective ways to make re-usable code or if your learning Object Oriented Programming and want to learn it from a game prospective.
The first Game Requirements
Alright with all the explanation out of the way Let's get into the first game challenge. I get to pick between a 'Pong' style game, or a 'Flappy Bird' style game. I've made pong-style games a lot when I started learning, so I'll opt for the 'Flappy Bird' style game.
The goals are as follows
- Create a game world with a floor
- Add obstacles on the left of the game area. They should have a vertical gap between them, and move across the screen.
- Detect character collisions with the floor or obstacles, and reset the game when a collision occurs
- accumulate one point for each obstacle that the player passes. Display the score.
Optional goals
- Add sounds that ply each time a point is gained, and when the player loses the game.
- add a basic game over the screen to display the player's score
- Track the score between sessions and display the high score alongside the current score
- Add some background art, Try layering and scrolling at different rates ( parallax scrolling )
Planning
So, another habit I'm trying to break is just jumping right into programming things without writing out any kind of Design doc, draft, or plan. I used to plan everything and as I got more experienced I started falling out of this habit. So for each game no matter how simple, I'm going to be doing a planning phase. It doesn't need to be a full-blown GDD but simply writing down what I need to make the game work, and sketching some of the main frames of the game is enough.
Above is my design/planning sketch. I always do this on paper and usually have journals full of these kinds of notes. It's a good way to demonstrate thought processes and even if I don't actualize a game right away it's like a catalogue of ideas I can pull from in the future.
So Flappy Bird is pretty straightforward, there's a reason why it was a game 1 option so I wrote down some of the most important features. Everything on the screen needs movement, the player, obstacles, the foreground, and background elements. So I plan to make a movement component to add to all moving elements.
I know that input is required for gameplay and for the other screens of the game. So I'll need to make an input handler. Finally, I know that I'll need classes for the obstacles and the player because they will collide and interact with each other to drive the game forward and add to the score.
The Code
You can take a look at the full source code here.
So long story short I had to make a lot of systems that are normally designed for you in a traditional game engine such as an input management system, collision detection, event systems, and more. All of that stuff is inside the 'Engine' folder of the GitHub repository. It is the beginning of a foundational set of tools I will be using and continue to expand upon as I complete the rest of these upcoming game challenges.
While this project took me roughly 4 days to complete, most of that time was put towards making those game engine systems and the game itself was almost like a way to test how they were all working.
The image above is a screenshot of all the .cs files I made for not only the engine classes but also what I made for the game itself. The game has 3 game states, 1 player, 1 obstacle class, and one terrain class. All of these classes were inherited from the base classes I made in the engine section.
The game states spawn the scene actors, make the music play, update all the actors for each update loop, and handle the actions for each type of input. FlappyGameplayState is the main play state, FlappyStartSplash is the main menu, and FlappyLooseSplash is the retry menu.
The Art
I made all the art in the game myself using Marmoset Hexels3. It's a program that does pixel art very well, and I purchased my license on Steam while it was on sale.
As I didn't have a ton of time in the world I went with a more whimsical approach and didn't think too hard about it all. I make a player, some obstacles, and the UI elements. Everything turned out pretty well and my favorite piece for this project is a tie between the title and the player duck.
I got the Music and audio from OpenGameArt.org. If you're interested in using any of it yourself, check out the credits document in my GitHub repository. I have the assets I use linked in there.
The Conclusion
This was a challenging but fun start to my MonoGame journey. I don't know if I'll be able to finish the 20-game challenge in the long run. But I feel far better about moving forward after finishing this first game.
Top comments (1)
Thanks for sharing, can’t wait to see the other 19!