Posts Tagged ‘journal’
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.
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.
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.
So, recently I got bored and got an idea of creating a new game. First idea: MMO. Then “well, I’ll need to write both server and client and deal with networking stuff”. Goes out.
Second idea: make something small. And, after an hour here’s it:
HP and MP are hardcoded and unchangable, but hey, that’s alpha
Then decided to move forward. Already got mapping stuff (currently hardcoded table of integers, to be replaced with files), working walls (with deleted ghost-mode :] ) and with some nice green grass. Doesn’t it look beautiful?
Hey, this is my first game without using Game Maker or any other stuff, don’t blame me
It’s confirmed to be working on Debian, Cygwin and WinXP. Tested it through SSH on my phone, too :
If you feel interested, have a look into sources hosted on my GitHub. You’re welcome to drop your hates below, too!
PS: Maybe it’ll go for next 48h, who knows..
After the ludum 27 48 hour compo, I continued to develop Turn Fighter Foo in order to bring out a version that is closer to what I had imagined.
So whats new?
The first major thing (not visible though) is that the code base has been ported from Flixel with Actionscript/Flash to HaxeFlixel with Haxe/OpenFL. Doing this has the advantage of being able to port it to other platforms natively. Expect something like gamepad support on desktop or a mobile version sometime in the future!
There are a few new hit animations for the fighters as well as new animations for the new moves that they can perform. The background has been spruced up a little to make it less bland and some background music thrown in to accompany the fighting. Here is an example of what to expect:
The first major change is a rebalancing of the play matrix for moves. You might have noticed that kick is probably the most overpowered move in the 48hr compo version. I’ve tried to create a version where there is always a counter to any move. For example, kick is now countered by the low sweep like the picture above shows. And air attacks can now be countered by a new uppercut move. The play matrix is still not perfect but it is far better than the 48 hr compo version. Along with the new normal moves, there are also a couple of special moves that I’ve added which were inspired (aka ripped off) from most fighting games. The first is a ranged fireball attack and a move called the phoenix punch which kinda resembles a dragon punch (very original I know! ). Have a look at the moves list below for how to execute the new moves. More special moves to come in future versions hopefully.
The post compo version now has several options that can be customised such as the ability to hide your inputs from your opponent, increasing/decreasing the number of inputs per turn and changing the turn timer duration (or have unlimited time). The last option enables Turn Fighter FOO to be played in Ippon scoring mode which means that a turn ends as soon as one fighter performs a decisive blow on the opponent scoring one point. The decisive blow occurs when one fighter performs a move that naturally counters the opposing fighter’s current move, thus getting the hit. Score three points and the match is over.
Last but not least, I’ve added an AI player for those that do not have anyone to play with. Yes, there is now a single player mode! The AI is not great but it should be enough to get a flavor of what the game is all about. I’ve gotten feedback regarding my compo version about how some players didn’t have a partner to play with so this one is for those players!
The post compo version of Turn Fighter Foo may be found (along with the original version) at my ludum 27 entry page here.
New Moves list
- Upper cut – down, punch
- Low sweep – down, kick
- Jump punch – up, right, punch (if facing right)
- Fireball – down, right, punch (if facing right)
- Phoenix punch – right, down, right, punch (if facing right)
- Duck – down
- Idle has been removed as an input. Use block instead.
- Controls for player 1 has changed to w,a,s,d for up,left, down,right and j,k,l,n for punch, kick, block, clear move list.
- Addition of new ready button for the unlimited time match. When both players hit the ready button, then the turn plays out. Player1 ready – space, Player2 ready – end.
In 10 Seconds to Loot.., you’ve got 10 seconds to collect as much loot as you can before it quickly become impossible to escape alive. Gain as much wealth as you can and try to make it through to the last level.
This was my first time taking part in LD, and overall the experience was great. I actually finished something playable (!).
I had been banking on ‘death is useful’ and didn’t really have any solid ideas for 10 seconds.
After a couple of hours at the start, I decided on ‘10 second of greed / rapid dungeon crawler’.
What went well
I actually think, SOMEHOW, most things went right. This was my first time doing a jam like this and surprising nothing went dreadfully wrong.
The concept and the game are actually fun, mostly
I was afraid I’d end up with an unpolished game that wasn’t remotely fun, or was so unfinished it didn’t really come together. I’m really happy with the end product (although it is FAR from the ideas I have for it).
It all came together in the last 90 minutes – before that point I didn’t even have the facilities for multiple levels or victory/loss conditions.
I’m pleased I didn’t just use the 10 seconds as a ‘hard’ time limit on each level. That was the obvious approach and I wanted to try to do it a little differently. I think with a bit more polish the ‘level collapse’ mechanic I have (currently, fire quickly spawning throughout the level after 10 seconds) will work quite well.
This was the first time I’ve actually created some art for a game. I have always shied away from trying properly, as I am hopeless with colours and perspective. LD forced me to give this a go and in the end, after some research and the use of DawnBringer’s awesome 16 colour palette, I made some graphics which I’m quite pleased with.
What could’ve been better
The code for the game is a shameful mess by my own standards. Bad practices and habits all over the place and it’s going to be hard to continue developing it. Not being familiar with Unity made this even worse.
Familiarity with tools
I decided this would be a great opportunity to develop a game using Unity for the first time, as it should save time overall. That probably wasn’t the best idea I ever had, as it quickly become slow-going while I figured things out, particularly on the coding side. I’d played around with things in Unity in the past but never actually created a game.
I got distracted by other things going on and other people too many times, and ended up losing a lot of time overall.
When it came to about 90 minutes before submission deadline, I realised I still only had one level, no victory condition and no title/menu screens. Woops.
Conclusion & future of the game
In the end this was a great experience and I’ve no doubt I’ll be taking part in many LDs to come. The best part is getting feedback from many different people and the community overall.
I’ve learnt most of all that I need to plan my time, prepare in advance and focus better.
I’m going to be developing this game further, I have a lot of ideas planned for it. Hopefully it’ll see the light of day again.. one day.
Ludum Dare 27 has been my first ever Ludum Dare competition.
I was not sure of what was going to happen, if I were capable of finishing a game in under 48 hours, if I would have felt stressed or relaxed, et cetera.
For the competition, I decided to use C++11, SFML, and my own framework, SSV, which is free, open-source, and always looking for contributions/critique.
My development environment was Arch Linux x64, using QTCreator as my IDE, and Sublime Text 3 as my text editor.
The development machine uses an Intel Core i7 processor, NVidia GTX275 and 10GB of DDR3 RAM.
My goal was producing a game that was worth playing in under 48 hours, with native Win32 and native GNU/Linux x86 binaries.
I’m very happy to have reached that goal, and I’d like to share my thoughts about the whole development process.
I worked on the game for about 30-32 hours. I slept, worked on a video for a friend’s birthday, and relaxed for 1-2 hours (played some Spelunky and browsed the internet).
The first thing that surprised me is that I felt constantly stressed. I do not know if everyone feels like this, but I couldn’t stop thinking about the deadline, about the end result.
I have to say that, as far as personal feelings go, I didn’t dislike the 48-hour deadline development process, but I didn’t find it fun either.
However, after finishing, I felt a great sense of satisfaction and reward, which kind of made up for the stressful coding hours.
The second thing that surprised me is that my framework, the SSV framework, was up for the task of creating a game from scratch.
It literally took less than an hour to get a prototype where I could walk around.
A big effort in SSV was put into development of SSVSCollision, a header-only pseudo-physics library intended for retro-style games.
It handles collisions very differently from all other engines out there, and, while not suitable for realistic physics simulations, it is great for retro-style games, where physical bodies do not interact much with each other, but have infinite stability and very precise collision resolution. Here’s a video of it’s performance.
It also lacks all sort of issues that would arise with a realistic physics engine, such as the common error where bodies get stuck between tiles in tile-based worlds.
Anyway, I also created a player sprite, which I had to divide in two parts (arms and body) to avoid repeating unnecessary frames. I used Pinta for the task, a Paint.NET clone for GNU/Linux.
I’m not an artist, and that is obvious by looking at the poor end result of the player sprite. I used the same tool to create all other graphics in-game.
I dealt with sounds by using sfxr, the free, open-source sound generator advertised on the LD website itself.
For music, I used LMMS, a GNU/Linux production software with an UI similar to Fruity Loops. I’m not a musician either, so the end result was poor here too.
The game concept was actually created after the prototype version. I had no idea what I was going to make. I just made stuff and tested stuff.
Then I had the idea of this cool throwing mechanic, where suddenly turning your character would increase the force of the throw.
This is where stuff started getting interesting. I had to deal with my peculiar physics engine in order to allow the player to grab/throw/release blocks.
It went pretty smoothly.
This is what the first grabbing prototype looked like. I also had added the number on the crates but had no idea how to use those yet.
I also had no idea how to use the crates yet.
Then I combined the throwing concept/mechanic with a time-based constraint (10 seconds theme), and had the idea to make the game into a reflex-based, time-based puzzle platformer.
I designed some game elements and threw some test levels together. But I didn’t have time to create a level editor, or to write a JSON level specification. So what did I do?
Tab based in-code level editing. Dear god.
Yep, I used tabs, newlines and spacing to re-create the structure of the level in the IDE itself, so that I could have a rough idea of where I was placing elements.
After making some levels, I created a menu screen, which was very easy thanks to the SSVMenuSystem module of the SSV framework. And that’s pretty much it.
There is a problem with level 5, which is almost impossible because I forgot a game element. But it is actually possible, even if insanely hard.
I’ll judge the game myself, now:
Innovation: I’d say the game is not unoriginal. The turn-based/jump-based throwing mechanic is pretty fun to use, and the game elements, while simple on their own, can be combined to create some interesting puzzles.
Fun: This is a very subjective point. The game is not easy, and can be very frustrating at times. Honestly, I find hardcore games pretty fun – I enjoyed playing my game, even if trying the fifth level for one-hundred times got frustrating quickly.
Theme: My interpretation of the theme is not very original, but I think the 10-seconds constraint that resets works well here.
Graphics: I’m not an artist, and it really shows. The sprites are of poor quality. I tried to redeem myself by creating variations of tiles that appear randomly and maintaining a simple flat look for the game.
Audio: Sfxr is a godsend. I love retro sound effects, and they work well here, I think. Music, on the other hand, is not catchy or memorable, and it’s just a simple loop. It was my first time ever producing music. Here I tried to redeem myself by adding a no-sound and a no-music option to the main menu.
Mood: I tried to create a simple story/world around the game. Basically, you’re working for this company, 10corp, in a futuristic (I guess) setting where getting a job is very hard. In order to survive, you have to work for this company, even if they terminate slow workers to maximize their profits. I used in-game messages (broadcasts from 10corp) to give the feeling of the player being observed and judged during its tasks.
Overall: Overall, I am satisfied with the end result. I’m still not sure if the game is worth improving, but as a less-than-48-hour product, I’m happy with how it came out.
I really hope you enjoyed my entry and this postmortem. Thanks for reading!
Hi LD people!!
First LD for me here! Hope I’ll have inspiration
I think I’ll go for a 2D game.
I’ll use :
- Unity with uni2D
- sfxr (if I have time for sounds)
Good luck to you all and the most important: have fun
Well, if you saw my post yesterday about not being here for thew Compo, you will know I am making my game now, and will be submitting it via my phone while on vacation.
I have made a little bit of progress in the about hour and a half I worked last night. The game will be a FPS, with a twist, keep the enemy alive.
Firstly, the theme I am going with, pigs, has turned into monkey pigs:
I have also made a second model for walking, but I need to redo it.
Secondly, I have made a todo/idea list which you can view here
The idea of the game is that you have pigs attacking you, but you need to keep them alive, as their genetically modified farts are the only source of oxygen when we have killed all flower and tree life.
The challenge of the game is that we all know that you can’t have monkey-pigs, without bandits to attack them, so you need to keep the pigs alive, while they are attacking you, while bandits are attacking them, if the game is finished.
I am going to start to work in unity now, to make the game mechanics and move towards the end of the todo list
Well, progress has definitely been slow on my end. The hardest part of this is to find a game that I can make in this limited amount of time with my limited amount of knowledge. In short, I’m a noob in this type of challenge, especially since this is my first miniLD.
To keep me from being deterred, I press on. For the sake of scope, I decided to do a sort of real time tactics instead of a traditional real time strategy. This should fit the challenge enough to complete a competitive entry, and I should be able to finish as well. So far, the idea for my game revolves around a French trapper who must trap animal s to upgrade his gear. It will have to have the process of building in the game to truly have the element of a real time tactics game. I thought about the name Frontier: Quebec for the name of the entry. I think I’ll stick with this name for now.
I have coded most of my scripts for the Unity engine for the sake of the game, but most of it is on paper at the moment. Hopefully I’ll have time to type it (hilarious, right?). Anywho, the only other thing that I have been doing is listening to “Farewell to Nova Scotia” by Gordon Bok to get me in the mood for the game development that I have later.
I’ll update later, and good luck to my fellow developers.
Here have a splash image!
Day 1, Part 2
After settling into the routine, I managed to get significantly less done than before. Nevertheless, it’s better than nothing.
*Attempted Gamepad support
*Put it on hold because it wasn’t working
*added sound effects
*Made Multiplayer more chaotic
*Added buttons for different controls
*Also put it on hold because of the gamepad issues
At this point, if it weren’t for the bad graphics that people watching my stream could notice I could consider this done, but then I still don’t know if it’s ready for submission – we’ll just have to wait and see.
Day 1, part 1
The night before was intense. I could not sleep, especially knowing that my first major game – to be made within 5-6 days – would start tomorrow. I set the alarm clock to 5 AM, and started working on it an hour later.
For the most part, the game mechanics are done. Sharks, seagulls, sailors, so on and so forth. Multiplayer is pretty much done, though I still have to test it with a friend.
I guess you guys want specifics, so here they are!
*Made the game controls for the seagull
*added mouse-only support
*removed mouse-only support
*added keyboard support
*”hey that’s pretty easy : D”
*So long, and have some fish!
*Added base credits
*Added endless singleplayer
*Seagull doodoo everywhere
yeah I’d better stop there before I gross myself out
for the first 5 hours, not bad! The graphics leave much to be desired, though, so no info on that quite yet :/
Goals for now: Online Multiplayer, sound design, testing, outsourcing graphics to a talented artist named BeGamer who’s working with me!
I’ve been going around trying to test and rate some of the games. One thing that I like is how this competition heavily encourages you to rate games, so your own game gains visibility. I feel this helps create the great community for this competition.
I’ve personally been checking my entry page every once in a while to reply to every comment and thank them for checking out my competition, and check out their game if they have a submission. I feel like I really want to give back to the community, and really like getting constructive criticism.
I remember there being a lot of complaints on the IRC chat after the theme was announced. I personally really liked the them, because it forces you to cut out unneeded elements from your game until you get straight to the core of the game. That, at least, is my interpretation of the theme. I feel like if you really embrace the theme, you can get a lot out of it, no matter the theme. It really gets you to think outside the box, and outside your comfort zone.
Saturday morning , around 6:00 CEST ( Paris), I woke up and immediately turned on my computer. After some everlasting minutes, I saw the theme : [Minimalism]…ok: Challenge accepted!
[Brain)]: “so Minimalism…minimalism….hum…[open google]…ahh!…That’s great…yep there is something there…[See Mondrian stuff]Uh?…wait a minute…oh yeah!….YEAH! This is THE THING I WANT to do!”
>>|Saturday|6:40 am | CEST|: CONCEPT DONE <<
[[ Code, code, code...]]
>>|Saturday|3:40 pm | CEST|: AVATAR CODE DONE <<
[[ Code, code, code...]]
>>|Sunday|00:20 am | CEST|: CORE GAMEPLAY DONE <<
[[ Code, draw, code...]]
>>|Sunday|02:30 am | CEST|: SLEEP TIME! <<
[[ Brain's dream : code, code ,code...]]
>>|Sunday|07:00 am | CEST|: What year it is?What is that place?….Aah right: Ludum dare! <<
[[ Code, code, code...]]
>>|Sunday|1:40 pm | CEST|: GAME NAVIGATION (menu&stuff) DONE <<
[[ Code, rage, code...]]
>>|Monday|2:50 am | CEST| H-1h: LEVEL IMPLANTED <<
[[ Think, write...]]
>>|Monday|3:10 am | CEST| H-30m: PROJECT NAMED <<
>>|Monday|3:30 am | CEST| H-30m: PROJECT PUBLISHED <<
A thousand lines of code and a blurry vision later, I had a little “game” (without real tweaking ) that I threw in the arena and went to bed.
Today, I wrote a post-mortem about it…
What went right ?
- Using the tech: at least enough to be comfortable for coding the whole core concept without researching and being stressed about how to do every little things.
- Having fun : what a relief it is to just enjoy the challenge, the community and all the little things that community produced. As a result, I just enjoyed the whole LD and even more, touched from the tip of my finger this “territory”: where you built your game without be harassed by technical pitfalls or unknowns life crisis and having fun by doing it! Well it’s the key…
- Loving and quick idea/concept : or how to have a core concept about forty minutes after waking up ! Well, as a “beginner programmer”, to have a concept that you love,that you are capable of doing it and this the earliest possible is a rare delicacy: that allows you to be focused on the damn coding thing!But it has its hidden traps…see below!
- Mondrian : I know…It wasn’t the theme…But I do think it help me designing the concept and that concept is well adapted to the theme as a minimalist dungeon explorer!
What went wrong ?
- Too focused on the production aspect: At the point that I didn’t pass much time on the conception: questioning the theme, thinking about different ideas, deepening the core gameplay. I did have others ideas but I quickly chose to go with that’s one. It’s not entirely a negative thing to quickly choose but it became a major weakness if you didn’t clearly identify the core features of your gameplay, the ones which are literally the border between an experimental “thing” and a game(with defined rules, a goal…) .To be too much focused on the tech part ended like: – My brain : “Is it a scoring game?But you have too much to do. So…here, write a score formula in 10 seconds, it will do! Trust me…” Ahem…So this time, I did have flaws in my game design and I didn’t said :” Stop! Stop producing like a mad man and take a moment to think about your gameplay!”. Next time, I will…
- No level Editor: Raaaaahh! I can’t use a tiled editor and I don’t have time to create my own level editor. ‘have to place every little things the old way! (by the way: thanks Mondrian for the basic Level Design.) – My brain(again): ” So we said about 4 or 5 levels? How about one fake-tuto level and one basic level? Yeah…That’s it! Oh! And you have to forget the polish&sound time because this task will take you every minutes left…Have a good night!”
What I failed to do :
As expected for a 48H project, There is many defaults but I only have one little thing about which I’m a bit mad:
Why I treat you so badly, so unfairly? Because you’re not important? because I don’t have any time left to make you? It’s a mistake… Sounds = Universal Feedback, Music = Mood levels up like hell! In my case, the solo use of the sound should have greatly enlightened what happen to the avatar entering my little white rooms. So I failed that part…(this time at least!)
- For the project itself – (link)
I want to take time to polish that one. That means:
- Add sounds,musics…anything even noise!
- Change Avatar’s controls
- Add dynamics feedback.
- Insert a real Scoring formula…
- Maybe, potentially… create a level editor.
-For the next Ludum dare-
Be even more comfortable with the tech…
…for really focusing on the concept and theme!
Make and use sound, music and noise !
Having fun again and again and forever…
Below is a fairly accurate account of how my weekend went while making F*** This Job
0830 Got up, had porridge and a cuppa, got dressed
0900 “Minimalism? Bugger.”
0930 Lots of Googling, etc. “Minimalism…Do more with less”
1000 “I’ll make a one-button roguelike!”
1030 “Screw that.” Decided on a one-button platformer instead
1100 Drew complicated sketch of how the game will play
1130 Guy is now running and jumping back-and forth
1230 Basic level loading and tiling done
1300 Wife asks what happens if you hold down the jump key. Turns out the guy starts flying. I assure her it’s a feature…Not a bug
1400 Added spikes and player deaths
1500 Went to ‘Burger Off’ to refuel
1730 Back to work, added the stegosaurus thingy which would later become the mutant rat enemy
1830 Added exits – levels now have a start and an end!
1900 More enemies that look nothing like they’re supposed to (except the gun turret…That sort of looks like a gun turret)
2100 “It would be awesome if I could add Super Meat Boy-style replays…”
0000 Somehow added Super Meat Boy-style replays
0200 More enemies, tile types and general bug fixing. Added just about all the mechanics and elements so I can focus on polish and level design tomorrow
1030 “Oh **** it’s still Ludum Dare!”
1100 Fixing up the main menu and level select screen
1200 Found my dusty Wacom tablet…Time to make an intro
1400 Finished the intro and outro. His fingers look weird but whatever
1500 Designed a few tutorial levels
1530 Ran out of bacon, went to the shops
1630 More levels, bug fixing the replays
1930 Redid a lot of the art for the enemies, spent ages trying to make a decent run animation in 3×3 pixels (didn’t work – he looks like he’s moonwalking)
2200 Added sounds – thank you AS3FXR!
2230 Added a poster to the intro and main menu (bonus points if you recognise it)
2300 Home stretch! More levels
0100 So many ideas for levels but they take *ages* to tweak and get right! Oh well, 24 will do for now
0130 Compiled and submitted
0200 Final tweaks and fixes… Need to get up for work in 5.5 hours, better go to bed
Hi there again!
Today we finished the assets and the most important parts of gameplay implementation, there’s one little thing that I liked to make, but ah well, things weren’t working out very nice, and since I managed to do the main thing that I wanted to implement, I think that’s ok for now…
So, first things first!
We have a logo! YEAH!
I really liked this logo, I think we managed to get something quite stylish, game related and minimalist, this one was made by me with the help of Hexels! An awesome software for drawing stuff with hexels, many thanks to @saint11 from miniboss for showing me this jewel!
Btw, for those who didn’t read the past WIP, RED stands for Red Eyes in the Dark!
About that thing that I managed to implement, here’s a look at it
Already know what it was?
Yup, I implemented a little system to make the AI predict the players movement before it called up the pathfinding algorithm, because it wasn’t very useful before, it was almost impossible for it to catch the player when it was just following its current position, so, to make the experience meaningful this was a must do!
In the case above, I just moved the player to the left and the AI aimed correctly according to the player’s linear velocity, but it also takes angular velocity into account when needed!
Next up are more aesthetic than functional things we made today, the first one we did was actually having the idea to take inspiration in minimalism quotes to inspire the level design of the stages, which we plan to make ten at most, maybe 9 and a final boss, maybe…
We really liked this font, for some reason it creates a dark atmosphere around it, we liked the idea of it being kind of typewritten, it’s like the kid (read the past WIP for story stuff) was making annotations of its experiences, really awesome!
We also finished the final UI of the gameplay scenarios, here it is
It will be possible to have more than one enemy at the same time, and they may have different sizes and speeds, it will be a really fun game to play and the challenge level is quite awesome!
The three blue bars up top are the battery level of you flashlight, they will go down fast, so you have to make it past the creatures fast, or else the lights go up and then the red eyes creatures will be unstoppable.
The little beam of light on the top right corner is the exit, the player’s objective is to get to it! I think we will have to make it more viewable, I think it is quite dark as it is now, more stuff for the last day!
For the last day we will be finally getting the sound stuff and effectively design the levels and stuff, I wish we had done a bit more today, but the event slowed us down a bit, as our workplace was used for the speedpaint session of our artist, Joao, that made this quite impressive piece there
Still unfinished as he told me to say here!
And here are we again, at our little booth, this time the whole crew getting in the frame!
From right to left: Joao, Pablo, Tiago (me =D)
Thanks a lot for your attention! Final updates and game ready tomorrow! Have a good Ludum Dare!
So, spent lots of time and work on the sort-of-game idea I had for the theme. Math was involved and sketching occured, evidence can be found here:
All in all, I feel pretty good about how the game is coming along, haven’t started making it look good yet. Gameplay goes first.
There are a couple of command line switches you can use:
-b Rebind all controls before starting the main loop
-r WxH Specify resolution
-m 0-100 Specify music volume
-s 0-100 Specify sound volume
Standard controls are WASD, and if you’re using -b then you can bind to both keyboard and joystick controls. It’s been tested with both an original Xbox Controller S and the Xbox 360 controller.
Also, I know that something is strange about collisions, at times they don’t seem to register at all. This is a bug that I’ve spent too much time trying to track down, and so sort of decided to leave it there until it becomes a more pressing issue.
If you happen to have a 32-bit Linux system, then you could try to build the game yourself. The source is available on Github (C++) and it uses CMake to build, you might need boost and SFML 2.0 (Don’t know if the RC works since I’m using the latest git myself).
There’s a small issue with the CMakeLists file so you might also have to set Kunlaboro_BOOST to On in your cmake cache for it to build properly.
Hope that you’ve enjoyed reading this (And maybe even enjoyed what exists so far of the game). Please comment.
This is Ace, reporting to bed.