About sorceress (twitter: @_sorceress)
Ludum Dare 30
Ludum Dare 29
Ludum Dare 27
Ludum Dare 27 Warmup
Ludum Dare 26
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
Ludum Dare 21
Trying my own design skills for the LD website. Is this better or worse?
Because there could be quite a lot of images from this, the results have their own page:
It is a work in progress. I’ll add more charts to it as I make them. Enjoy!
ps: the survey form is still available here. I use the latest data for all charts.
“Connected worlds, indeed”
The shimmer effect is created by adding together 4 linear waves, each travelling in different directions, and with slightly different amplitudes. This makes it easy to loop over time, as the wavelengths of each can be chosen to line up.
This is pretty much how real water shimmer works, as wind generated waves run into walls/obstacles/shores, they get reflected in different directions. You can do this with any number of waves. With higher numbers (like 100+), the effects can be quite spectacular!
Yeyyyyyyy it’s Ludum Dare!
give us the tips already!
If you live in Europe, then the compo is split over 2 days. This is generally how I split my work between Saturday and Sunday:
- Day 1 – engine, controls, graphics, music.
- Day 2 – gameplay features, level design, sound effects, particles, screen shake and other effects.
I recommend this schedule to others. My reasoning? Day 2 can be stressful – or rather – you will feel the pressure of time. When you’re under pressure you will rush things, and the engine/controls/graphics/music can’t afford to be rushed!
What happens if you rush them, sorceress?
When you rush things, you don’t do them as well or as carefully. They are much more prone to errors. And if you are under pressure, then you won’t really have time to properly test/debug/fix them.
Engine – Say you rush your engine (that is the game loop and the core physics of your game). If it doesn’t work properly, then you could have a broken game. Nothing else will matter.
Controls – Imagine if the keys/mouse input doesn’t work properly. Imagine if a character can’t make jumps it is supposed to be able to make. Imagine if an inventory or in-game menu won’t open. Your game could be unplayable.
Graphics – Rush your graphics and spoil them and your game will look bad. Graphics create first impressions. Your screenshot is all that will entice players to click your game, and your game could well be judged after a mere 60 seconds of play. First impressions are everything!
Music – Rush your music and your game could sound bad. Painful sounds will put player’s in a bad mood, which could be the difference between “I like your game” and “I don’t like your game”. This will show in the ratings. If they decide to turn down the volume, they won’t hear your sound effects either.
This month’s miniLD was due to be hosted by sfernald.
Problem is, he isn’t around! He hasn’t been active on this site since last year, and he has not (yet) replied to our two attempts to contact him.
So… what shall we do with the miniLD?
There are only 10 days left in this month, so if we are going to do something it will have to be this coming weekend (24th-25th May).
- Option 1. We could wait, and hope that sfernald comes.
- Option 2. We could all put our heads together and come up with a theme and rules between us.
- Option 3. Back in 2008 our admin PoV hosted one of the first miniLDs, and chose the ‘Tool Jam’, where instead of games, the objective was to make game dev utilities, that might be useful in future game jams. I think it would be nice to repeat this at some point, since we have a much larger user-base now.
- Option 4. We could offer the miniLD to the person booked for June/July. This tends to be messy as it doesn’t fill the gap, it just moves the gap. People might also have their heart set on certain months to align with some events and don’t particularly want to move, etc.
- Option 5. We could give the miniLD to someone else, which may or may not annoy those who have been waiting up to 2 years in the queue.
Post your thoughts/ideas below, and remember we have to come up with something before the weekend!
edit: A majority has spoken! We’re doing the Tool Jam.
Day Two Summary
Day 2: Morning
Taking stock of things the next morning: what I’d made so far didn’t do much of anything. I had about 18 hours left to change that. Day two of LD is when you feel the pressure, and where you realise you need to cut corners!
Day two began by writing the combat system, and making sure I kept it super simple: Projectiles, Attack Cooldown, Hitpoints, Damage, Death. Units could now attack, and follow their attack orders. This felt like a monumental bit of progress!
I decided against drawing projectiles. Having to make those projectile sprites, and render them, including rotating the rangers’ arrows to fly in the right direction — it just felt like it would be unnecessary work, when projectiles could be represented by particles instead. I was planning to add a particle system anyway, to represent units’ bloody deaths, smoke from the cannons, and the sorceress’ fireballs. All projectiles could be done with the particle system to keep things simpler. But that was a task for later in the day…
Day 2: Afternoon
Before doing particles I wanted to get something more urgent out of the way: to make the buildings functional. I needed to be being able to purchase units and upgrades.
Normally in RTS games, it takes time to “train” units. But if I did it this way, it would have meant attaching timers to buildings; keeping track of cost and food usage during training; being able to cancel training and recoup costs; having a progress bar in the HUD; and what happens if a building is destroyed while something is being trained? and how will units in the process of being trained be seen by the CPU AI? etc etc… Too much to implement! So to simplify things I decided that all purchases would be instant. Another corner cut.
The particle system came after this, adding blood and smoke and fire effects. Then adding sound effects to the combat.
Throughout the day I had been expanding the stats of the different character classes too. Giving them each unique values for hitpoints, damage, attack cooldown, movement speed, etc.
Day 2: Evening
Writing the CPU AI was a big task that both excited me and terrified me! For if I failed at this, then the game would not be a challenge. Having thought about RTS AIs previously, I had a fair idea how I was going to do this. I felt that my AI should have three subroutines:
- Subroutine to control workers. This was the easiest: if a worker is idle, then find some unharvested terrain near to home, and order the worker to harvest from that point.
- Subroutine to buy stuff. This begins by counting up what units we have, and following up with a bunch of if(…) statements to decide what we should buy next. If we can afford it then buy it. If not, then buy nothing.
- Subroutine to control fighting units. This was super simple, and not very clever: If we have more fighting units than the enemy then Attack-move them towards a random enemy building; otherwise Attack-move towards home.
I was actually surprised how quick the AI was to code, and how effective it was! The computer played me at my own game, and it won!
Day 2: Night
As it came into the last few hours, my game was coming together nicely. It had a lot of rough corners, a few bits that didn’t work right, and there were features that I knew I wouldn’t have time to add, but the basic game was there, and it had an AI that beat me once!
I knew there was no time left to add any more big features. No time to add base construction, sadly. I spent much of the remaining time making the game presentable, and fixing some annoying bugs:
- There were random units that wouldn’t die. — Wrong limits in clean-up function.
- There were idle units that suddenly decided to go for a walk to the top of the screen — An Auto-attack sometimes failed to expire, despite the targeted unit having died.
- Getting command buttons when selecting enemy units — Required an ownership check.
- The command buttons sometimes going wrong if a selected unit died — Need to rebuild the command buttons when a selected unit dies.
- Other stuff like this
I did have time to add a handful of small things however, including:
- HP bars, toggled with the caps-lock key.
- Casting orders for the sorceress and cleric, although only two of the six spells were added.
- Began adding keyboard shortcuts for orders, although only time to do the main attack/move orders.
- Made a little title screen using the (otherwise unused) harvesting animation for the worker pigs.
- Tweaked the costs+stats of the character classes, to make the game better balanced, and rearranged the buildings more logically.
And that was my Ludum Dare 29 weekend!
Day One Summary
Day 1: Morning
I woke at about 8am. I powered up my computer, got breakfast, and mulled over the theme while chatting on IRC.
I decided pretty quickly that I would make an overhead 2D game that involved strip mining the land. I had no real idea what the game would become at that time. My first task was to draw some terrain textures, and get code in place to render a terrain.
I realised straight away that to make the terrain look nice, there would have to be nice transitions between the different terrain types. And I really needed a minimum of 4 types: grass, dirt, water, and land that had been stripped.
Blending between two tile types is easy, as the transition can be part of the texture proper. But with 3+ tile types, the sheer quantity of transition tiles becomes unrealistic to draw. After some discussion about this on IRC, I decided to do layered textures (which was the solution I was leaning towards anyway).
This means that many kinds of terrain can be drawn with transparency, stacked on top of each other. I wanted to get this up and running with a scrolling camera by noon. Which I did much to my delight with literally 5 minutes to spare.
Day 1: Afternoon
Throughout the morning, I had developed a couple of different ideas for what this strip mining would be about: It could be people digging for gold and gems, birds digging for worms, or pigs foraging for truffles — either way it would be generating an income for buying stuff.
With my fondness of the strategy genre, this harvesting mechanic reminded me of Warcraft II. The idea of using income to buy fighting units to stop enemy harvesters appealed to me. So that was my goal.
I’d attempted to make an RTS once before for LD24, but that didn’t go to plan. The difficulty with it was:
– It was 3D, which needs more work for pretty much everything.
– Path-finding took too long to set up.
– Combat system was over-complicated.
My game this time was 2D. I needed to ensure I had simple path-finding and simple combat system.
So it was now time to start making some characters to populate this land. My first attempt at drawing birds was not very successful, and I feared that pigs would all look alike. So I settled on human characters with pig workers.
The basic character sprite was drawn and animated, and then copy-pasted, modified and recoloured into six other characters. All together that drawing took me about 3 hours.
The next couple of hours before dinner were spent adding units into the game, and perfecting their collision detection/reaction.
Day 1: Evening
As day one passed the half way point, my next step was to add unit group selection. And since orders can be targeted at both units or areas, I needed to be able to differentiate between clicking points on the terrain and clicking on units. I tested this initially by having units follow other units if I right-clicked on them, or simply to move to the clicked point if I right-clicked terrain.
I spent all of the evening fleshing out this order handling system, as it was the core of the game engine. This included writing an auto-attack subroutine, whereby units could assign themselves an attack order if there are hostiles nearby.
Day 1: Night
By about 10pm, I realised I needed a HUD! No good me having this fancy order handling system if I couldn’t select which order to assign!
The button images were drawn at this time, mostly by copy-pasting bits from my sprite sheet. Plus I wrote a few lines of code to detect the mouse hover/click events over the buttons. The HUD wasn’t functional at this time.
At around midnight, I started writing my game music. This took me about 2-3 hours more I think. I’m not sure when I fell asleep.
About 5 hours in I think. I’ve decided to make something 2D and pixelly this time.
☑ GL environment set up
☑ Terrain tiles made
☑ Texture layering done
☑ Trees drawn, and tree layer added