This is madness!

This is MiniLD #44!

The goal is to make an RTS game in 7 days, and I love RTS games.  Not to mention we are allowed to use pre-existing code, and have 7 days, so unlike a normal Ludum Dare I actually have a hope in Hell of getting something done.

Once I get up tomorrow, my 7-Day RTS odyssey will begin!  I hope to blog a little about my progress each day, though it’s hard to say whether or not I’ll have the time.  I will also be cross-posting on my personal blog.

I will be using some code I wrote previously for handling importing graphical assets and moving sprites around, as well as some code for playing sounds and for generating Voronoi diagrams. My first order of business, tomorrow, will be pulling that code together into a seamless whole for use as the base of my game.

My Game

Insurrection, a space-themed RTS game about taking down an Empire while managing public approval of your rebellion.

My Tools

C++, using the SFML library
Code::Blocks as my IDE
Paint.Net for the game’s art
…LMMS for sound?… we’ll see.

So starting tomorrow morning, it’s full steam ahead!  See you on the other side!  Good luck everybody, and have fun!

Tags: MiniLD #44, RTS

So today I managed to pull my disparate code base together, and get the very basics of an RTS up and running.  What I have is essentially a field of more or less randomly positioned planets, as well as some ships that spawn at the start of the game and can be directed using the standard RTS interface of left-click to select, right-click to order.  I also have box-based group selection, though there is a kink with that I still need to work out, and my first pixel art!

Resource management and combat are still a ways away, though.  Tomorrow I hope to at least get the enemy faction implemented, as well as basic combat.

Don’t forget to get your sleep, guys!

So the second day of MiniLD #44 draws to a close, and I have made some good progress today.

First, I added a lot of art to the game, though it is still pretty fugly.  I also tested out an equally fugly random music system I had lying around somewhere.  We’ll see what comes of that.

On the gameplay side, I implemented combat and an enemy faction, space stations, and the fundamentals for resources (no spending or gathering yet, just numbers, functions for changing those numbers, and interface elements), and the fundamentals for collision detection, though for now the only meaningful uses of that are 1) tracking where shots fall, and 2) scanning for nearby enemies.

Tomorrow, my goals are to get trade routes, production, and resource collection up and running, and maybe implement some rudimentary enemy AI (i.e. enemy player AI, not enemy ship AI, which already exists).  If I have the time, implementing placeholder sounds for things like weapons fire and ship explosions might be nice, as well as implementing the graphics for ship explosions.

Good night, and see you all tomorrow!

Cross-posted on my blog.

Tags: MiniLD #44, RTS

So I decided to slightly tweak the theme of my game.  Only slightly.  Now, it’s not just “public approval” you are gunning for; that public approval is reflected in the revenue pulled in by the crowdfunding campaign you are running to fund the rebellion.  Correspondingly, it is no longer called Insurrection, but rather Jumpstarter.

Otherwise, today has been a productive day, but sadly not as productive as I would have hoped.  I managed to get trade routes and resource gathering up and running, tweaked combat code a bit, and I’ve started implementing the interface structure for unit construction, but I haven’t actually started implementing unit construction yet, which is a big deal.  I was hoping to at least get started with that.

Still, there are 4 days left in which to implement production and enemy AI before getting to the more unique stuff, as well as possibly polish (though frankly, I don’t think I’ll have time for much of that).  Tomorrow will be ugly, because I have a really full day of classes, but I’m sure I’ll find a few hours to work on the problem, and starting Friday things are calmer.

Cross-posted on my personal blog.

Tags: MiniLD #44, RTS

So today I had very little time to get things done, compared to the rest of the week so far.  I managed to get unit production up and running without much trouble, though, and also implemented planet capturing.  That means that the fundamental ingredients of the RTS game here – unit command, territory control and economic management – are in!  Yay!

Unfortunately, I am going to bed tonight with an unsolved crash related to particle effects.  Hopefully my fresher eyes tomorrow morning will help solve that.  Afterwards, there is some tweaking to be done, particularly to the interface, but the last major feature to add is enemy AI.  I hope to get basic enemy AI implemented tomorrow, as well as interface fixes and improvements; and I hope to get complete AI and basic sound implemented by Saturday night.  Sunday, then, will be a day for adding fun extra features, if all goes well.

I’m really enjoying the #7DRTS so far, but it is a definitely a bit exhausting, and I look forward to a code detox once this is over.  At that point, I think I’ll sit down and play Shadowrun Returns.

Cross-posted on my personal blog.

Tags: MiniLD #44, RTS

Today I managed to get lots of little tweaks done, such as fixing crashes, implementing population limits, fixing bugs, adding the minimap and tooltips, and adding particle effects and more visual feedback, and so on.  The game is basically playable, with the glaring exception that the AI is not yet implemented.  I’ve started working on the basics, but it’s rather daunting, as I’ve never done anything like this before.  The weather was also awful today, sunny the entire time, and as a result I feel like I’ve been beaten up by somebody with a hot iron, so I wasn’t at my most productive.

I’m going to try and get some extra sleep tonight, and hopefully wake up fresher and able to tackle the problem that is AI.  I’ve got two days to get it done, really, though I’d like to continue tweaking the game and adding gameplay features as well.

Cross-posted on my personal blog.

Tags: MiniLD #44, RTS

The penultimate day of the 44th MiniLD compo comes to a close, I’m happy to report that the game is more or less feature-complete.  I didn’t get the chance to include all the features I would like to include, but I’ve managed to implement all the core functionality I wanted to include, including:

• Spacecraft and immobile space stations
• Unit selection (single and box-based) and command
• Combat
• Income according to public approval rating
• Income from raiding trade routes
• Capturing planets
• Enemy AI
• A win and a lose state
• Basic sound and particle effects

This is great.  Tomorrow, then, I will focus on solving the game’s remaining problems, including a fixing a few bugs and adding missing features regarding unit selection; softening the extremely difficult enemy AI (the AI doesn’t even cheat! If anything, it is handicapped.); adding more sound and particle effects; balancing unit costs; fixing population limits; and generally fixing bugs and trying to track down and prevent the mysterious random crashes I experienced earlier today.

Good luck to everyone else on the last day!

Cross-posted on my personal website.

Tags: MiniLD #44, RTS

So here it is, then – Day 7 of the 44th Mini Ludum Dare.  As this is a 7 Day RTS compo, that makes this the final day – and about time, too, since I really need a break.  I am, therefore, done – here is my first LD submission.

My game, Jumpstarter, is nominally about taking the reigns of a rebellion against an Empire, using crowdfunding (tied to public approval rating) and trade route raiding as a main source of income.  In point of fact, the theme is rather thin; most of my work was concentrating on coding a working RTS, and in that respect, I think it’s a moderate success.

There are several issues remaining – not as many selection modes as I’d like; a bug that crashes the game if you exit to the main menu and try to start it again from there; homing missiles are a little wonky; and the balance of the enemy AI is iffy at best, swinging between hilariously incompetent and ruthlessly efficient.  I played against the AI’s current design and won a few times, but I am generally terrible at RTS games (despite them being a favorite genre), so I upped the difficulty a little bit above my level before uploading it, and I can’t consistently beat it as it currently stands.  Also, ship costs are mostly arbitrary, and are probably not properly balanced.

The game uses fairly standard RTS controls.  You drag-left-click to select all units within a box, or single-left-click to select one unit.  Mouse wheel zooms in and out, WASD pans the camera around..  Right-clicking issues orders, either to move, attack or invade.

There are three ship types and three station types in the game; the main difference is that ships are mobile and stations are locked to their parent planet.  The ships are (in the same order as the build menu)

• The Cruiser, a powerful but expensive ship;
• The Interceptor, a fast and cheaper ship;
• The Dropship, a weak ship that is capable of conquering planets;
• The Shipyard, which is required to build ships;
• The Repair station, which repairs nearby ships and stations fairly quickly; and
• The Turret, which fires homing missiles at nearby targets

To win the game, you must capture all the red Empire’s planets; to lose, you must lose all your planets and ships – that is, you can live on if all you have are ships (but you effectively cannot win if you have neither planets nor Dropships, since you can’t capture any planets).

Tomorrow, I will consider doing a more exhaustive post-mortem on how the development of Jumpstarter went, but for now I need some rest.  Good night everyone!

Cross-posted on my personal blog.

Tags: MiniLD #44, RTS

So against my better judgement, I decided to participate in this month’s Mini Ludum Dare!  I will be building a game in C++ using the SFML framework, and creating my game assets in Paint.NET.  Unfortunately, I don’t think I’ll be able to get a whole lot done, since I also have homework to attend to, so I am scoping very low for this project.

My game will be a one-screen, top-down monster shooter set in a labyrinth; nothing fancy on the experience side.  However, I am using this as an opportunity to teach myself new things, in the spirit of the compo.  Specifically, I implemented a new AI pathfinding method I’ve never tried before, use cellular automata to generate my levels in a way I’ve never done before, and am going to try to practice my pixel art a little more.

The following screenshot is a debugging view of the pathfinding technique I mentioned.  It is essentially my own implementation of the technique described in this article, where it is called “diffusion-based pathfinding”.  The brighter the tiles, the nearer they are to my player character, as you can surely see; the data is updated constantly, in real-time.  Monsters will use this diffusion- or scent-based grid to navigate towards the player at all times.

Hope everyone’s having fun, and getting their proper rest!  I’ll be cross-posting to my personal blog as well.

Tags: MiniLD #45

So today I got most of the fundamental gameplay in place for my game.  There are now two enemy types who pursue the player, one which shoots at the player and the other which tries to swarm the player at close range.  The player also has three weapon types, though two of them are effectively identical at the moment.  There is also a rudimentary GUI that tracks player health, monsters killed, and weapon type current equipped.

Tomorrow I am going to focus on adding content and creating a progressively increasing difficulty curve.  I am not sure whether to add audio, but if I do, it will be fairly primitive.  I am actually having quite a bit of fun with this, which is probably helped by the fact that I chose a super low-scope game to build.  Hope everyone else is also enjoying their MiniLD!

As usual, I cross-post this to my personal blog.

Tags: MiniLD #45

So I just finished Monster’s Maze and uploaded it to the main thread!  This has been a very whirlwind experience, since I didn’t at all expect to participate in this MiniLD, especially not since it only lasted 3 days and I had other work to attend to.  And yet here I am, and I think I can say with confidence (I hope!) that Monster’s Maze turned out even better than my MiniLD #44 entry (Jumpstarter).

The development process was incredibly smooth, with only a few major blockages.  I think it helped a lot that I chose to make such a heavily restricted game world; that helped me focus my efforts on gameplay and balancing.  I’m happy with the end result; it may be a little too hard (I can’t even survive until unlocking all weapons!), but it’s frantic and hopefully fun.

I also learned a few things.  Diffusion-based pathfinding is amazing, really, and I will have to pay close attention to my future projects to see if they would benefit from an implementation; it’s such a useful technique, that alone was worth getting into this MiniLD for.  I also learned about using cellular automata to create mazes (and how to deal with the mazes if they aren’t completely navigable – interestingly, diffusion-based pathfinding really helps fix broken mazes!), some minor SFML details, some debugging techniques, and had my first real clash with the need to balance numbers in my game, both directly and algorithmically.

Great and rewarding fun, all in all, and I hope everyone else enjoyed their time too!

As usual, cross-posting to my personal blog!

Tags: MiniLD #45

The main game interface for Mama Is Sick

So the 28th Ludum Dare marks the first time I have participated in the mainline Ludum Dare event, though I was previously a participant in the Mini Ludum Dares 44 and 45.  Myself and a teammate, JaymeeMak, made a game called Mama Is Sick (submission page here) and submitted it yesterday afternoon after 72 hours of mostly work and a little sleep.

Mama Is Sick is a resource management game in which “You Only Get One” dollar a day with which you must try and feed yourself and your family, as well as pursue an education.  It was developed entirely in Unity, using Unity’s GUI functions; I was the programmer on the project, while Jaymee handled narrative design, art, and audio, and we shared the tasks of gameplay and interface design.

Successes

The development process was really fun; this is my fourth game jam this year, and the whole concept is really starting to grow on me.  By Friday night, a few hours after the theme was announced, we had a basic prototype of our game, and by Monday morning it was mostly bugfixes and polish that we had left to do.

Of the things we did well, I think scope and planning was definitely one of them.  Going with an entirely menu-driven game was a better choice than implementing some kind of game world behind the menu, as it helped us focus and flesh out our mechanics without getting distracted.  The mechanics we had were just enough to keep us busy for the better part of two days, but not enough to overwhelm us by the time the jam ended.

We also did well with working as a team with complementary skillsets.  The fact that each area of the game was being looked after by the person in a best position to perform those tasks really helped us keep things on schedule, and made sure it all worked out in the end; we also did a good job at effectively communicating what we were doing and what needed to be done, to make sure we were mostly synced up during development.

Finally, I think we did a good job at integrating the theme in our game; it’s not a strictly one-thing-forever scenario, but the whole concept of living off only a dollar a day has a strong presence in the public consciousness, and I think we ended up with a pretty interesting game for it.

Improvements

As for what we could improve, one of the things we concluded was that we needed a better introduction to the game mechanics; most of the difficulties players had with the game involved not knowing exactly how the mechanics or interface worked.  Instruction screens are nice, but ideally we would have had some kind of in-game tutorial, which we unfortunately didn’t have the time to implement.

Along a similar vein, I think we could have made an interface and game that felt more responsive to player actions.  We tried to make an audiovisually responsive interface, and succeeded to some extent, but there is definitely room for improvement on that front.  Buttons could change color when hovered or clicked on; the upgrade mechanic could have been clarified through more obvious feedback; etc.  We thought a lot about these things during the game and are confident that we’ve learned lessons that can be applied to future projects we work on.

Finally, from my programmer’s perspective, I didn’t do a very good job at making modular code.  As I was assembling everything very quickly, and needed to work within Unity’s still somewhat unfamiliar framework (me being used to the much more blank-slate approach afforded by raw C++), I could have spent a bit more time making more reusable and modular functions for different kinds of buttons, actions and resources.  This would have helped a lot on Monday, when I spent a lot of time fixing or debugging problems that stemmed from the game mostly being run through a few very large functions.  On future projects I will definitely keep that in mind.

Conclusion

This was a really fun and instructive experience, and however the ratings may fall, getting the game out the door and seeing people’s initial and mostly positive responses is a great feeling.  I hope to take the things I learned making Mama Is Sick into future projects, and I can’t wait for the next chance to take part in a game jam (Mini Ludum Dare #48, I am looking at you!).

I should also thank our two playtesters from before we submitted the game, as well as everyone who takes the time to play Mama Is Sick and provide feedback for us; as game design students and future developers, these jams are really important learning experiences for us.  And a big shout out to everyone who managed to get a game in there, big or small; 2065 games made over the weekend!  Wow, that’s really incredible.

Of course, though, my greatest thanks go to my teammate Jaymee, for bringing her great talent, spirit and work ethic to the game (as well as for keeping me away from the game’s art).  Alone, I could only have made something lesser than what we managed to create as a team.  Thank you!

So yes, I am participating in this month’s Mini Ludum Dare! And I’m quite excited, if I may say so.

My game, which I’m tentatively calling Space Prober, is a game about a space probe slingshotting itself between stars and planets. You are trying to explore as many planets as you can while keeping your battery levels up by slingshotting close to active stars.

It will be a fairly simple game, all things considered, and I am planning on porting it to Android if I have the time to do so. It will be built in Unity, so I should be able to publish it for browsers as well as Windows.

I will try to post a screenshot tonight, but I already have the core slingshotting mechanic working! Yay!

Good luck everyone!

Tags: #one-button, MiniLD49

This shows the space probe orbiting a star

I have successfully worked on my game, Space Prober, today! I’ve actually already got the core mechanic working, though it needs a lot of polish. The probe swings around through space and starts to orbit any planet it hits.

Tomorrow’s work will be implementing planets, asteroids, battery usage and recharging, and otherwise getting the core mechanics working. Sunday will be for polishing, tuning, and making the game look and sound nicer!

I’m already liking the swoopy feeling of slingshotting the probe around, and I can’t wait to get down to really making it feel right!

Get some rest, everyone, and enjoy the jam!

As usual, I’m cross-posting to my blog.

Tags: MiniLD 49

So during last month’s Mini Ludum Dare, I created a one-button game called Star Prober. It was a simple little game, but I rather liked it and so did several of the people I showed it to, so I decided to go all the way and figure out how to turn a tiny little game into a commercial release! You can now download Star Prober on the Google Play Store (I think? Conflicting reports from friends as to whether it’s actually available). It’s free, with a small handful of IAPs thrown in for kicks.

The gameplay itself is identical, though I touched up the graphics a bit and expanded on the interface. Most of the changes went into expanding on the GUI and fitting it to Android devices, and setting up an IAP system for a few small gameplay bonuses. I didn’t actually change the gameplay balance to accommodate the IAP scheme – the game is perfectly playable without them.  Instead, they basically just make the game easier, if that’s something you’re interested in.

I spent a lot of time struggling with the whole in-app purchasing thing. I used the OpenIAB plugin for Unity, which has a few issues – it’s hard to figure out when OpenIAB is ready to start performing billing and inventory operations, and the event-driven structure means that there are delays involved in getting feedback from it, so you need to use round-about ways to get information at the right time relative to the rest of your code. Since it’s fairly new, the documentation isn’t yet completely clear, though that’s something that the developers seem to be working to fix. Took me about a day and a half to get running properly, a more experienced developer will be able to figure it out sooner.

The game was tested on Nexus 4, 7 and 10 devices, and has screenshots uploaded for each of those screen sizes, but I still get the “Designed For Phones” tag, and I don’t know why, so that’s something I need to figure out. Sometimes there are also stuttering issues, which I still want to get to the bottom of, though they don’t appear to impact gameplay all that much.

Overall though, I’m happy that the game works and is out there. I decided to release it mostly as an experiment and as a learning exercise – how do you make Android games ready for release? How do you actually build an IAP scheme into a game? How do you Beta test and publish using the Google Play Store? I feel I’ve learned a good deal with regards to all these questions, and that’s really what I set out to do, so I’m happy with that.

I hope Star Prober brings you at least a few minutes of entertainment!  Once I’ve waited a bit to see if there are any outstanding issues for other users, it’s off to the next game. Maybe MiniLD #50? 😀

Tags: android game, Google Play, MiniLD49

So I haven’t done LD in a while, but I’m taking time this weekend to try and crank something out solo. I’ll be working in Unity, probably 2D but it depends on what the theme ends up being. Already trying to brainstorm ideas for all the theme finalists, since I won’t have a full uninterrupted weekend to do this.

Best of luck to all!

Hey folks! Now that the jam is over, I just wanted to look back a little on my game, Spore Valley.

Spore Valley is an engine-builder where you play as the newly germinated spore of an alien slime mold, and you must grow complex enough to complete your reproductive life-cycle within the limited space of a narrow river's edge, hemmed in by otherwise arid and barren desert. Different "bioforms" allow you to do different things, such as produce resources, construct other bioforms, cross water, and eventually win the game. Placement of bioforms depends in large part on what else is nearby, as well as what resources you've built up already.

This was my first game jam since doing the 7DRL in 2019, and my first Ludum Dare in even longer. I was motivated by a few things, partly the fact that I got this Monday off work, and partly because I've been considering switching my personal projects to Godot. I figured this would be a good chance to wrangle the new engine and see how I get along with it, and seeing the theme was "Limited Space" sealed the deal, since I very quickly thought of something entertaining to do with it.

The idea of an alien that sits vaguely somewhere in the triangle between a slime mold, a fungus, and a lycophyte is really just a reflection of the kinds of things I like spotting when I go outside in nature. The gameplay concept reflects my love of strategy games, which were what got me into gaming orginally (particularly 4X and RTS games). On top of that I've played some fun games that distill the 4X genre into simple, almost puzzle-like systems, and I've been playing some engine-builder board games lately too, so the concept of filling up a literally limited space with parts of your biological "engine" fell into place immediately.

The mechanics were simple enough to come up with, and I found myself "accidentally" having fun playing the game almost as soon as it was functional. I was delighted when I asked my partner to give it a try and they not only enjoyed the game but, unprompted, proceeded to play four whole rounds until they'd mastered the mechanics and won! The mechanics are familiar ones, so I was leaning on tried and true principles here, but I'm glad that worked out well.

The real meat of this challenge, for me, was figuring out how to use Godot. So far my one and only experience with the engine was running through the "Your First 2D Game" tutorial a couple of weeks ago, so this was my first time doing any self-directed work with the engine.

Happily, I found I really enjoyed my time with Godot. For reasons I'm not sure I can express yet, I found Godot's framework and flow for constructing a game GUI to be much smoother and more pleasant than my experiences with Unity. And I found the Node structure most objects in the game use to be pleasantly easy to slip into.

I did struggle at first to figure out how to align and distribute multiple objects in the UI in a way that felt coordinated, and repeated googling eventually dragged me through the Container paradigm and all its quirks; there are still things about it where I feel I don't understand what's going on or why the children of my containers behave the ways they do, but I made enough progress learning about the system this weekend that I feel the rest should eventually follow.

Godot's editor also, for the most part, feels less clunky and chuggy than Unity's. There are a few odd behaviours it has that may be either bugs or design choices I need to get used to, but for the most part it felt like the editor just got out of my way and let me do my job.

There are a couple of things I feel I didn't have the time to develop a sufficient understanding of. Tweens don't always do what I expect; I was unable to get map tiles to steadily flash when selected with Tweens (there was always a delay between tweens, even though I didn't define one), although I was able to use the same code to make it work with Buttons, so I switched to manually adjusting the color of the tile per frame instead. And I only barely touched the animation system enough to get my water tiles to animate a little; I would have liked to cross-fade between frames instead of instantly switching from frame to frame, but I can't tell if that's supported or if that's something I'd need to approach differently. I also would have liked to experiment with 2D bones, ironically to get the boneless slime structures wavering in the wind a bit, and I want to check out whatever Godot has for a particle system too.

Beyond that, I'm pretty proud of how I managed to make the system very data-driven. The tooltips, help page, graphics, and gameplay all draw from the same core set of data, so adding a new bioform (such as the Lysoplasm, which I added about 4 hours before submission) is incredibly easy and automatically propagates everywhere it needs to go with barely any work.

I'm also happy for the one piece of code I brought in from past projects; a class I call HexHelper. I love procedural generation and have been working in procgen for over a decade, and many years ago I decided to start playing around with map generation on hex grids. I loved it, and ended up writing a class of helper and math functions for dealing with hex grids.

I popped that over into Spore Valley to help with a couple of things... and immediately realized I had made a mistake! Because for years I've been working in flat-topped hex grids, so all my math was specific to flat-topped grids, but for some reason I'd decided to make Spore Valley a pointy-top hex grid. This resulted in some time spent rewriting my HexHelper class to account for both orientations, which felt silly to be doing so late and is probably going to be valuable in the future.

I'm reasonably happy with the art and I did learn some better Inkscape workflows as I made it, though I'm under no illusions as to its overall quality; I've already seen some art in other games in the jam that have blown me away! But this was primarily an engine-learning and gameplay-programming challenge for me, and in that respect I had a blast, and I consider the experience to be a great success.

If you happen to check out Spore Valley, thank you so much!