Screenshot
Butterfly Destroyers!
Butterfly Destroyers is a 2.5D/Parallax Arcade Shooter written with Pygame. We hope you enjoy!
In the year 20XX, butterflies have started to overpopulate the Earth (a problem of the future that you wouldn't understand). It is up to humans, the only intelligent species in the world, to reduce the butterfly populations. But the butterfly army and their leader, "Big Butta", won't go without a fight! :O
https://www.youtube.com/watch?v=AmFneqdItbg
How to Play
Or in a virtual environement :
Controls
In the year 20XX, butterflies have started to overpopulate the Earth (a problem of the future that you wouldn't understand). It is up to humans, the only intelligent species in the world, to reduce the butterfly populations. But the butterfly army and their leader, "Big Butta", won't go without a fight! :O
https://www.youtube.com/watch?v=AmFneqdItbg
How to Play
Installation
pip install -r requirements.txt
python ./run_game.py
Or in a virtual environement :
git clone https://github.com/PythonixCoders/PyWeek29.git butterfly-destroyer
cd butterfly-destroyer
python -m venv .env
source .env/bin/activate
pip install -r requirements.txt
python run_game.py
Controls
The keyboard controls are simple :
But the game is better with a controler,
- WASD or arrows to move
- Space or enter to shoot
- Shift to change weapons after unlock
But the game is better with a controler,
it was only tested with an Xbox controler
and there is no guarantee that it will work with
correct mappings on others.
Content
One of the most important thing missing is
a way to select the level. If you quit the game and
want to start at a certain level, just pass the number of
the level to the command line. For instance:
Most of the game is done, but as the deadline approched,
we did not have enough time to make all the levels we wanted
and the last levels need a lot more love that they received.
Some of them were even abandoned in a hurry.
Let's have a minute of silence for them.
If you want to know what the rest of the game would
have looked like, you can check the scenario
and use your imagination to design good levels with well balanced
ButtaBombers and Flyers. Also imagine the final boss with nice
butterfly paterns.
CreditsShip graphic: https://opengameart.org/users/pitrizzo
Font: https://www.dafont.com/press-start-2p.font
and there is no guarantee that it will work with
correct mappings on others.
- Main sticks to move
- A/B or RB/LB to shoot
- X/Y to change weapons after unlock
Content
One of the most important thing missing is
a way to select the level. If you quit the game and
want to start at a certain level, just pass the number of
the level to the command line. For instance:
python run_game.py 4 # Any number between 1 and 7 included
python run_game.py intro
python run_game.py credits
Most of the game is done, but as the deadline approched,
we did not have enough time to make all the levels we wanted
and the last levels need a lot more love that they received.
Some of them were even abandoned in a hurry.
Let's have a minute of silence for them.
If you want to know what the rest of the game would
have looked like, you can check the scenario
and use your imagination to design good levels with well balanced
ButtaBombers and Flyers. Also imagine the final boss with nice
butterfly paterns.
CreditsShip graphic: https://opengameart.org/users/pitrizzo
Font: https://www.dafont.com/press-start-2p.font
And thanks to the pyweek team for giving us the opportunity to
have such a wonderful week ! It was the first pyweek for each of us
and we will definitely do it again :D
github.com/PythonixCoders/PyWeek29
Awards
Scores
Ratings (show detail)
Overall: 3.8
Fun: 3.9
Production: 4.2
Innovation: 3.4
Files
| File | Uploader | Date |
|---|---|---|
|
screenshot.png
Screenshot |
flipcoder | 2020/03/29 23:46 |
|
title.png
Title Screen |
flipcoder | 2020/03/29 23:40 |
|
Butterfly-Destroyers-1.1.zip
— final
Final 1.1 |
flipcoder | 2020/03/29 23:35 |
|
Screen_Shot_2020-03-30_at_2.58.34_AM.png
screenshot |
MysteryCoder456 | 2020/03/29 23:05 |
|
Screen_Shot_2020-03-30_at_2.58.42_AM.png
screenshot |
MysteryCoder456 | 2020/03/29 23:05 |
|
Screen_Shot_2020-03-30_at_2.57.05_AM.png
screenshot |
MysteryCoder456 | 2020/03/29 23:04 |
|
Screen_Shot_2020-03-30_at_2.59.12_AM.png
screenshot |
MysteryCoder456 | 2020/03/29 23:04 |
|
screenshot.png
Screen 1 |
flipcoder | 2020/03/29 22:37 |
Diary Entries
A solid base for the base is complete.
MysteryCoder456 on 2020-03-26 07:09
It is now day 4 of the challenge and the basic game mechanics of the game are complete. All that's left to do is refine the game and iron out any bugs and problems, and also add levels.
Butterfly Destroyers Development Overview
flipcoder on 2020-04-12 23:24
Written by flipcoder (github.com/flipcoder)
Background
----------
Team PythonCoders was an open team started by MysteryCoder, a 13y/o programmer. The team
was international: Our team members were from USA, France, Finland, and UAE.
I myself have been in several gamejams in the past, including GitHub game-off,
where my game was one of the featured winners.
Workflow
--------
Going into this jam we started with our project management using Trello.
We used a Kanban-like layout for tasks. Our columns were:
Early Decisions
---------------
One of the early strategies I suggested was to just start going and not worry too much about
waiting on our decision-making, since we were slower at this at the start,
it was very important to me to just get a flow going.
From my experience with jams, especially with more than a couple members,
being bottlenecked by "analysis paralysis" is a common problem. It's better
to do something and have to scrap or fix it than to discuss every detail before
you add it. In this strategy, the most active people on the team can make the initial decisions
as they arise, This sometimes causes code redundancy, since we may
find different ways to do the same thing, but its often worth the cost of this,
since allowing coders to use the methods they are comfortable with increases
their development speed.
First Steps
-----------
Our team was light on the graphics end, so we initially thought of doing
something in curses, so I threw together a curses-like terminal in pygame (see game/base/terminal.py).
This would be come in handy later, considering our game's scripting would
make heavy use of character-by-character typing during the game.
We had some ideas for games. I pitched the idea of doing something like Top Gun for NES, where it would
seem 3D, but we would try not to overdue it, knowing pygame's limitations were
going to become a problem. I imagined most teams would approach the butterfly theme as something gentle or light-hearted.
We went completely the other direction. I thought doing something comedic where you play
as the military hunting down butterflies for no apparent reason, while playing
it off as serious was quite funny. We decided this would make a cool arcade-like game and went with it.
Codebase
--------
By the time we decided to move forward on the idea, we already had a basic game base.
I put together an Entity system as ddorn created a nice 2.5D/parallax Camera.
MysteryCoder implemented fog/distance-fading.
One of the core parts of the game's codebase is the signal/slot system, which was extended by both the timer system
(game/base/when.py) and the scene entity list itself. We implemented Scene
as a Signal containing entities as slots. This is the first time I've tried this,
but it had some benefits. The signal system was basically a safely-modifiable list,
where all changes to it during the list's iteration are queued until after
all iterations of it have stopped. This iteration+modification is also reentrant.
This meant all objects could modify the scene without iterator invalidation,
and we don't need to copy the entire scene list every time we iterate.
The modes of the game were implemented as a basic state machine.
The intro, game, intermission, and credits are separate modes that
contain their own update(dt), and render methods.
And finally, one of my favorite parts of the project: The scripting system.
We didn't want levels to be simply X,Y,Z object placements, we wanted
them to be scripts that were stepped through, and could pause/resume/restart
as needed. Multiple scripts could run at once and start/stop each other.
We used python's generators to script
both levels and entity behavior, allowing a single line of code to turn
on and off behaviors of things in the game at any time.
We allowed scripts to be run not just for levels, but for entities and game states as well.
A 3rd use of signals were here: Scripts could yield a condition for when to resume,
very similar to async promises. These were either timer events or fades.
I wrote a timer system called 'When', based on the signal system, that would
register timed events and fades and return a connection/slot that we could
yield from our scripts.
Scripts that needed user input would accumulate events that happened since last yield.
So we could script things like this:
yield script.sleep(5) # resume the coroutine after 5 game-seconds
Or:
yield lambda: not boss.alive # continue the script until the boss dies
Or:
# call faderfunc() with color values from black to white and resume script after
yield script.when.fade(2, (ncolor('black'), ncolor('white'), faderfunc, script.resume))
Look and Feel
-------------
Ddorn added ground tilting and parallax clouds. I added a noise-gradient to
give the ground and sky some depth.
We wanted each level to look different, so we varied sky and ground colors, and later
added weather effects and rocks on the ground.
We made the ship sprite stretch based on movement direction to give it a nice 3d effect
and Ddorn used his input system to smooth the movement of the ship. The player
handling felt really good.
Level Design
------------
Ddorn developed an AI system, allowing spawning of batches
of enemies in different moving configurations and shapes. In my opinion,
this is the most visually impressive parts of the project, and his
math work on this gave us lots of variety in the levels.
Ddorn's text narration during the levels was also great, and had exactly the
comedic tone I'd hoped for.
We did 3 different types of enemies and a boss. AI varied within the
initial butterfly type as well. We didn't get to fully use the Flyers and
ButtaBombers, and the ButtaBombers explosive behavior wasn't finished.
We didn't get everything we wanted to finished, but we were quite happy
with what we got considering the deadline.
Flair
-----
With the scripting, we were able to start polishing the look of the game.
We took advantage of gradients, noise functions, weather effects, particles, etc.
I wanted the game to look solid from the start to give a good first impression.
Music
-----
All of the music was written quickly, probably within a half hour.
I wanted to spend my time on code, but the game needed a memorable soundtrack
to give it the first impression we needed. I wrote 3 songs,
and I was quite happy with it considering the fast-approaching deadline.
Improving Performance
---------------------
We had some concerns about frame rate near the end. We had a memory bug which was a bit of a scare, since at one point the game was filling up
most of my RAM and causing bad fps. We logged like crazy and couldn't find much. This issue only
sometimes happened on certain computers, which made it harder to find.
I'm pretty sure that a different bug I fixed had removed the worst of it right before
We added an fps stabilizer that would disable some of the
effects if the frame rate dipped too low. We fixed the slow intro and score screen
by time-limiting the amount of effects updates, and improved the noise generation using caching.
Conclusion
----------
I think everyone felt it was a fun project (except for the scary last-minute debugging),
and I'm happy we were selected as a winner. I think everyone learned some new things during this.
I know I certainly did. We had some great competition,
but we gained an advantage due to the separation of the Team and Individual categories.
Thanks to my team for all the hard work, PyWeek for hosting this, and everyone who played our game. We've discussed
Project GitHub: https://github.com/PythonixCoders/PyWeek29
Hope to see you all next time!
Background
----------
Team PythonCoders was an open team started by MysteryCoder, a 13y/o programmer. The team
was international: Our team members were from USA, France, Finland, and UAE.
I myself have been in several gamejams in the past, including GitHub game-off,
where my game was one of the featured winners.
Pyweek would be the shortest jam I'd done so far.
Workflow
--------
Going into this jam we started with our project management using Trello.
We used a Kanban-like layout for tasks. Our columns were:
Ideas, Queue, Doing, Fix, Test, and Done.
Trello Link: https://trello.com/b/WuR7izYB/butterfly-destroyers
Early Decisions
---------------
One of the early strategies I suggested was to just start going and not worry too much about
waiting on our decision-making, since we were slower at this at the start,
it was very important to me to just get a flow going.
From my experience with jams, especially with more than a couple members,
being bottlenecked by "analysis paralysis" is a common problem. It's better
to do something and have to scrap or fix it than to discuss every detail before
you add it. In this strategy, the most active people on the team can make the initial decisions
as they arise, This sometimes causes code redundancy, since we may
find different ways to do the same thing, but its often worth the cost of this,
since allowing coders to use the methods they are comfortable with increases
their development speed.
First Steps
-----------
Our team was light on the graphics end, so we initially thought of doing
something in curses, so I threw together a curses-like terminal in pygame (see game/base/terminal.py).
This would be come in handy later, considering our game's scripting would
make heavy use of character-by-character typing during the game.
We had some ideas for games. I pitched the idea of doing something like Top Gun for NES, where it would
seem 3D, but we would try not to overdue it, knowing pygame's limitations were
going to become a problem. I imagined most teams would approach the butterfly theme as something gentle or light-hearted.
We went completely the other direction. I thought doing something comedic where you play
as the military hunting down butterflies for no apparent reason, while playing
it off as serious was quite funny. We decided this would make a cool arcade-like game and went with it.
--------
By the time we decided to move forward on the idea, we already had a basic game base.
I put together an Entity system as ddorn created a nice 2.5D/parallax Camera.
MysteryCoder implemented fog/distance-fading.
One of the core parts of the game's codebase is the signal/slot system, which was extended by both the timer system
(game/base/when.py) and the scene entity list itself. We implemented Scene
as a Signal containing entities as slots. This is the first time I've tried this,
but it had some benefits. The signal system was basically a safely-modifiable list,
where all changes to it during the list's iteration are queued until after
all iterations of it have stopped. This iteration+modification is also reentrant.
This meant all objects could modify the scene without iterator invalidation,
and we don't need to copy the entire scene list every time we iterate.
The modes of the game were implemented as a basic state machine.
The intro, game, intermission, and credits are separate modes that
contain their own update(dt), and render methods.
And finally, one of my favorite parts of the project: The scripting system.
We didn't want levels to be simply X,Y,Z object placements, we wanted
them to be scripts that were stepped through, and could pause/resume/restart
as needed. Multiple scripts could run at once and start/stop each other.
We used python's generators to script
both levels and entity behavior, allowing a single line of code to turn
on and off behaviors of things in the game at any time.
We allowed scripts to be run not just for levels, but for entities and game states as well.
A 3rd use of signals were here: Scripts could yield a condition for when to resume,
very similar to async promises. These were either timer events or fades.
I wrote a timer system called 'When', based on the signal system, that would
register timed events and fades and return a connection/slot that we could
yield from our scripts.
Scripts that needed user input would accumulate events that happened since last yield.
So we could script things like this:
yield script.sleep(5) # resume the coroutine after 5 game-seconds
Or:
yield lambda: not boss.alive # continue the script until the boss dies
Or:
# call faderfunc() with color values from black to white and resume script after
yield script.when.fade(2, (ncolor('black'), ncolor('white'), faderfunc, script.resume))
Look and Feel
-------------
Ddorn added ground tilting and parallax clouds. I added a noise-gradient to
give the ground and sky some depth.
We wanted each level to look different, so we varied sky and ground colors, and later
added weather effects and rocks on the ground.
We made the ship sprite stretch based on movement direction to give it a nice 3d effect
and Ddorn used his input system to smooth the movement of the ship. The player
handling felt really good.
Level Design
------------
Ddorn developed an AI system, allowing spawning of batches
of enemies in different moving configurations and shapes. In my opinion,
this is the most visually impressive parts of the project, and his
math work on this gave us lots of variety in the levels.
Ddorn's text narration during the levels was also great, and had exactly the
comedic tone I'd hoped for.
We did 3 different types of enemies and a boss. AI varied within the
initial butterfly type as well. We didn't get to fully use the Flyers and
ButtaBombers, and the ButtaBombers explosive behavior wasn't finished.
We didn't get everything we wanted to finished, but we were quite happy
with what we got considering the deadline.
Flair
-----
With the scripting, we were able to start polishing the look of the game.
We took advantage of gradients, noise functions, weather effects, particles, etc.
I wanted the game to look solid from the start to give a good first impression.
Music
-----
All of the music was written quickly, probably within a half hour.
I wanted to spend my time on code, but the game needed a memorable soundtrack
to give it the first impression we needed. I wrote 3 songs,
and I was quite happy with it considering the fast-approaching deadline.
Improving Performance
---------------------
We had some concerns about frame rate near the end. We had a memory bug which was a bit of a scare, since at one point the game was filling up
most of my RAM and causing bad fps. We logged like crazy and couldn't find much. This issue only
sometimes happened on certain computers, which made it harder to find.
I'm pretty sure that a different bug I fixed had removed the worst of it right before
causing it to not appear for us during testing, which was super confusing. We added some last-minute optimizations and hoped that it ran well for others.
We added an fps stabilizer that would disable some of the
effects if the frame rate dipped too low. We fixed the slow intro and score screen
by time-limiting the amount of effects updates, and improved the noise generation using caching.
Conclusion
----------
I think everyone felt it was a fun project (except for the scary last-minute debugging),
and I'm happy we were selected as a winner. I think everyone learned some new things during this.
I know I certainly did. We had some great competition,
but we gained an advantage due to the separation of the Team and Individual categories.
Thanks to my team for all the hard work, PyWeek for hosting this, and everyone who played our game. We've discussed
expanding the game moving forward. We've talked about moving the renderer to OpenGL and adding more levels. A few of the systems we created during this can definitely be reused in the future as well.
Project GitHub: https://github.com/PythonixCoders/PyWeek29
If you want to contact me, my discord is: flipcoder#8604. All of us are in the pyweek discord.
Hope to see you all next time!