Woo! I fixed all of the bugs that were affecting gameplay in Match Strike. 馃憤馃憤馃憤馃憤
I did upload a stand-alone Win64 build, but it still crashes on exit. I'm still working on figuring this problem out, but it does not affect the game in any way.
Thanks everyone who played and commented!
Put together a trailer just for fun. :smile:
https://www.youtube.com/watch?v=TgTUz4eYZ9k
I tried to be clever and fly between the blocks as they were moving...
That feeling when you've been having a crash problem with your Unity game, thinking it was your own code, only to find out it was due to some bug in a new feature of Unity that you decided to use last-minute during Ludum Dare.
At least now I know how to avoid it. By not using said feature! 馃憛
I'll explain in detail during my postmortem.
Well, I got to say, this LD was a lot of fun for me. I'm going to share some of my experiences I've had to with creating Match Strike, my LD#41 entry.
I checked the theme with some trepidation; The sort we all feel, where we expect it to be a weird theme that we will blank on. I know we've all been there. "What do I do?" "I can't think of anything?" "Maybe I should just...make a 2D platformer and shoehorn the theme in?" :grin:
But this time? I was prepared! No, I don't mean that I had already looked over the theme choices and individually crafted an idea for each one. Some of you might be able to do that, but my brain is too small to hold all those possibilities. What I mean is that instead of having tons of ideas, I had been thinking about a flight sim. I don't know why, other than watching longplay videos of F-15 Strike Eagle or Red Baron (great DOS games), and waxing nostalgic for those old flat-shaded 3D polygon worlds.
So when the theme landed, I knew instantly what I had to do. A flight sim as genre #1. But what about genre #2? What would be the worse thing to combine with the high speed, low accuracy of a flight sim...? I barely had to think about it. A match-tile game! Let's call it Column Strike!
Originally, I wanted to do a match-3 game, such as Candy Crush or Columns. (Hence the name.) You'd be tasked with flying to parts of the world and pick up combinations of blocks, and then fly them to the target. Right! Vague idea, but I got it. Let's start work.
It didn't take me long to sketch up the basics. First was the plane. I didn't want a realistic flight sim (since that would take too much time!), so I modeled up a futuristic looking craft that had some basis in the real world. At least, the concept art of what the F-19 fighter was supposed to look like...
Once I had the plane, making the world was simple. Pixel-art up a flat terrain, and I'm done! No need to be fancy here.
But the next step? Making a flight HUD. This part was fun. Lots of fun! In fact, I think I spent most of my time on this for day 1. It was complete overkill to have a HUD with altimeter, airspeed, artificial horizon, and so on. But I just wanted it. So bad. And it was worth it, as that HUD would act as the foundation for every other decision I would make about Column Strike.
My end of day I was nearly done with all of this. The artificial horizon wasn't working properly, but I was pretty tired at this point, and the math part of my brain wasn't math-ing. I put it aside and then went to bed for some much-needed sleep!
I'm overwhelmed by the amount of attention by entry for LD #41 has received! Thank all of you for giving it a try, and for all that awesome feedback!
So, as we last left my postmortem of my game Match Strike, I was starting day #2 with a working flight sim, for the most part. The plane could fly, and the HUD was working. I had a small bug with how the artifical horizon was rendering, but the fix was simple: I just had to fix the pitch-calculating code. Pretty basic mistake, but my sleep-hazed brain couldn't figure it out just 8 hours prior. :)
Right! So we have the basics of flight. But now what? The Match-3 concept just wasn't going to hold up. I'd need a way to select which 2 blocks to swap, and after some thought I realized that would be impossible for the rapid movements of a flight sim. I had ways around this problem, but they required a lot more coding to make work. So, I decided to swap from a match-3 game (like Candy Crush or Columns) to a simpler, more puzzler-like game called SameGame (originally Chain Shot!). In SameGame, the only action is a tap, instead of a swipe or block swap. That's easy for a plane to do at high speed, right? :)
So I implemented the blocks, just as destroyable entities. My idea for the player's gun to make it work like a hitscan weapon (and any bullets it fired would just be visual effects), which would cut down the delay the player had before a move when into practice. I also spent time making a targeting cursor, which according to feedback was quite a necessary addition.
Right, blocks are now done! Now what? Next up was making the puzzle aspect. The blocks were destroyable, but I had to make them destroy other blocks that they were touching (if they matched), and they had to move. That part I coded up rapidly, which would later end up being a rattlesnake in the grass, ready to bite me post-launch. But more on that, later!
As a further aid to the player, I also added a board-camera, which would always show the position of the blocks onscreen. I wanted this to be rendered as part of the cockpit on the plane, but never had time to come back to that concept...
What's next? Well, just shooting the puzzle block was a challenge, but I wanted more! So of course, the obvious thing: Turrets, which shoot at the player. That part didn't take long to add in.
Now what? Further challenge; Limited fuel! I already had the game loop at this point. You could fly, shoot at blocks and solve the level, and die. But another condition for dying was easy to add. I already had to write code so the game would detect you landing at the airfield, so it was easy to re-use this for refueling.
Most of the game was done at this, but I decided to juice it up. I initially recorded some audio to have a bit of extra flare, but wouldn't it be neat if all the game events had audio queues? I probably spent way too much time on this part, but by the end of Day 2, I had what I felt was a pretty solid product.
So I went to bed, feeling pretty good with my progress.
Last day!
The gameloop was done, and I had enough juice items to make the game interessting. So that was done. Now what? My first step was to make the random level. I decided to have five stages total, 1 through 5, where the final one would be a randomly-generated level. And I'm glad I added that, since it did give the game some re-playability.
I find the hardest part of any Ludum Dare is what I like to call the "bumpers" in a game. These would be: Transitions between levels, menu screen, and so on. This is important to really give a product a finished feel to it, but I can sometimes spend as much time writing this kind of code or designing the art, as I would the actual game itself!
I was ready to go! I tested a few builds, and was preparing to upload when -- disaster. The game crashed on exit, and I mean hard. It's the crash I discussed in this post.
Oops. But I had no time to solve this issue. On to release! Shortly afterwards, I decided to do a WebGL build and see if worked, and viola. It did, and no crash.
It was time to rest after that.
I was starting to see reports of the game being "glitchy" and "buggy" in the comments. Ut-oh, time to investigate! I found a lot of problems with it, particularly the WebGL version, which had broken some of the visual and audio aspects of the game.
First major problem: Keyboard bindings were becoming invalid after dying! This was due to rushed config menu code on the last day, as mentioned above. It was an easy fix.
The second major problem was that I had made an error with my valid board position detection code. It was not detecting valid moves in the final positions, which meant that sometimes the blocks would not slide properly once gaps were introduced in the board. I changed this, which resulted in fixing all the block sliding issues, but it caused the boards to generate new values. I did write separate simulation code to verify that the boards were solvable, though this isn't used in the post-compo bugfix version. (For the record, detecting solvable SameGame boards is an NP-Complete problem, so I didn't feel too bad when it could take up to tens of thousand iterations for my solver to figure it out. :grin:)
A few days later, I figured out the crash-on-exit problem. I had decided to use the new Unity Timeline Director to animate my title screen logo, and there's a problem with playing sound effects from this mode. Disabling that part, and using code to generate the sound effects, and that was fixed. The problem didn't cause any issues with playing the game, but it was nasty to see a this-app-crashed dialog every time you exited the Win64 build of the game... So glad that was solved!
Solid idea for my game. I knew what I wanted, and it was easy to adapt the idea.
Extra Juice. I spent some time juicing the game during its development, and I think that really paid off.
Doing an open-world/open-ended level first, then the regular levels. This gave the game some replayability.
Incorporated a lot of untested code at the end, which ended up causing crashes/bugs. Namely, the crash-on-exit (using the untested Unity Director) and keyboard-binding code (causing the game to lose keyboard bindings on death).
Perhaps a bit too much polish, not enough meat. There was a lot of additions I wanted to add which would make the game harder and give more challenge, but I had to drop them.
Not enough explanation of how to play. A lot of people didn't realize you could shoot the turrets and stun them, for example.
Overall, a very fun Ludum Dare! Over and out, and good luck to you all!
I'm working on a much enhanced version of my LD#41 entry.
It has true terrains, instead of just a flat plane, along with trees and details. Still has the same simple polygonal style, though.
My jam version: Match Strike
It's actually starting to feel like a flight sim now!
Want to play the LD version?
I've been using this little animated Ludum Dare logo in my Unity games for a few years.
I think it's keen and I wanted to give others a chance to use it too, if they want!
The scene is real simple: It consists of a simple shader (which gives the logo its gemlike look) and the logo itself, plus all necessary animation information. It even includes the audio clip of me saying "Ludum Dare."
To use, download the .unitypackage file from here: Chainedlupine-LudumDareIntro-v1.unitypackage
The Github link to the source: Chainedlupine's Ludum Dare Intro (Source)
To use it, just include the files in your project, and make sure the LudumDareIntro scene is at the #0 slot in your Build scene list. It will automatically transition to the next scene once it has finished displaying the logo.
Note: I only say this works in 2017 because that's the editor version I used to export it. It will easily work in older versions, but you will need to import it via the unitypackage or make a new project (and copy over the files) if you try to load up the source project in an older editor.
I'm waaaaaaaay behind.
I finally finished my YaBulletML parser. (Think BulletML but for YaML.)
I'll be doing Ludum Dare again! However, this time I wanted to try something different. I recently pulled my old Apple II from the closet, and I thought it would be really crazy to try to make a game on it. In 48 hours!
Here's my demo code running on a real Apple //e Enhanced:
I feel like I'm doing a really stupid thing; I was never a 6502 coder back in the day (8088 and later was my jam), and it's taken me a week of constant fighting to get a basic tool chain ready.
But, here it is! You can download it right here It uses cc65, python, and a few other misc tools. I've also went ahead and coded up some helper functions, mostly to do simple bitmap transfers and ProDOS file-IO. That gave me the practice I needed to undertake this event.
Hooboy, the Apple II is a fairly poor choice for a gaming computer. Particular when this particular model was released in 1987. (386 PCs were on the market!) Even with the 64K expansion, memory is tight, and drawing raster graphics is really tedious in hires 16-color mode. I am probably going to regret this!
Kudos to the people who wrote games for this thing back in the late 70s/early 80s: You had your work cut out for you, and you weren't using modern tools such as I am...
(Excuse the cheap LCD TV, but my 1084 monitor decided to give up the ghost a few days ago and I haven't had time to diagnose/fix it.)
Woo. I do have something now.
My graphics routines are way too slow to do an action game, so I'm going to take a page from all those Applesoft-based games from the 80s -- make a text-y static-y game!
Working on my mixed graphics/80-column code now.
So I have a name for my game.
Finished my 80-col text routines. Those were fun to write. Not!
Not really a whole lot to show for my day's progress. Hopefully tomorrow I will make up for it. Goodnight!
Update: You can find my disk image right here Requires an Apple //e to run!
Ludum website is acting weird for me. Trying to post a status update.
Is this going to work?
Hello? Is this working?
Okay, this is my last try on posting an update; I need to get back to work!
Not a lot of progress has been made!
Coding in 6502 is hard. I've said that already, right?
Well, I've finished the basic UI for EXUBER&. It all works, though of course there is no game attached to it.
Sadly, this will be my code push to the repo before the compo ends. I was really hoping to do a compo game as I haven't entered one in a while, but alas it will not be so.
Moving on to finishing this for the jam. (I hope!)
