Two weeks ago, Ludosity participated in the four-day Games Against Ebola game jam. Daniel and Anton made Princess Remedy In a World of Hurt, with music by Mattias and Stefan, and Simon and Nils made Fist of Healing with more music by Mattias.
Today we’re releasing Princess Remedy for free, while talking a bit about how it was made. Get the game here:
Download Princess Remedy for Windows
Daniel on the game design
In Princess Remedy, you travel around the world to heal people with various ailments. The “Healing Mode” is a single-screen action sequence where you shoot band-aids and throw a limited amount of flasks at enemies like viruses and ghosts. Most of the ideas came from looking at Anton’s various concepts made before the game jam, which were expanded upon on our whiteboard on the first day of the jam.
Since we had four days, I figured it should be possible to make a fairly small RPG world with plenty of characters to heal, and several different enemies. After coding the overworld and basic battle screens, I received 64 NPC sprites and 16 enemy sprites from Anton, and two sets of tiles for the overworld and towns. With only two days left, I made the overworld areas, 49 regular battles, spent about four hours on the final boss, wrote the dialogue (hence why it’s so simple and rushed), and in the final hour of the jam added a save system. Since me and Simon decided to skip sleep on Saturday, I worked for about 32 hours straight, and managed to finish the game without having to cut any content from the plans. We also got a set of sweet final boss tunes from Stefan near the end.
Anton on graphics
Graphics for a jam game should be quick and fun to work with. I decided on a very low resolution look with very few colors on heavy black backgrounds. To spice it up I decided I should only use 1 color per 8×8 pixel block on a sprite or a tile, and I had Daniel code the sprites “erasing” tiles below them (it looks cool! Oldey!). This isn’t to emulate a specific console (although that is fun, I wasn’t up for that kind of dedication in a jam timeframe) but merely because limitations like these are fun to work with and forces one to be creative and try new things. And trying new things is a key to improvement, I feel.
This simple style, combined with very clear instructions on exactly what graphics we needed and how they should be set up, allowed me to churn out all the graphics in 2 days. Which was necessary since I would be away on the weekend.
The biggest thing I had to make was the final boss. For his concept design, both me and Daniel drew simultaneously on the whiteboard, just doodling whatever we could think of. Then I simply polished that design and translated it to pixels (still adhering to the 1 color per 8×8 area was the thoughest part!).
Haku on music
While the graphics are technically emulating something older than the NES I didn’t want to go that far back with the music. Thus the music is made by samples from the NES and the Gameboy, but disregarding any limitations those console would have. I played around with the noise sounds and with using moody arpeggios, also, I’ve been very much into jazz since the Card City Nights OST, so a jazz track naturally made it in there. All in all, I’m very proud of the soundtrack.
Hello there, scores of rabid Ittle fans swarming our offices and staring through the windows. Daniel here to say something vague about Ittle Dew 2 again!
What’s going on?
At the moment, only me (designer) and Anton (artist) are working on the game at all, mostly planning and making the graphical content. Stefan (programmer) becomes available for some small coding work now and then, but most of the time we have to make do with the functionality we have. Therefore, progress is pretty slow.
What’s done so far?
The game’s design has been mostly laid out down to the finer details, but a lot might change as development progresses. As far as actual development goes – as opposed to me just drawing dungeons and puzzles – we have a player running around various work-in-progress areas and smacking enemies, an enemy scripting system and level editor by Stefan, and some neat room transitions.
What’s the plan?
As the rest of the team are tied up with other projects for a few months more, the game will continue stumbling along, maybe picking up a few lines of code here and there. We don’t even have a deadline on deciding a deadline yet, but hey – here’s a Fishbun with legs.
Hello there! We recently made a couple of games for Retrospelsmässan, a retro game fair in Gothenburg. These are actual ROMs that run in emulators and on the real hardware.
Mattias and Anton made Tiger Jenny, a NES/Famicom game based on characters from the credits sequence in Ittle Dew. You can get the ROM here, and the source code here!
(To play this game, you’ll need a NES/Famicom emulator like FCEUX, or a cart like Everdrive N8.)
Mattias made Questforge, an Atari 2600 game. Get the ROM here, and source code here!
(To play this game, you’ll need an Atari 2600 emulator like Stella, or a cart like Harmony.)
Daniel made J.Ö.R.G.E.N., an Atari 2600 game. Get the ROM, source code and included Stella emulator here!
Anton made Atarena, an Atari 2600 game. Get the ROM here!
For more information on how these were made, this guide is what Mattias used when making Tiger Jenny. We also used Batari Basic when making the Atari games.
There were more games shown at the fair, but the makers don’t consider them complete enough to release yet. We hope you like the games!
It’s the last part of the Muri dev blog! Oh my!
The plot and setting were inspired mostly by Doom and Sin & Punishment, though it’s not as over-the-top as the latter. Since each person the player meets only gets a few minutes of screentime, it’s hard to establish them as characters, and as a side-effect they all get portrayed in a pretty negative light… on the other hand, the story is about strife anyway, so it might just fit.
I wanted it to be possible to take the story as both serious and/or cheesy, depending on what you want to get out of it. One tester managed to be immersed at least, but I think it’s a mindset you need to have when going into any media with a dramatic setting. Heck, I liked the bizarre and creepy story in Doom, eventhough most people I’ve talked to didn’t even know it had one, and Doom is hardly a game I take seriously.
I didn’t want reading the story to be mandatory, so you can skip the cutscenes and still enjoy the game. Of course, the reason you’re fighting the weirder bosses won’t be clear, but if you’re not interested in the story it shouldn’t matter anyway.
While I made Iji previously, which has a lot of modifiers depending on what the player does, Muri only has one alternate way out of a specific bossfight which doesn’t change the episodes that come after it. It wouldn’t really fit this kind of game to be more complex than that, I think.
One of the biggest challenges in level design was the fact that the player can only see a short distance vertically, so platforms, spikes and enemies had to be placed carefully. Though the player can safely bounce on enemies’ heads, making it more fair when falling into unknown places from above, I just avoided putting enemies in unknown areas below the player in the first place.
The small screen size also made it hard to let the player know what a boss on the other side of a big room is doing. One enemy that is part of a boss encounter was designed to rush the player from a distance, but since this was hard to anticipate when the enemy was off-screen, I lowered its speed by a lot. The boss was hard enough as it was, anyway.
Teaching the player
Although the game only needs a few buttons to play, I have to tell the player the controls somehow when they’re playing with a keyboard. I didn’t want to show the controls on-screen like more modern games, instead prompting them to “PRESS F1 FOR HELP” which explains the controls, and if you flip the pages, the most basic parts of the rest of the game.
The testers never looked up the help screen aside from curiosity, as they immediately found at least one set of the buttons that perform the game’s only two actions (jumping and shooting): Control and Alt, Z and X, Numpad Ins and Numpad Del, and a few more. Y is also mapped to Z due to these being swapped on German keyboards. I decided against the user remapping the Z/X keys, since it wasn’t necessary given that Control and Alt are in the same place regardless of your keyboard layout, and rarely “block” the arrow keys when used in conjunction like other keys do.
In the first level, the player is dropped into a small room with a barrier guarding the exit. A nearby generator (obvious reference to Hero Core) needs to be shot while ducking, lowering the barrier. The player must then keep the jump button held to jump higher and reach the ledge above, and with this they have discovered the basics of the game by themselves. Jumping on enemies is usually discovered in stage two, where enemies are clinging to a wall at the bottom of a thin vertical shaft. The player inevitably bounces on the enemies on the way down.
The game could’ve clearly communicated everything about how to play it through text and icons, but this being a DOS-like game, I didn’t want to overdo it. I prefer when games don’t underestimate the player or waste their time, too (though I’ve made some long-winded tutorials in the past).
Well, that’s it for the Muri dev blog. I hope you’ll like the game! 🙂
It’s Muri time!
Many DOS games let you choose between PC speaker sound or MIDI and digital samples, which required a sound card. When dad got a Sound Blaster 16 we had to manually input the IRQ and DMA in setup programs for each game, though later games like Tyrian could autodetect the sound card.
Anyway, the PC speaker can only generate one fairly simple wave at a time, with no way to adjust the volume. For Muri I used a synth emulating the PC speaker, set up by Mattias, to generate these sounds. The game uses a priority system to make sure that only one sound is played at a time. A higher priority sound will overwrite a lower one, which works surprisingly well in practice!
Mattias also wrote two PC speaker songs for the game, but only one was used. The other was going to play in a cutscene, but was considered too distracting.
There’s at least one new enemy or boss in each of Muri’s 20 stages, ranging from small robots that don’t even notice you to jumping, ducking and dodging humanoids with rapid-fire rifles. Most robots come in four different colors with slightly different abilities, and each episode has a unique enemy that usually guards or carries something important.
Though most enemies are limited to simply running into you or firing slow-moving bullets in one of 8 directions, I hope I’ve managed to add enough variety to them. I noticed during testing that since you can jump on enemies from above to damage them, some testers tried to do this all the time, even if it meant crashing into them and dying more often than usual. :p
Pickups and weapons
Aside from the regular point bonuses, there are several energy pickups and one extra life more or less hidden in each stage. Both the energy and extra lives are replaced by point bonuses on higher difficulties.
Since all the enemies and bosses are defeated by simply shooting at them, the game could become too hard or too easy depending on your current weapons. To alleviate this, there’s a rare kind of pickup that gives you infinite ammo for a weapon, usually before a boss where I wouldn’t want the player to get stuck with just the regular gun. I also tried to make the weapons different enough from one another that they all had their uses, though as you’d expect they are more powerful the rarer they are.
The weapons got the DOS-y names RAPID, MKV, LASER, MEGA and CHAOS, with distinct sounds for each one. MKV stands for Mark Five, but this isn’t explained by the game. Letting the player guess at the meanings of weird acronyms is part of what I liked about old games. But now I’ve ruined it for you. Oh well.
Next up is story, vertical problems and teaching the player!
It’s time for another Muri post!
The game emulates the 320*200 EGA graphics mode that uses the 16 CGA colors for its palette. I’ve actually only played a few games that ran in this, like Duke Nukem, which used the optional brown color instead of gold.
There’s a lot you can do with these 16 colors, but I didn’t want to use dithering or more advanced pixelart, since it would look more like an Amiga game in style. I was rather inspired by the simplistic look of games like Electro Man, plus I’m not that good of an artist.
You might remember the bright-red and yellow character portraits in Duke Nukem – it’s hard to get a proper skin tone, especially a darker one, with these colors without heavy dithering. The only time you see Adwoa without the helmet is when red sunlight is reflected in her face, providing some context for the high contrast. Thanks to Scott Robertson for help with this!
The only other time people’s faces are seen is in a greyscale portrait, which probably looks better than if I’d tried to do it in the 16-color palette. Speaking of these limitations, the colors used for the Muri suit were chosen to stand out from the background and enemies, and each suit has a different colored visor.
Late in development, I realized that the game – which normally runs in 16 frames per second – may be too archaic (and a bit nauseating) for most people. The low framerate also makes it harder to turn around quickly or react to enemy bullets. After a bit of testing with doubling the framerate and rewriting the code for the player character, I decided to implement a 32 FPS “smooth mode”.
The smooth mode required programming special cases or timing changes for all the logic in the game, which was pretty tedious. I think it was the right decision in the end though, making the game more visually appealing to players who don’t want their retro games that retro. Essentially, it just makes everything move twice as smoothly.
The game asks you to select the “authentic” or “smooth” mode on first startup, but can be easily changed in the options afterwards. It was the only option I considered important enough to ask the player about, since many players never go into the options menu.
The next post will be about sound, enemies and pickups!
Hi there! This is the first of a series of blog posts about Muri’s development.
I started work on Muri in May, with the goal of making a simple DOS-like platform shooter inspired by Duke Nukem and Commander Keen. Unlike my freeware games, this one was made specifically for Ludosity.
Jumping, ducking and shooting is pretty much all you do in this game, with the strongest weapon being used automatically as long as you have ammunition for it. I had a button for changing weapons during development, but testers either forgot you could switch weapons after a while, or stuck with the basic gun to save on ammo and wound up never using their best ones. Being forced to use your currently best weapon improved the pace of the game quite a bit.
There are four episodes selectable from the start, with increasingly tougher enemies and stages. Now that I think about it, I miss being able to select episode (or the equivalent) in most modern games. It’s a good way to separate Muri into distinct and manageable pieces, since nothing is carried over between episodes.
There are some things the player needs to figure out for themselves, like what the “CELLs” do and where to find them, but I think that’s part of the fun. A player often appreciates having figured something out more than being told about it.
There are four selectable difficulties, with the easiest giving you a lot more health and ammo. The harder ones remove health pickups and extra lives, but the enemies remain the same.
I wondered throughout the whole development whether the game should have continues, or even infinite continues, rather than having to start the episode over when you run out of extra lives. But since the episodes are rather short, and it didn’t really fit the arcade-style nature of the game, I decided not to include them. Instead I added secret ways to get through the episodes faster at the cost of a potentially higher score.
The highest difficulty is pretty tough, since you’re allowed fewer mistakes. The first episode isn’t too challenging even on this difficulty though.
That’s it for the introduction – next time I’ll talk about the graphics, EGA limitations and “smooth mode”!
So what do we do here at Ludosity? What kind of skills would you need for this kind of prestigous, minimum wage job? Let’s find out!
Gustav, Mattias, Dan and Stefan are the coders, creating everything from gameplay features to file converters, and working out low-level memory managment. Let’s take a closer look at these people’s brains.
Daniel: Please describe in one sentence what’s it like developing for the 3DS.
Gustav: Interesting but challenging.
Stefan: It’s cool.
Dan: Death tractor.
Mattias: Is it my turn to have the devkit yet?
Daniel: Explain with a metaphor what working at Ludosity is like.
Everyone: (Long silence)
Daniel: What’s the weirdest thing about one of the games we’re making?
Gustav: The source code contains dialogues between us, and a reference to Office Space – not just a random comment, but a part describing the code.
Joel is part boss, project lead, economic department and public relations… a lot of executive things. He’d like to be more involved with the games though. Sometimes mysteriously disappears, and returns with either a publishing deal or bags of fruit.
Daniel: On a scale of having tea to wrestling giraffes, how difficult was it to start up a game company?
Joel: Really easy. I didn’t do it myself, it was first started by Arcade and Jesper, and then the team has gradually changed, so it rather fell into my lap. It still doesn’t feel like a “real” company due to our low wages, help from the business incubator and loans. So it’s basically as easy as brewing coffee.
Daniel: What have you done today?
Joel: Gone to a meeting with a bank, bought snacks, worked on legal documents for our new LLC and put a game up on the website.
Daniel: What’s the weirdest thing about one of the games we’re making?
Joel: That Ittle Dew’s normal-sized breasts make people mistake her for a guy.
Anton is the artist and produces 2D and 3D graphics and animations, using Photoshop, Maya, and currently Nintendo’s development tools. All day, every day.
Daniel: What does an average workday look like?
Anton: I sit here and make a lot of art. That’s all I do.
Daniel: How many of our game characters are completely sane?
Anton: Hmmm… none?
Daniel: What’s the weirdest thing about one of the games we’re making?
Anton: Our level editors contain minigames.
Fredrik is in charge of QA (Quality Assurance), and is incidentally also the entire QA staff. The 3DS’s 3D feature gives him motion sickness in ten seconds flat, and he’s currently going through 100 levels and writing down which ones crash, rebooting the console in between each one. Let’s make his life even worse for a bit.
Daniel: Please describe in one sentence how stable our games are right now.
Fredrik: Haha… “Not.”
Daniel: How fun is your job?
Fredrik: Better than any other job I’ve had. QA is fun if you turn it into a challenge to find as many serious bugs as possible.
Daniel: What’s the weirdest thing about one of the games we’re making?
Fredrik: That the armadillo is impossible to kill. He’s gigantic and there is no escape. If you try to jump, he just follows behind you. He covers the entire screen. It’s impossible.
I (Daniel) am a designer, but it’s a fuzzy word – since I started working at Ludosity I’ve been coding some flash games and level editors (hence the inclusion of minigames in our editors, ed. note) for our games, but mostly doing levels, design documents, prototypes, gameplay ideas, particle effects, gameplay tweaking, menues and menu animation, 2D animation tweening, trailer recording, 2D graphics, some project lead duties and sound editing. And the weirdest thing is how doodles on the whiteboard turn into features and characters in Ittle Dew.
Remar here, ready to tell you about the joys of Nintendo 3DS development! Today Gustav found that the largest factor in our loading times was the loading screen itself, and our new QA guy has recovered from motion sickness after playing our game. Apparently a medical history of motion sickness and stereoscopic 3D don’t mix…
In the graphical department, Anton and I discussed the best way to set a rotating chainsaw on fire. We can’t have clusters of them flying through the air with the fire coming out the wrong end – that would just be embarrasing. For some reason there’s also been an increase of frogs in our concept art and games lately.
During lunchtime and after work, Anton, Mattias and I play assorted fighting games and argue over the superiority of MK9, SSBM, GG:AC, and MvC3, not to mention arcade sticks vs gamepads. It’s the nerdiest time of day, and I think the more “serious” companies in the corridor wonder if we ever work at all. Every time they walk by our room, I happen to be staring at the screen or stretching my arms (such as right now), which probably doesn’t help.
Anyway, developing for the 3DS means a fine balance between interesting use of graphics and plain gimmicks, and in some cases opinions differ. We don’t really “think in 3D” considering that both of our games are 2D, gameplay-wise, so we rather use it as an extra feature. Same with the stylus, it’s just another way to navigate the menues. I may be oldschool, but I think buttons often work best.
Why did we include an Xperia Play in a 3DS post?
That’s it for my introduction – next time I’d like to go more in-depth with one of our games. “Designer” is a fuzzy job title, so I might also just talk about what I do here at Ludosity, and what you can expect if you want to work at a small game studio.
As some of you might know, Ludosity Interactive has teamed up with Daniel Remar of Iji and Hero Core fame, to bring Garden Gnome Carnage to new platforms, starting with Flash.
Me and Daniel go back since we first met at uni 4-5 years ago, and we have worked on several games together. We entered Yoyo-Games winter competition with Garden Gnome Carnage and won 2’nd place! (Beaten by Frozzd by Jesse, who I later made Shoot Stop Lollipop with)
Now we have brought Daniel into our offices to build GGC for flash and it’s already progressed really well! Hopefully we’ll have some vids for you up soon. It’s super fun to work on these fun, small titles, and we hope that it’ll hit the interwebs very soon and blow your minds =)