Ludum Dare 31
Theme:
Entire Game on One Screen

Judging ends in:
It’s time to Play and Rate Games!

PlayRate80Star

About sorceress (twitter: @_sorceress)

Software Developer

Entries

 
Ludum Dare 31
 
Ludum Dare 30
 
Ludum Dare 29
 
Ludum Dare 27
 
Ludum Dare 27 Warmup
 
Ludum Dare 26
 
MiniLD 40
 
MiniLD #37
 
Ludum Dare 24
 
MiniLD #34
 
Ludum Dare 23
 
MiniLD 32
 
MiniLD 31
 
Ludum Dare 22
 
MiniLD #30
 
MiniLD #29
 
Ludum Dare 21

sorceress's Trophies

Too many entries award
Awarded by Sogomn
on September 8, 2014
Interesting Idea Poster Award
Awarded by MadGnomeGamer
on March 1, 2012
Constructive Response
Awarded by galman
on November 7, 2011

sorceress's Archive

Sorceress is IN (free tips inside!)

Posted by (twitter: @_sorceress)
Friday, December 5th, 2014 5:20 am

It’s Ludum Dare ☃ Time!

Tips

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, menu, particles and other visual 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!

If you do rush these things, you don’t do them as well or as carefully. So they will be more prone to errors, and 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. Or if the speed/feel of character movement is just wrong/bad. 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 – Leave it until day 2 and it’s the sort of thing you’ll keep putting off until it’s too late! And if you rush your music then 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”. Don’t make them want to turn down the volume.

Day 2 – If you’re finding things too stressful, then try not to worry. Don’t worry about making a big game with many levels and a zillion different items. Short games are often preferred anyway! Everybody cuts corners on day 2, so let it happen. And always have fun, and let that fun show in your work.

Good Luck. See you on the other side :P

Yet Another Wallpaper

Posted by (twitter: @_sorceress)
Sunday, November 30th, 2014 8:59 am

x31-1920

Wallpaper

Posted by (twitter: @_sorceress)
Thursday, November 27th, 2014 6:32 am

Woodum Dare

Posted by (twitter: @_sorceress)
Friday, November 21st, 2014 5:15 pm

More website design experiments. Better or worse?

Image2

  click to embiggen

New Design

Posted by (twitter: @_sorceress)
Tuesday, November 18th, 2014 6:26 am

Trying my own design skills for the LD website. Is this better or worse?

ldconcept

example of all tab colours

Ludum Dare Survey: Results

Posted by (twitter: @_sorceress)
Tuesday, September 2nd, 2014 2:06 pm

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.

sorceress’s game – update 1

Posted by (twitter: @_sorceress)
Saturday, August 23rd, 2014 6:09 am

“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!

Sorceress is in, and brings tips!

Posted by (twitter: @_sorceress)
Friday, August 22nd, 2014 3:38 am

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.

what shall we do with MiniLD 51?

Posted by (twitter: @_sorceress)
Wednesday, May 21st, 2014 12:49 pm

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.

Warpigs Postmortem – Part 2

Posted by (twitter: @_sorceress)
Wednesday, May 7th, 2014 8:55 am

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…

day2-01

 

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.

day2-02

 

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! :o

day2-03

 

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!

day2-04

 

Link to Game

 Link to postmortem part 1

Warpigs Postmortem – Part 1

Posted by (twitter: @_sorceress)
Tuesday, May 6th, 2014 5:31 pm

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.

day1-01

 

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.

day1-02

 

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.

day1-03

 

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.

day1-04

 

http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=5745

 

Sorceress’ Game!

Posted by (twitter: @_sorceress)
Saturday, April 26th, 2014 5:55 am

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

LD29_SS01

A Lake!

[cache: storing page]