I'm calling it quits on Piecemeal Jack for now. This is as far as I got:
I built everything I had planned, to some extent, and the result appears to be a game you could finish in less than 30 minutes. Granted, I haven't implemented the bosses, and damage isn't doing much, but I don't think adding either of these things will help extend the game beyond 30 minutes.
2 strategies come to mind for ensuring player's don't finish the game in 1 sitting: Slice up what I have and extend it out by adding 2 more levels, or ensure the game is so difficult that few players would be able to complete the game the first time they play.
I don't really like either approach at the moment, so yesterday I decided to put Piecemeal Jack aside. I don't see the point in paying for the production of art assets for what I have. I intend to return to this project some day in the future, but next month I plan to focus on things that would help me get a new job instead.
Piecemeal Jack has very much been a learning experience on when I should start talking about a project. I get so exited and, as with the registering of a domain, the paying for a website, and everything that happened with my past game projects, I think I rushed into showing off the idea. I don't think any of these things was strictly harmful to myself, but I believe it's hurt my ability to find and retain an audience for blogs, future games, etc. Honestly, I don't believe anything I've done to date is particularly interesting, and I've started asking myself why that is.
The next time I start on a game, I'm planning to stay silent on the whole thing until I've reached the point of adding art assets.
My goal for this month is to produce an art-ready game before December 1st.
Art-ready is a made-up term to describe a mostly-complete game that is missing all art assets. This approach to game creation should generally be frowned upon due to the potential of technical issues arising from the late introduction of said assets. I decided to attempt this approach with my new game for 2 reasons:
I recently realized, with the help of my roommate, that I really don't enjoy the process of designing and crafting art for games. I enjoy programming and game design, but the art side has always been the kind of thing that I only attempted to do on my own because of an assumption that it's the indiething to do.
I've never attempted to hire an artist as a contractor before. I want time to ensure I have a good estimate of how many assets I'll need, which may require the whole month to work out.
Now, before I go over what Piecemeal Jack is, let me cover some history:
One of the first videogames I ever tried to make was based on an old series called Splatterhouse. I wanted to take the simple 2D platforming of this series and transplant it into a top-down 2D perspective. I worked on the project on and off for a year, and finally released a prototype I named Punch in the Dark. I'm not very proud of what I ended up with, but I am happy I released something as the response to it was inspiring in unexpected ways. You can play the prototype here:
https://dgalga.itch.io/punch-in-the-dark
The game that became Punch in the Dark went through so many iterations that almost every idea I originally had was stripped or filed down in some way. Over October, while I was brainstorming and prototyping ideas to work on for this month, those scrapped ideas came slithering back to me.
Piecemeal Jack will be a short, combat-oriented 2D platformer set in 1 large-house-sized level. I'm talking jumping, ground slams, punching, the ability to fall between floors, the ability to discover secret passages, use of 3 weapons you get from boss enemies, and a focus on enemies as your primary obstacle instead of jumping challenges. In this way, I intend to adhere much closer to my original design idea for the game. For example, I plan to featured holes in the floors of the house, which were previously challenging to design in a fun or interesting way from a top-down perspective.
I get 4 full weeks out of November, and I intend to build the full game over those 4 weeks. This first week will be focusing on building out the main character, then the 4 bosses I have planned and design of the house if there's time. Work progress will slow greatly after this first week, but I'm hoping I'll be able to come up with and implement all low-level enemies over the following 2 weeks. The final week will be for implementation of menus and the 4 difficulty levels I'm planning:
Easy
Double health
Double damage
Checkpoints
No unlocks
Medium
Normal health
Normal damage
Checkpoints
Can use unlocks
Get 3 unlocks whenever you beat the game
1 life
Normal health
Normal damage
Can use unlocks
No checkpoints
1 unlock on death
3 unlocks on win
Punishing
1 life
No unlocks
No checkpoints
Normal health
Normal damage
Some difficulty modes, chiefly Easy and Punishing, may be cut for time if needed.
I'm planning to post 1 new blog entry every Sunday of this month with an update on the status of the game. I don't think this will help my productivity any, but I am hoping it'll catch some interest for the game.
Over the past 5-ish months since my last post, I've learned that programming only really matters to me in the context of programming a game. Accordingly, I've quit school with the intent to do everything possible to move into a game development career. My first priority in this regard is to find a new and better production strategy for myself.
Of the strategies I've encountered so far for making games, my favorite has easily been the boardgame production strategy:
Produce prototype > find players > get feedback > repeat until "ready" > submit to a contest or group of other designers to tear apart > make corrections with intent to pursue a publisher or kickstarter, with additional testing as needed.
However, I haven't found a way or group to work with to easily apply this strategy to my videogame production. The closest similar outlet I've found for videogames are game jams, where you craft and produce an idea in accordance with a theme (or, sometimes, no theme) and (hopefully) receive feedback from other jam participants. Even if you don't get feedback, you get the opportunity to compare you work to your peers.
Jams are very good for testing new ideas and mechanics you might be interested in. It's my impression that making jam games can do alot to develop your ability to craft mechanics that "feel good". But, how do you take a jam game and turn it into a full title? I've yet to figure this out, despite trying to for at least 3 projects. The spark goes out once the prototype game is "done", and I find myself moving on.
My only alternative to the boardgame strategy and jams, until recently, was just to "plan to finish a full game this year" and work on and off on the project. This strategy led to boredom and frustration. I spent a good portion of my free time tinkering with programming languages until I finally decided to go back to school.
I need tight deadlines, the ability to work rapidly, and built-in time off in order to ensure I can continue working full-time while attempting to change my life. I've decided to try the following strategy:
Sent aside 4 months twice a year to produce a full game with the intent to charge some amount of money for it
First month is just brainstorming and experimenting with the goal of selecting 1 game idea to continue with. I've been completely derailed by experiments in the past and, in the game jam I most recently participated in (MechJam II), the game I actually finished was started with 12 hours left out of 2 weeks. It's my hope that providing more time at the start will allow me to get a better grasp of my project and its scope.
The remaining 3 months are intended only for the production of the idea I selected in the first month. The 3rd month is intended as a safety net only, so if I'm starting over again in the 3rd month that's a sign I need to shelve the project for later.
The remaining 4 months are sprinkled between big game projects and are for pushing my games on social media, game jams, programming, life events, whatever else arises. I've found social media in general to be an annoying distraction, and I hope to keep interaction with it to a minimum while developing.
This new strategy doesn't include time for user testing, feedback, or coordination with other artists. There's so many prototypes vying for people's attention, not to mention all of the completed games from every decade imaginable, that I find the idea of attempting to attract an audience with my current resources extremely intimidating. I've also given up on the idea of paying others to work with me for now, as I no longer have the spare finances.
Every now and again, I hear about weird little indie games. Projects buried in the mass of steam, or invisible on the prototype-heavy platform of Itch.io. I hear about these games from videos posted by other game makers, or through quirks of the YouTube algorithm that lead me to tiny channels with minuscule followers. It really seems to me that any sufficiently entertaining or distinct videogame has the potential to be discovered and cherished by a tiny group of zealots.
Aiming for tiny success is not a good business strategy. However, when all you want to do is produce something worth actual money with your very limited resources, ie not an asset flip and typically more developed than a student project, it is a strategy. Worst case, no one notices your games and your portfolio expands beyond jam projects. Best case, you make a game a few people like enough to tell their friends about.
You don't have to ask for money as part of this process, but I want to. It gives me reason to aim for a higher standard in my work.
As part of this new strategy, I plan to spend this month planning a project and then next month attempting to make 1 game. This would allow me to treat December as an off month before planning a new game in January.
This will be my only blog post for October. However, I plan to post weekly updates in November. I plan to continue posting here because I'm not ready to divide whatever audience I might have.
"Growth" was submitted to Trijam 121, which had the theme "Exploring spacetime". I (and most of the jam participants) could only initially think of games focusing on vehicles in space, but I rejected this as too obvious. I've spent the past 6 months learning C++ and not finishing games, so I wanted to do something more personally interesting. I decided on doing a multi-part, artsy, exploration-of-the-short-life-of-an-alien-parasite thing. I didn't get in everything I wanted with a 3 hour deadline, but I got all of the key points in and I'm happy with the result.
"Confettiman tries to fight guns" took me 10 hours out of a special 20 hour Bean Jam #20. The jam was held in a far off time zone, and I started late, but I'm still happy with the result. It's super basic, and I don't actually think it fits the theme very well, which is "World's worst superhero".
I made Confettiman far too powerful. His jump allow you to completely dodge bullets! However, this also marks the first game I've ever made that somewhat fits the beat-em-up perspective, and it's this I'm proud of.
Now, I was originally planning to take part in 2 more jams before my classes resume next week. However, I had to drop out of one when I realized it was all getting me very stressed before what looks to be a very stressful and compact summer semester. Shortly afterwards, I decided to drop the second when I realized something odd: I miss working with C++.
C++ is hard. However, I can see a future in it. I can even see myself making games using it with more practice, and I credit my experiences of this past semester with improvements in my game design and workflow. I don't see a future in Godot, or tinkering with Unity. Tinkering and hobbyist projects won't teach me the concepts I need to build better projects.
I need a future of the kind I see in programming. I plan to do a few game jams between semesters, and I plan to keep this blog for that. However, I can't pretend anymore that the tinkering way I was for 2018, 2019, and much of 2020 will ever get me where I want.
It's challenging, as you can probably tell, and I'm enjoying it. The project is inspired by an old Sega game called Gain Ground.
Gain Ground is a top-down 2D ancestor of the twin-stick shooter. The player progresses from the bottom of the screen to either an exit at the top or towards a boss somewhere in the level, all the while shooting at enemies and rescuing characters for use in later levels. There are a number of features I enjoy, such as the rescuing of new characters and how the entire level is always shown to the player.
However, there are a number of rough edges I'm hoping to remove in my new game. For example, there are a number of almost useless characters and abilities that only ever get used when you have no choice, and game progression is a mess.
I like how much my project has progressed, but I can't keep it up.
At my job, as I've mentioned before, there's more pressure to conform to goals that benefit the company rather than myself. This takes up more of the free time I get for studying C++ during the week. On the school side, I've found myself in a situation where I need to read 3 textbook chapters and get ready for a new test I wasn't expecting before next week.
I've decided to stop working on my own games completely until I either get more free time or the current school semester ends. I already feel like I'm starting to burn out on C++, and creative side projects aren't helping. That said, I may still post random blog entries in the coming months.
I've started working through Love2D tutorials.
I've always wanted to understand and use the Love2D game engine. The biggest barrier for past-me in regards to this goal was simply my limited understanding of coding concepts. The Lua language, which forms the backbone of Love2D, retains many complexities for a newcomer despite the extreme simplicity of the language. After 9 months of learning C++ and Rust, however, Lua is starting to feel like child's play.
I'm going to continue tinkering with Lua and Love2D in whatever downtime I have, and I'll make another post if I find or make anything interesting enough to share.
This week, I learned the hardest thing for me to do is set aside a project that inspires me. When my daily life is stressful, as this past week has been, this becomes doubly true. However, in the interest of this little "3 hour game each week" project I'm on, I tried my best to move on from Ghost and Hostage to something new.
I spent far more than 3 hours this week experimenting with mechanics in Godot. My self justification was that I needed to settle my mind into a new goal I might achieve in 3 hours. I ended up stuck on ideas and mechanics that would only apply to the growing list of projects I've shelved at one time or another, and that continue to haunt me.
I finally settled on a new project yesterday, and started building it at my earliest opportunity. The idea was a simple puzzle game. I don't typically play or enjoy puzzle games, but it was all I'd come up with all week. The result was so mechanically uninteresting to me I will not be publishing it.
To break it down: you play a little green dude who picks up green bugs. You automatically pick up the bugs, and automatically drop them in the appropriate spots to cross over lava to reach a goal. You control your character using the mouse.
I imagined a really simple and breezy puzzle experience, and ended up with something that was too simple with less than an hour left for changes. I tried some changes and ran out of time.
I can still see some potential in the idea. More hazards, height and or jumping, more obstacles, and there might be something. Trouble is, I don't think I care enough to return to the project.
I've re-written the ending to this post multiple times. How much do you vent about growing pressure at work to conform in a public blog? About wanting to find a new job, but feeling hopeless in regards to your ability to step into a new industry or find anything better in your current one? I have no answers, these 3 hour games aren't helping, and I'd rather use 1 or more of these hours looking up jobs each week. So, as of now, the 3 hour games are done.
I'm going to step back and figure out what development I can fit in without adding too much stress. I'll post an update next week on what that means.
Happy new year! It's been a little while, and there've been some changes. To keep it short: I'm back in school, I don't want to stop making games, I don't have alot of free time, and I hate the idea of having to put down a large project for extended periods. So, starting this week, I've decided to attempt to produce 1 new game in 3 hours every week until the end of my current semester.
I'll be posting to my blog after each game is "finished" (running in a browser). If I fail to complete an idea in one week, I'll post anyway and then set the project aside for a month. If I ever fail to come up with a decent idea, I'll join a 1 week or less game jam for inspiration.
To start things off, here's a Flappy Bird clone possibly staring a character from Steven Universe:
I intentionally decided to start with a super-simple design. The project took me about 152 minutes in total, and the majority of the code is all in the player.
For the uninitiated, Flappy Bird was a 2013 mobile title that blew up beyond anyone's expectations. It looks like this:
I've literally never played Flappy Bird in my life, and I was not interested in directly copying it. However, the potential of a system that can be engaging while requiring little more than button taps has started appealing to me recently, so I decided to take a shot at it.
I didn't really do anything to reference any part of the design of Flappy Bird. I opened a blank project, setup a basic player character, and tinkered until things felt "OK":
func _physics_process(delta): fail_check() #constant gravity if !calm: velocity.y += fall #rise when flying if Input.is_action_just_pressed("ui_select"): animplayer.play("flap") velocity.y = 0 velocity.y -= rise velocity.x += forward elif calm: velocity.y += fall * 2 if Input.is_action_just_pressed("ui_select"): animplayer.play("flap") velocity.y = 0 velocity.y -= rise / 2 velocity.x += forward / 2
In the above script, the player is always falling thanks to velocity.y += fall (down is positive on the Y axis in Godot, while up is negative, so adding to a variables y value before applying it to a character causes "falling"). Anytime the player taps the Space key on a keyboard, the player moves upwards and forwards for a very, very short duration. After a great deal of tinkering, I found that constantly falling at a rate of about 1 pixel, while possessing the ability to rise at the rate of about 50 pixels and move forward at a rate of 20 pixels, felt the best.
To make things a bit more interesting, I decided to create a "zone of calm" in my game. The idea was that the player character, who I'll henceforth refer to as Lapis, is flying through a storm. There is a calm space within the storm where there is no wind, but flying takes twice as much effort. This is what the calm variable above is referring to: an object outside of Lapis has the ability to reach into her script and set calm to true or false. While calm is true, flying is twice as hard as gravity is unchanged but Lapis' ability to rise up and move forward is divided in order to be more difficult.
The rest of the important code in my game is associated with the "wind". I wasn't sure how to create wind other than by using static blocks, and I clearly didn't leave myself alot of time to experiment, so static blocks is what I went with. Each block has the ability to reach into Lapis' script and move her in a given direction, with the larger blocks being twice as good at this:
The above function fires when the player touches "wind". dir_push is a variable that controls what direction the player is moved in, and forward_push controls the power of that change of direction. The smaller wind gusts are set to 100 power, while the larger are set to 200. I still don't think these values feel perfect, but they do feel "good enough", so I settled.
On a side note: I totally forgot these objects are set to print the word "boop" on contact with the player. Oops.
That's really all the important code for my new game. Give it a shot and let me know what you think.
Yesterday, I completed a project I've been working on for awhile I decided to name Bomb the Bugs. You can play it in your browser by following this link: https://dgalga.itch.io/bomb-the-bugs
Bomb the Bugs was inspired by the Nintendo title Wrecking Crew. I played Wrecking Crew for the first time this year, and I found the design immediately approachable. I also tried playing the sequel, Wrecking Crew '98, which I did not find as approachable.
Wrecking Crew is a clunky arcade title. Each level is a puzzle, but you cannot advance unless you complete the entire puzzle. So, if you try to complete the puzzle in the wrong order, you can easily become stuck in a situation where you have to let an enemy kill you in order to progress. Worse, if you've managed to kill all the enemies you can reach, you have to wait for a fireball to spawn to kill you. To me, this design is problematic.
'98, on the other hand, embraces the matching design of most popular puzzle games and is turned into a cluttered competitive title in the process.
There are obvious elements shared by both titles. However, I didn't feel that '98 was a true sequel, and the clunky design of the original title still feels ripe for improvement.
I've been tinkering with this design ever since I first played it this year. Initially, I was frustrated by an inability to change Wrecking Crew into something I thought was worth money. When I finally did come up with something, it was a title that would require either more advanced programming skills than I previously possessed, or 3D.
The idea was this: In the wake of the Chernobyl disaster in 1986, crews were sent out into the area surrounding the exploded nuclear power plant in order to try and contain the disaster. People were evacuated, pets and animals were slaughtered, the top layer of the ground was buried.
The game idea I had was to be set in similar circumstances. Only, replace Chernobyl with a large-scale biological disaster stemming from a chemical plant. The player would be a member of a team sent out to destroy human habitations as part of efforts to ensure people and animals infected by the disaster were cleared or put down.
The game design would need either fake 3D a la Fez, or a fully 3D environment. The dream gameplay would be a puzzle-take on the destruction from Red Faction Guerrilla: https://www.youtube.com/watch?v=H5bv4RIOc_s
I couldn't manage that on my own, though. I didn't investigate going 3D, as I'm still shying away from the 3rd dimension in all of my games, and I wrote off Fez's method of fake 3D due to the technical skill that was required.
Now that I think back on it, there's no reason I couldn't try doing 3D with sprites someday. Instead, I settled on a method of using an array to generate a map of tiles when a game first starts:
var wall_types = ["X","H","O"] var walls = {wall_types[0]:preload("res://Walls/BaseWall.tscn"), wall_types[1]:preload("res://Walls/Ladder.tscn"), wall_types[2]:preload("res://Walls/BustedWall.tscn")} var level_map = [ "XXHHOXXHHXXOHHXX", "XXHHXXXHHXXXHHXX", "XXHHXXXHHXXXHHXX", "XXHHXXXHHXXXHHXX", "XXHHOXXHHXXOHHXX", "XXHHXXXHHXXXHHXX", "XXHHXXXHHXXXHHXX", "XXHHXXXHHXXXHHXX" ] var map_height = -1 var map_length = -1 var map_test = 0 var map_pos = [] #array of map positions var map_replacement_pos = []
func _ready(): fullscreen_sprite.visible = false for line in level_map: map_height += 1 for chr in line: map_length += 1 if map_test != map_height: map_length = 0 map_test = map_height wall_instance(chr)
I above code is still kinda cool to me, though overall it's not that special. It's GDscript that takes an array of lines like "XXHHOXXHHXXOHHXX" and compares these lines to a filter of expected wall types. In this case, X = basic wall, H = ladder, and O = a point the enemy units can spawn from. This allows you to easily spawn in an array of tiles of whatever kind you want, in this case Area2Ds, instead of needing to rely on Godot's occasionally unhelpful built-in Tilemap system.
I couldn't make a game within the parameters I set for myself that was worth money (imo) and better than Wrecking Crew while embracing that original design influence. So, I eventually decided to change the design.
I found myself picturing a city of sentient buildings, with the player acting as one of a limited number of agents with the ability to cleanse these buildings of infestation. That's where the "O" in the above line comes from: I was picturing a game where, if the player took too long, enemies would burst from previously uninfected wall panels and increase a global countdown to failure.
I still have the bugs bursting from walls, but the longer this year went on the less I was sure about the rest of it. I resolved to build the most basic, lazy version I could. And, I've now succeeded: https://dgalga.itch.io/bomb-the-bugs
This year has been hard. It's also been the most productive year I feel like I've ever had. I'm still a long way off from where I want to be, and I'm honestly not sure what to do with my time as the deadline for when I resume school looms closer.
Starting next month, I'm going to try evaluating games posted in the r/PlayMyGame subreddit. I've been frustrated by feeling disconnected from the game making community at large, and game jams haven't done much for my need to discuss design. The boardgame designer group I frequent is no longer a complete substitute either. So, I'm going to try playing other's games and giving my feedback on them. I'll post another entry next month accordingly.
My name is Andrew, I'm a student of game design and programming, and I'm using this blog to replace my previous paid SpakeGames Wix site. My next few posts will be recovered from my old site, and my future posts will be focused on digital and physical game design, future games I release, and occasionally programming and business. Any programming content I post will likely be related to Godot and GDscript, Rust, Python, or C++ for the time being.
I haven't decided on a posting schedule, and there's not likely to be one for a while. I'm in the process of going back to school, so that takes priority.
While we're here, I'll give my thoughts on Wix:
It's too clunky for someone who only has time to write a blog. Wix has a number of powerful tools, but tends to behave poorly in the editing UI and when accessing the site as a visitor. It's possible there are optimizations that can be made from within the site to prevent formatting from jumping around or loading oddly, but I never took the time to learn these. The site is probably fantastic as a platform for your business, but I never got to the point where I was ready to use it in such a way.
That's it for now. Of course, I've never gone through the process of closing a paid Gmail account and shutting down a domain before, so if anything interesting happens I'll post about it. As previously stated, expect the next few posts to be copy-pasted from spakegames.com.
