Archive for the ‘MiniLD’ Category
For Mini Ludum Dare 47 I decided to recreate my first complete game, Untitled using Construct 2 and thus html5.
What Went Wrong:
- It wasn’t planned, It was the end of Thanksgiving week and I happened to check this website. I liked the theme so I decided to go for it knowing that I would have less time.
- Its a rather complicated game, and I wanted to keep the Leaderboards the same. I lost a good chunk of time on generating the levels, in the same way. I think I redid it 3 times during the weekend.
- Scoring is complicated, I was in the process of adding it during the weekend, but ran out of time. That more or less left the game in a non-game state. Mostly its complicated because I wanted your score to be calculated on the website, so its sent in variables and then calculated there. But it also has to be displayed in game, so I calculate it there as well.
-Collisions When I imported my sprites to Construct 2 the collision mask that was generated was a mess, it has some really weird things going on so that look time to fix (but it works good now)
What Went Right:
- Construct 2 worked great, other than the collisions I had no problems with it.
- html5 I feel is a better platform for this type of Art game, its much faster and easier to get at than downloading a client.
- I will be finishing the html5 version at some point, but right now I’m not sure when as its getting into Finals week.
Just at in the eleventh hour, I managed to finish off building a version of Heartbreak that should scale nicely for all Android devices. If you have an Android device, please give the .apk a try. I’d love to hear how it plays for others on their phones, or even tablets.
I also added in a little easter egg for those with tappy fingers.
So, I didn’t have enough time to finish my MiniLD #47 entry, Pix2. I had a feeling that I wouldn’t due to my project being quite ambitious for the short amount of time. I did make quite alot of progress and I should have it complete by the end of the week.
Pix 2 will be the successor to my Ludum Dare 26 entry, Pix. It was a 2D puzzle game where you had to get your blue pixel to the exit by going over every other pixel. It was a relatively simple game that I made in only 12 of the 48 hours of LD26. Pix 2 follows the same theme as the first but with a different aesthetic style, a bunch more levels and challenges, and a level editor. Here is the same level display in Pix and Pix 2 to show the difference.
After I have completed Pix 2, I might port it to Android as it seems it might control well with touch controls.
Anyway, Ludum Dare 28 is coming up and I shall be taking part in it. Ive participated in the previous 2 LDs, I’m not prepared to break that streak now ;D
Well, v0.1 is complete, anyway. Considering how much stuff I had in mind when I began this LD which didn’t come to fruition, I hesitate to call it a full-fledged 1.0, but it’s working, and (as far as I can tell) stable.
I’m pleased with the final result, overall. It could definitely use some polishing and expanding, but for two and a half days spent making what is essentially my first non-2600 game? It could certainly have been worse!
My only real disappointment is that I don’t know how to dynamically make the game fit across multiple mobile device screens. The linked version is sized for a Droid RAZR HD, since that’s the phone I’ve got. Once I figure out how to make a version that scales automatically for different phone resolutions, I’ll make sure to post it. Until then, give the Windows version a shot if you don’t have a RAZR. Controls are mouse clicks and drags, since it’s the same control scheme as the tapping/flicking gestures of the mobile version.
For those curious, you can play the original game, made for the 2013 Game Jam in Unity3D, here, and my remake for the Atari 2600 (included in a compilation ROM of other small games I made) here. The latter will need an emulator such as Stella.
This has been an excellent learning experience. I’m going to enjoy a little break, but then I hope to keep working on learning more to improve what I can do, whether with programming, art design, or sound design, since there is serious room for improvement in all of them.
And I’m done!
Rockets rise from bottom of the screen, explode into a bullet pattern, and you have to dodge it while (optionally) catching the extinguished firework. The game is a 3 minute survival, collecting fireworks advances time an extra 5 seconds, and it gets rather difficult rather fast.
The original game, to which I’ve unfortunately lost the source to, was made in C++/SDL but this version was made in Unity (and Photoshop, I guess!). I didn’t have time to add sound so there is no sound.
This morning was spent working on the Traits and Ability in the game, as well as selecting colors. Now by selecting a color you can take on the trait or ability that the color has, as well as travel through the color you have selected.
I’m submitting the game now, not because its done, but because I’m not sure if I will have time later. http://www.ludumdare.com/compo/minild-47/?action=preview&uid=3966
Provided I have time, I will be adding music, sound, scoring, and leaderboards. I would also like to add some how to play information.
First off, to anyone reading this–when exactly does today’s LD end? Is it at a specific time, or just midnight, relative to whomever is doing the dare?
Last day. I’m fortunate that my game happens to be significantly less complicated than everyone else’s, so I have the luxury of effectively being finished, then having an entire day to polish things up. The downside is that I’ve decently recreated everything that I’d intended, so I’m not quite sure on what direction to go with said polishing, aside from the inclusion of music and sound effects. I suppose that’s part of the learning experience.
- Sound Effects – 100%
I expect that I’ll just use the sound effects created for the Atari 2600 version, since they’ll be simple to acquire and appropriate for the retro-inspired style I had intended.
UPDATE: I’ve got some sound effects in, most of them simply recorded from the 2600 version of Heartbreak, though I generated a couple with DrPetter’s awesome SFXr, made for LudumDare participants, as it so happens. The sounds that I chose aren’t particularly great, but sound engineering is something I have zero experience in. May be a field worth learning more about for the future, particularly if I intend to keep participating in dares like this.
- Title Screen – 100%
This took the longest. I’ve been working on the title/credits screens for half the day. My desire to make things as “neat” as possible has resulted in an absolute mess of code all over the place as the entire game only uses three rooms, one that only initializes two variables before kicking the player to the title screen, and one that just scrolls credits on screen, since it seemed easier to use a unique room than to modify an existing room. The remaining room handles all levels and the title screen based on what global.level is set to. It’s both elegant, and an absolute mess.
- Music Integration – 100%
This went off fairly well, especially since the songs I’m using from incompetech.com list the BPMs of the songs, making it a lot easier to make them feel integrated. In hindsight, there is a song for the last three levels of the game that may be almost unfairly fast, which causes the heartbeat to be nearly too quick to get the color you want, so you have to anticipate it. Ah, well–I’m sure that anyone who can make it to that level will be able to handle it.
Pixel Grunge Style? Scanlines?
UPDATE: After some research, it seems that most of the effects like noise or scanlines are done using surfaces, which I know nothing about. I’ll definitely be looking into them in the future, but since I’m on a deadline with this LD, I think I’ll stick with the crisp, clean style that I’ve currently got. Besides, I have a couple other ideas on how I may polish things.
Time to get to it.
This time it’s not really recovering. Because I’ll make graphics, and I can’t say I could make good graphics before. So,
Relearning graphics —————
At first, I made a to-do list for graphics:
- Color scheme. I thought about making gray platforms, black void as walls, and gray fog for undiscovered territories. Quiet moody.
- Make player. You see it at 45 degrees, it can rotate in 4 directions.
- If possible, make walking anomation for player.
- Switches. It shouldn’t be difficult.
- Orbs (aka exits). Little black balls with smaller white balls orbiting them.
- Fog. Grey tiles which fade away as you discover them.
- Make some kind of tutorial. Text messages that will appear as you play.
- Main menu and stuff.
(Hey, where did the spelling check button go?)
The color scheme looked nice, but the fog was kinda bad, so I started from the fog. I decided to make the fog like that: initially, all undiscovered tiles are gray. But when I discover them, as I can’t just interpolate then to whatever I want, I switch them instatly and at the same time add a new fog tile, which will fade away with time.
Wow, it looks cool. Well, let’s go on.
Next things I made were switches and orbs. I made both of them animated, and it was very interesting to do.
Let’s make a player then! I imagine him knida squared (cubed?). After several minutes I managed to finish him. (Finish him!).
Why does he look like that? Idk, I just wanted so.
I didn’t animate him. Because my code is like cuonmoppltiicmaitzeedd. So, I finished graphics. Yay! Have a screenshot:
I decided to leave music for now and make some menus. And come up with a name of the game! So, here is an another to-do list I made:
- Make a tutorial.
- Come up with a name.
- Make a menu.
- Make an “you win” screen.
Eventually, I didn’t make an “you win” screen. But I made some cool effects, and discovered some in the program I use. Nice!
By the way, the name I chose is “By the Void”.
Now the game is pretty much complete. Except it’s missing some atmospheric music.
————— Relearning composing —————
Abundant Music still doesn’t have any export excepting to midi. Sad…
*Lookes (Listens?) through previously generated music* Bad luck… Nothing suitable…
Well, actually, there is some a bit suitable music, but generating is too easy! And I’m here to warm up my skills! So, let’s compose some music ourselves!
It didn’t took me long, but hey, I just made a 16-second loop!
And then, an usual problem: converting WAV to MP3. I use Audacity, and when it converts, it leave a little pause at the begining. Eek! It ruines the rhythm when looped! Well, the solution I know is to chop off the end of the track, so the length remains the same. But you can still feel the bump. If anyone knows a solution, please tell me.
————— Results —————
What went good:
- I finished it in time!
- I made some good graphics!
- I made (I think) the game moody.
What went wrong:
- Code. I even had some problems with it’s entanglement.
- I spent 48 hours, but made only one level. Well, I wasn’t really trying, but I need some serious warm-up to make it in time in December!
- The game isn’t very challenging. Well, the idea is years old.
Day 2 for me is coming to an end, I would like to be farther along, but I’m not. I continued from where I left off last night, with a working level generation, I completed that…then 6 hours later realized that I did it “wrong”. It was working correctly, but there was a better and more efficient way to do it. So I deleted what I had, and redid it. Next was to get the basic player movement in, that is simple in Construct 2. The problem arose from the collision mask that Construct 2 generated. The generated masks were very inaccurate and upon inspection, some were just wild. I just completed realigning all of the collision masks, and I’m going to call it done for the night.
The screenshot above shows the Starting screen, with the Play window open (well it doesn’t close yet). Inside the Play window you can either click on one of the complexity levels to use a preset level generation, or you can make you own by inputting numbers.
Tomorrows goals are to get the color selecting in, as well as the Abilities and Traits and with any luck scoring. A bonus if I had time would be music, leaderboard integration into the website, sound effects, mobile controls, and just about anything else you can think of.
I’m very pleased with where things are right now. Considering that much of yesterday was spent with family after Thanksgiving, I got started late today, and I took frequent, long breaks, I couldn’t be happier that the core game is basically completed after about 12 hours or so of actual work. It’s good to know that the game could be made and work well within a Game Jam’s time period, no problem. Take that, guys who said that Heartbreak couldn’t be made in GameMaker!
I’ve been keeping an ongoing list of my progress throughout the day, and I feel that having the work in a checklist aided in my productivity and concentration. I’ll have to practice this sort of thing more in the future.
That leaves things like sound effects and music for tomorrow, but at least those should be fairly simple to do. There is an abundance of great music available on the ‘net, and I may simply record my sound effects from the Atari 2600 version of Heartbreak to use again, as they are perfectly serviceable and I would be looking for something similarly retro-synth-sounding, anyway.
I’d also like to experiment with different visual styles, such as a grungy pixel art look and/or some scanlines. Something so that the visuals are so overly smooth and clean. That said, I do like the pastel colors that I’ve settled on, and it all looks pretty slick on my phone. I’ll have to experiment tomorrow and see what I like.
In any case, I consider the mini-LD technically complete as of now, since the gameplay is implemented and fully functional. The only nagging point is a crashing bug that I experienced a few times that I’ve been unable to replicate and track down. Here’s hoping that it got smoothed out somewhere and doesn’t rear its ugly head. Or, if it does rear its ugly head, hopefully it rears it high enough that I can find the neck and give it a good chop.
That’s it for me tonight. Time to wind down!
P.S. Is it just me, or does the above screenshot have a bit of an optical illusion going on with the blue block on the far right? Try turning your head back and forth and looking at it out of the corner of your eye. To me, it’s like the blue block separates away from the rest of the circle.
It’s quite hard for me to nail down the first game I have ever made, but I think if you ignore altering game listings and modifications you arrive at my fireworks game – where you were a flying character dangerously near a fireworks display.
Rockets rose from bottom of the screen, exploded into a bullet pattern, and you had to dodge it while catching the extinguished firework. Perhaps my logic was you were using your levitating powers to stop cardboard tubes giving someone a nasty bonk on the head, although in reality I imagine they burn up quite sharpish.
I no longer have the original version, which was coded badly in C++ and SDL, but I do remember it was infinite and had 4 modes: normal, normal deterministic, ultra and ultra-deterministic. I kind of wish I still had the Esp.Ra.De inspired character sprite.
For its modern reconstruction I’m focusing on a difficult two minute survival mode and there will be randomness to how the level is generated. Currently there is no catching and I think I will keep it that way. Above is everything I have so far with some placeholder art (the character is from Touhou 10 and totally not mine, will change!). Tomorrow I will do everything I haven’t done already.
After a relaxing night’s sleep, some Thanksgiving leftovers, and a couple YouTube videos to wake up with, I’m back to work! While checking the new posts for this mini-LD, I came across this particular post, which posted a video about motivation.
Now, I, personally, often have trouble keeping myself motivated. I tend to want to go do something else, like watching YouTube videos, playing a game, chatting on Skype, etc. and it’s been a bane to my productivity for many years. In the interest of giving the aforementioned video’s suggestions a try, I’m going to set out a clear list of things that I must get done today and organize them into “modules” so I can see the progress I’ve made. I’ll be editing this post to update my list as I work.
- Mobile Controls – 100%
Mostly complete, and much simpler than expected, thanks GM’s point_direction function. Still need to test it on a mobile device with someone to see how intuitive the controls are.
Update: Complete, with press-dragging to move the blocks and tapping to create balls or change ball colors, if a ball already exists on the playfield. It’s actually very intuitive on a mobile device, which is pleasing.
- Lives – 100%
This was one of the shorter, simpler tasks. The heart is resized based on a global lives variable and is destroyed when the lives are set to 0, which also serves to lock out any controls but a simple tap, which resets the stage.
- Ball Color Checking – 100%
I underestimated the work involved in “Bouncing Ball,” so I’ve split it into two categories, now. Collisions work, with balls correctly changing the colors of the blocks they hit, but I don’t have any bouncing code implemented as of yet. It may prove to be complicated, and I’m not exactly sure how I will implement it. I’ll ponder it while I take a break.
- Bouncing Ball – 100%
Finally managed to get this implemented. Not only did decent bouncing take a while (and it could use some work, but it’s serviceable), but I came across a number of other things that needed tweaking and fixing in the process. There’s still one bug that I can’t reliably replicate that strikes almost at random, seemingly only when a blue ball hits an orange block, but only on occasion. I hate loose ends.
- Level Progression – 100%
This task was fairly simple, and I took advantage of GM’s defaulting unspecified array values to 0 to my advantage to cut down a tad on how huge the level array will be, at least in code. Now to type out the levels, which should be fairly simple–it’s just a bunch of copy-pasta.
- Implement Levels – 100%
There are currently 22 levels implemented, with plenty of room for more. My level system is pretty flexible, allowing me to specify how many rings there are (I’ve set up the rings in a switch case statement so that they’re rendered in a certain order), which colors the heart progresses to (a necessary control for the earlier tutorial levels), and what the odds are of each of the eight possible colors spawning. It worked out quite well, and I could easily add more levels that have different color spawning odds, but I’ll probably leave it at 22.
- Score Implementation – 100%
The current score is rendered on-screen, just above the heart, as in the original Unity3D version of the game. I had to look up how to make it always display zeroes to the left of the score, but in hindsight, it’s something I should have figured out, myself.
Scanline Effect Sound Effects
Time to put on a game soundtrack and get to it. On a related note, while Hotline Miami has an awesome soundtrack in the game itself, it doesn’t make for good listening on its own. FTL and Super Meat Boy are great to just listen to, though. If you can think of some others, let me know.
It’s been a while since I made a game. I didn’t make since summer… And the December LD is coming!
So, I’m going to get back into making games. And I’m participating in MiniLD #47.
————— Relearning planning —————
Hmm… The first game I ever made? I remember my old games surprisingly well, but I can’t remember my first one. They were written with Delphi 7 and they are short. I think I remember one very old game… I don’t think it’s the oldest one, but I’ll pick it. Let’s see if I’ll find it.
I’ve changed a computer since then, but I backed up some data from it. Searching didn’t take long. So, I found a folder of my old Delphi games. Unfortunately, I didn’t find the game I was looking for. OK, I remember it quiet well.
Also, I found out that I don’t have Delphi on my computer. Well, I’ll have to use another program then.
The game is simple: you have a stickman, you move it around. You only see 4 adjanced tiles, and, well, ones you already saw. You need to reach the chest. Once you do it, you go to the next level and control another stickman. There are doors, which need to be opened with levers.
But I didn’t use an individual screen for each level. So, in the picture above, there are 3 levels. It allowed me to make a twist: communicating beween levels. So, the switch in level 3 doesn’t open the door in level 3, but it opens the door in level 2. And behind that door is the switch that opens the door in level 3.
After some time, I created a map for my future game.
I designed it so (I hope) characters never meet each other. (Oh, they actually do. Well, nvm.) Also, switches can’t be switched back once used. And wires are just for understanding, I won’t include them in the game.
So, the planning part is done. Then I started programming.
————— Relearning programming —————
Well, not really relearning. I’ve been programming though I haven’t been programming games. I decided to use PhYard Builder, that I usually use for games.
The first problem is: how to store the map data. I planned to make undoing for my game, so I should make the map loading flexible, but not containing too much data. Each tile has up to two values:
- Is it explored or not. Unexplored tiles are inactive and and black.
- Is it changed or not. Used for appearing/disappearing platforms and switches turned on/off.
So, basically, there are two things to store: the level itself and the state of tiles.
The second problem is switches. I usualy store the level in a string, with each char representing a tile. But switches need more information, because they need to know what tile(s) to switch. So, I decided to mark switches with letters A-Z and describe the behaviour for each one individually.
The ends of the level also need more data: the beginning of the next level. But I can just make them switches those change not the state of tile, but is it explored or not. And mark them with letters a-z.
So, I converted the level to the text form:
................ .@.@...@..A.##B. .#.#.#.#.C...... .#.#.#.#..D#@a@. .b.E.c.#.d...F#. .......#.G..#H.. .@.I.J.#.#.#.K#. .#.#...#.L.M.... .###.N##........ ...........##.e. ..f..@.@####O... .....#.......... .g.###.##P.#Q.R. ...S...#...##.#. .....T###U...... ................
After about four hours, I finally got to test the game. I could move the player anywhere by clicking, and I couldn’t change players. Also, switches weren’t working. Oh, I just forgot making them work.
After a lot of debugging, I managed to make it work. Unfortunately, I found out that I also have to remember player positions. So I decided to make undoing remembering the level. So, I failed at planning. I hope that won’t happen in an actual LD.
I wiped off the “changing” of tiles surprisingly easy. So, I managed to make everything excepting the undoing.
Finally, I finished the undoing. The programming part is complete!!!
————— Results —————
What went good:
- I made it!
- I remembered how to program.
- I planned well. At least the level design.
What went bad:
- Time. I think it took me longer that I thought.
- Code. The thing that went the wrongest is the undoing. I didn’t do it before, but I think you remember the action, and trace them back to undo. But I remembered the whole level…(
Well, I think that it’s gone well so far. Using the template posted earlier, I built base sprites for each row of blocks, then created a script for creating and setting up individual blocks and a script to churn out full rows. Much like the original game(s), I hope that this version will do a decent job of teaching intuitively through level progression.
Also, the heart changes colors and has a simple beating animation (just scaling down for a frame).
Tomorrow, I’ll be adding the ball and controls. If I have time (which I expect I will), I’ll also add in all the core levels and the score counter. There should be at least 12 levels, each of which will introduce something new (an additional color or another row), plus a few different random mixtures for infinite play beyond that.
Here is a screenshot of where I’m at so far, with all the blocks being randomized into place. Seeing how it looks, I’m definitely going to have to figure out something different visually. I was shooting for something cleaner, but it just looks drab in the end, plus the blocks don’t fit together particularly well, so I will have to rethink that. Maybe a pixel-y art style will be back on the table, since it’s relatively simple to accomplish, but would add some visual grit and variety, if done well, so everything wouldn’t seem so bland.
Time for a break, then bed.
I saw the theme to this mini Ludum Dare, and immediately knew what I wanted to do.
Almost 2 years ago I released a game that I called Untitled, that game started as an entry to Ludum Dare #21, I spent another year or so polishing the game, and adding features. While its not my first game, it is the first one that I really considered and put a fair amount of time into.
For more information on the game:
I’m happy with how the game plays. The shortcomings for me are the interface, and the accessibility of the game. Having to download a client to play something that could be done in a web browser didn’t help the appeal. The original client was made in Construct Classic, as it is now called.
For this MiniLD I will be recreating the game in Construct 2, and reorganizing a lot of the backend features. provided I have time I will also revise the website. I don’t know that I will complete the remake this weekend, but it will be finished. My immediate goals for this weekend is to have the gameplay elements all working correctly by Sunday.
The core of Heartbreak is the blocks that get colored and rotated. Thankfully, GameMaker should make this relatively simple, since it has a coloring function that I’ve tested and find to be working fine, plus a simple rotation value for each sprite. All I need to do is create a single block, give it an offset that will make it rotate around the center of the screen, and then rotate and color the blocks based off of a controller object.
I’ve already had some annoyances with selecting a resolution, so I’m just going to keep it simple (since I don’t have much time or experience for fiddling around with adjusting views for every possible mobile device) and just design it for my own Motorolla RAZOR HD phone, which seems to have a 1280×720 screen. If only there was some semblance of a standard when it comes to phone resolutions. This is certainly giving me a whole new respect for mobile developers, who have to contend with multiple versions of images for all possible densities and resolutions of phones, and they are all over the place.
A question I now have to ponder is how many blocks to design the game for? I have a couple templates made, one with 80 blocks and one with 40 blocks. The Atari 2600 version of Heartbreak used 16 blocks in a row, but that would mean 80 blocks after 5 rows and I wonder if that wouldn’t just be too tedious to play through. I suppose I can always adjust things later, if need be.
What bothers me is that 8 blocks seems good for the inner-most two circles, but since the individual blocks in the rings get larger and larger, that makes the outermost ring quite easy. I suppose I could combine rings of 8 and 16 blocks, either with the inner-most two or three rings sporting 8 while the outer ones have 16, or maybe just a random combination of 8 and 16? The latter would be a bit more tricky to program, as leaving things purely to random chance could result in too many or too few blocks in a row. I’ll have to see how things go.
EDIT: Using different sizes for the rings gives 64 blocks total, a nice in-between, and requires more and more precision for the player, so I think that I will go with it this way.
So, I shall attempt the MiniLD #47. However, I am about 80-90% sure that I will fail due to me not having the time or resources available. Also, this is a very ambitious project for just 2 days. I am away from my main PC so I am coding and drawing on my laptop.
I currently have a very fancy shmancy title screen and some code for a level editor. Tommorow I will get the map loader and renderer working, and finish off the level creator.
My progress so far:
If you want to view the original game I created for LD26 called Pix, click here!
Last journal post until I actually make some progress, I swear!
After making a long post about my choice in game engines and then another explaining where my original game concept came from, I’m going to, finally, explain the history of my first game’s development. In brief, I hope.
Heartbreak version 1: Unity 3D for Windows
Original Heartbreak game, made in Unity3D
As you can probably see, the game is very flawed. One major issue was with the controls, which were tied to the mouse, so moving the mouse left and right caused the ring to spin. Hitting left mouse button would fire the balls from the central heart. On top of that, the game itself is bugged. At the eleventh hour, we discovered a bug on the fourth or fifth level that would cause the score to reset to 0 after the player had progressed to the following level. Finally, at the time I made a big deal out of “elegance of design”, which I saw as every part of a game coming together to compliment everything else.
Don’t get me wrong–elegance of design is a good thing, but I may have taken it a bit too far by creating a menu system that you could literally “lose” at (by accidentally selecting the exit button), in the interest of turning even the menu screen into a gameplay tutorial. I think I had seen one too many episodes of Sequelitis.
After the 2013 Game Jam, I was excited to try my hand at game programming, since I’d been only the lead designer for the original Heartbreak. I wanted to learn the craft of programming for myself, in the interest of being more self-sufficient. To that end, I decided to start as “simple” as possible and got into programming for the Atari 2600. Yes, the real Atari 2600.
If it’s a bit debatable whether or not I technically “made” Heartbreak version 1, since I was really just directing a Unity 3D programmer in what to do, I consider my actual first game to be my first remake of Heartbreak for the Atari 2600. I used the homebrew tool Visual Batari Basic, which, when combined with Batari Basic, gave me a convenient and simple IDE with many helpful sprite and sound design tools, plus the ability to code in BASIC and use a pre-made kernel, rather than coding everything directly in 6502 Assembly. I was extremely grateful for that.
Heartbreak version 2: Visual Batari Basic for Atari 2600
Prototype Heartbreak game, made in Visual Batari Basic for the Atari 2600
It took me a couple months to actually make Heartbreak for the 2600, since I was learning along the way and frequently had to go back and reprogram bits of code here and there as I discovered more efficient ways to organize the game logic. Keep in mind this was all done for a system with a 1.19Mhz processor and 128 bytes (yes, individual bytes) of memory (only 26 bytes of which were available to me in Batari Basic, since the kernel I used consumed the rest of it to write the playfield to the screen).
In the end, it was again thanks to a more experienced programmer, who generously wrote a custom kernel for me, that Heartbreak was able to function well on the 2600. Normally, using Batari Basic’s standard kernel, only a single playfield color can be displayed on-screen per playfield pixel (those big, rectangular blocks), but the programmer managed to work around that limitation with some clever 6502 Assembly wizardry that I still don’t fully comprehend.
From the custom kernel as a framework, I was able to build the finished game. Some months later, I revisited my old code and cleaned it up, organizing everything into neat, clean functions that you can view here. I’m rather proud of how tidy and efficient it all is (relatively, keeping in mind that this is BASIC with 6502 Assembly calls in it, all programmed in non-object oriented in a language that relies on spaghetti code). The game itself only uses about 1000 out of ~3000 CPU cycles that are available with this particular kernel, and the game itself is under 4 kilobytes. And, yes, it works on a real Atari 2600. If you’d like to try for yourself, I included Heartbreak, with a few other small games I developed for the Atari 2600, in a 32k compilation ROM (along with an updated version of my previous LD, Ping) that you can get here (you’ll need an emulator such as Stella to run it, unless you have a real 2600 with a Harmony cartridge), and you can see the finished version of the game below.
There have been a number of gameplay changes since the Unity3D and earlier 2600 versions.
Heartbreak version 3: GameMaker for Mobile
Originally, the player had to hit a button (joystick fire on the 2600, spacebar or left mouse on Windows) to fire a new ball from the heart. The ball would take on the color of the heart and it had to either match the block’s primary color or be one of the primary colors that made up the block’s color, or else the player would lose a life (indicated by the size of the central heart). Hitting a wrong block three times meant game over, but the player’s heart would be brought back up to full size after every stage.
Once I’d finished the basic game on the 2600, I was seeking to program in alternative gameplay modes, since alternate modes were a thing with many 2600 games. One of those modes included a bouncing ball, so rather than the player having to spawn each ball (which would fire from the heart and then disappear once it had stricken a block), the player only had to press the fire button when they wanted to transfer the heart’s current color to the ball. This meant a lot less button mashing, and it was far more satisfying to just control the blocks to catch the ball as it bounced. This ended up being the only game mode in later versions.
With the block colors, I’d always intended the game to start with simple primaries–Red, Yellow, and Blue, and work up to secondaries–Orange, Green, and Purple–and finally to White and Black. White blocks would give you a heart back, but black would take away a heart if they were struck and had to be avoided, which was particularly challenging in the 2600 version, because the background is solid black as well.
However, this lead to the game becoming progressively easier, since an orange block could be broken by either a red or a yellow ball, a green with yellow or blue, and a purple with red or blue. Obviously, a game should get more challenging over time, not less. I fixed this in the 2600 version by having the ball remove a color from the block’s color, leaving the remaining colors in its wake. For instance, if a red ball hits an orange block, it bounces off and leaves a yellow block behind, which must then be broken by a yellow ball. And if the orange block was hit by a yellow ball, it would bounce off leaving the block red. Yellow blocks would need to be hit by all three primary colors before they would disappear.
Overall, I’m very pleased with how the game itself plays as of the final 2600 version, but a few things had to be sacrificed in the move to the 2600′s limited hardware.
For one, the ball will only bounce at a few pre-determined angles, as letting it bounce freely would result in the ball always getting lost, particularly since the blocks aren’t of uniform shape and they don’t fully encircle the central heart.
Additionally, there was no way to add multiple concentric circles to the game, so it always operates on a single ring. I would very much like the game to have up to three or four rings at a time, as in the original Unity3D version.
Finally, I always intended the game to be a musical arcade game, but having background music wasn’t feasible with the 4 kilobyte size limit of the 2600′s ROM. I would like to bring a musical quality back into the game, with the heartbeat matching the tempo of the current soundtrack, rather than set to a steady, heart-beating sound effect.
On top of all that, I’d also like to bring the game to a mobile setting, which I think would fit the gameplay very well, being a sort of casual game that works best in just a few moments played at a time. This would, of course, mean reconsidering the control scheme. I would like a simple swipe gesture to allow the ring to spin, perhaps with a simple tap used to set the ball’s current color to the color displayed by the heart.
On the other hand, I may modify that mechanic so that the heart does not change colors on its own, but instead must be tapped by the player in order to change the ball’s color. Or maybe the heart and ball always share the same color and, rather than tapping at the right moment to get the right color on the ball, the player would need to tap the heart to swap between its colors? We’ll see.
While I’m at it, I’d like to update the game’s visual style, maybe moving away from the direct pixel-art look into something a bit cleaner. And, who knows–if I find the time, maybe I’ll try implementing some kind of power-up system, similar to Arkanoid. I may have an idea of how it could work.
Now it’s (finally) time to get to started!
As mentioned in my previous journal entry, I will be remaking my first game, Heartbreak. It’s a bit of a strange tale, however, since Heartbreak wasn’t originally “made” by me at all, at least in the sense of programming. It was my baby design-wise and in the limited capacity of “art,” but I relied on another programmer to do all the actual creation. Still, I think that it will count fine for the sake of this mini-Dare. It’s either that, or Ping.
The game was originally made for the 2013 Game Jam (the same one that produced Surgeon Simulator 2013). It was my first time ever attempting to make a game, and I was nervous of the possibility of having no ideas. There were about 200 students packed into a lecture hall (which very much surprised me, as our university isn’t particularly large) when we were all given the theme for the Game Jam: the sound of a beating heart. We broke off into 15-20 person groups and went into separate classrooms to brainstorm.
This was my first experience with brainstorming, and I loved it. There were dozens of great ideas thrown around, my contribution being an idea for a point and click adventure game set inside a dystopian, film-noir crumbling city that was located in someone’s body, with a large, pulsating heart looming in the background. It was supposed to be a story about survival and dealing with impeding death, etc. Not a very good idea for a 3-day game jam.
Then, someone in our brainstorming group suggested a game consisting of a number of arcade-style mini-games. Although I cannot guess why, for some reason Heartbreak–a mix-up of the classic arcade game Breakout where the player controls the blocks instead of a ball, with the blocks arranged in a circle around a beating heart that serves as the player’s life counter–sprung immediately to mind. I abandoned the over-complicated concept of a point-and-click adventure game and clung to this new concept.
When we returned to the lecture hall and game creators began separating to work on individual games, I found myself almost working alone, since my concept of an arcade game about moving colorful blocks around a heart sprite didn’t quite grab attention in the same way that some of the other concepts did, but I managed to hook a couple people who claimed to be experienced with programming in GameMaker. With that, we all broke up again into different classrooms to begin constructing the games we’d gone with. My group was, by far, the smallest, with most groups having 6 to 10 people on a team, and I with just 3.
The two programmers set to work surfing the Internet and half-heartedly (forgive the pun) looking up tutorials while I fiddled with some sprite art and designed the game in my head. That’s how most of the first evening was spent–simply thinking while I worked. By the next day, after a short sleep and a lot of fitful half-awakedness, the game, simple as it was, was fully-formed in my mind.
The only remaining problem was that the two programmers claimed that the concept couldn’t be done in GameMaker (something I intend to prove wrong during this mini-LD), and so our little team was stalled for a few hours until a very nice and quite talented Unity3D programmer stepped in to join our group and get us on the right track. Said programmer made the game in Unity entirely on his own, with me hovering over his shoulder like a fussy mother, directing every aspect of the game’s design.
To cut an already too-long story short, our little four-person team (the two GM programmers were delegated to sound work, which meant searching Newgrounds for some music tracks and finding a few arcade-like sound effects) ended up winning “best designed game” for the Game Jam at our university, as well as “most popular” among all those students at our university who participated. A humble honor that was all thanks to the nice programmer who stepped in to make the game for me. It fired off a brand new interest in game development that I’d not really had before, and I’m still waiting to see exactly how far it will take me.
Ah, it’s good to be doing a Dare again, even if this is just a mini-Dare.
Since my first LD, which was completed using Visual Batari Basic in order to create a game that runs natively on the Atari 2600, I’ve been experimenting with various engines and frameworks, including Construct 2, Loom, OpenFL/HaxePunk, LOVE, and, most recently, GameMaker.
I tried learning each of these engines by re-creating a Pony-clone of Tapper that a friend of mine made, since he gave me the already-made assets to ease development. Although progress has been slow because I’m sick of re-making the same game over and over, my experience with the engines was as follows:
Construct 2: Although I felt a bit patronized by the drag-and-drop coding interface, it did help to simplify the coding. In the end, I built in all the core functionality, but lost interest with Construct 2 when I attempted to export my game to mobile. Unlike Loom, OpenFL, and GameMaker, there is no direct push to mobile option, and instead I was just given a folder of assets that I’d need to manually compile using Cocoon Launcher… which never worked for me.
So I gave up on C2 pretty fast, though I can see the appeal of it for beginners who are looking to make games on Windows/Mac/Linux or HTML5. It compiled to those platforms very easily.
Loom: This engine was recommended by one of my game professors, as it’s a relatively new engine that is built for rapid app development, which is great because I was looking to make the game on mobile. The down-side is that the documentation for Loom is very sparse. For those familiar with ActionScript 3, LoomScript is heavily based on it, so I’m sure it would be a snap.
Unfortunately, I don’t know ActionScript 3, so I found it very frustrating to learn a language from scratch with little more than a handful of basic, outdated examples and an outdated API (because LoomScript is updating so quickly, much of the documentation is out of date). It was very good at live development on mobile, though. I just never got beyond building my game’s title screen.
OpenFL/HaxePunk: Initially, I was excited for this, as I saw it as an alternative to Loom. It’s a much more mature engine with better documentation and, while it doesn’t have live update like Loom does, it pushes to mobile just fine. Unfortunately, the language barrier of me not knowing ActionScript 3 again became an issue when I began to hit the limits of the tutorials and examples.
Unlike Construct 2 and Loom, HaxePunk can boast Papers, Please as a commercial product created using it. Once again, I didn’t get far beyond building a title screen before moving on to something else. As with Loom, I’d recommend it for those who are already familiar with making games in Flash, as I’m sure it’ll be fairly easy to pick up.
LOVE: This was my first time trying to program in Lua. Prior to this, my programming experience was only with C and a tiny bit of C++ (which I am currently taking a college course on). I immediately liked Lua’s dynamically-typed language and the flexibility of it. Tables are awesome! The only issue is that LOVE itself is very much a framework. I think it would be perfect for certain kinds of games, or for those who have experience with Lua. I, being a newbie to the language, had to rely heavily on plug-ins and additional frameworks to support animated sprites, object-oriented classes, and collision detection, which the engine does not come pre-packaged with (not completely true, as it does come with Box2D, but I didn’t require that level of a physics engine).
I got most of the framework of my Tapper clone built in Lua, but I was already nearing 650 lines of code by that point, just having laid the foundation for the game itself, but with no actual gameplay or levels implemented. On top of all that, LOVE does not have native support for HTML5 or mobile, and the plug-in support for both those platforms has been halted for at least a couple years.
In the end, I enjoyed LOVE, but I found making a game of this type from the ground-up to be frustrating. I think that I will return to LOVE if I ever have a game intended for desktop platforms that doesn’t rely much on object-oriented, but not until then.
GameMaker: It’s ironic that GameMaker was the first engine that I was ever introduced to, and yet the last I came back to. I never really did any programming to speak of (unless you count one mandatory C course and HTML/CSS) until I had an interest sparked by last year’s Game Jam. I wasn’t on as a programmer, but an artist (more because I knew nothing about programming, rather than because I was particularly adept at art). The game that I will be remaking, Heartbreak, was more one that I designed, rather than “made” per se, but it’s still the first (and only, unless you count Atari 2600 mini-games) original game that I’ve made, so it will be my focus of this Mini-Dare.
When I first designed Heartbreak for the 2013 Game Jam, I had a couple “programmers” who claimed to be decent in GameMaker. The first day of the Game Jam consisted of me designing the game’s mechanics in my head while I worked on simple (very simple) pixel art to build the game in GameMaker. I knew nothing of the engine at the time, but after an entire day of the programmers surfing the web and allegedly looking up tutorials, they claimed that the game simply could not be made in GameMaker. Since I had no experience with the engine, I was frustrated by this news. Luckily for me, another programmer stepped into the group at the eleventh hour to make the game in Unity.
With my sense of GameMaker having “failed” me, I begrudgingly avoided it as a useless prototyping tool that couldn’t make anything really “serious.” After trying all these other engines and frameworks, I find myself crawling back to GameMaker like the prodigal son. I’m aware that it still has problems, such as being very inefficient with its resources (according to the bitter folks over at the #GMC GameMaker IRC room), but I can’t sneeze at an engine that has been used to make awesome games like Spelunky, Hotline Miami, and, most recently, Hyper Light Drifter. If it’s good enough for games like that, it’s good enough for me.
In giving GameMaker a chance (I’ve been fiddling in it for about a week or two, whenever I can muster up the energy to go back to the Tapper clone that I’ve remade so many times, I hate its guts), I’m immediately drawn to how much it simplifies the organization of game code. I feel like I’m scripting more than “programming” per se… and I like it.
GML is very similar to C and it hides the annoying Java/ActionScript 3-inspired object oriented faffing that I had to deal with in Loom or OpenFL. Code is organized into easily-managed blocks within objects that are called from basic events, keeping it nicely organized into manageable scripts rather than giving me a 600-line file of code to just lay the groundwork for things. On top of all that, it has tons of tutorials, plug-ins, and shaders available online, AND it can push to mobile with the press of a button (if you have the Pro version, like I do).
I know that it’s not an end-all solution, but I think that it’s a great place to start, and even though I’ve only actually programmed in it for a whopping total of 10 or 12 hours at the most, I feel confident enough to try remaking Heartbreak in it, which is more than I can say for any of the other afore-mentioned engines and frameworks, aside from maybe Construct 2. The downside of C2, though, is the entire lack of the ability to write code. It forces the user to rely on its drag-and-drop system which, while powerful enough for basic game types, takes a lot longer than just writing raw code, lacks a lot of the flexibility of plain code, and it’s a pain to organize once the event sheet starts to get long.
I’m sure that someone with more programming experience will look down my choice of GameMaker, but I’ll say that I’ve only actually been programming for about six to nine months, and most of that was in a non-object-oriented language. The entirety of my non-Assembly/BASIC programming experience has come in the past two months, or so. I have to start somewhere.
Although this post was long-winded, I hope that some find it interesting or helpful in their own selection of an engine. Now to write a post about Heartbreak and why I am remaking it. Maybe after all this blogging, I’ll even have a little time left to make a game. Maybe.