August 3rd, 2018 by Daniel Remar
Hi, I’m the animator and co-designer of Slap City, and today I want to talk about the ideas and philosophies that go into making the game.
Slap City is mainly designed to be fun and silly, but it should preferably also hold up when played competitively, even if not to the degree that serious competitive-only games do. Like most of our games, we’re only six people developing it, so we stick to this whimsical and self-indulgent approach to the art style and characters and hope that others will like them as well.
The heart of Slap City is the fluid character movement. Any ground move can be performed while standing, walking, running or turning, and instead of the “L cancelling” from the first two Smash Bros. games, we have Dash cancelling which gives your character a burst of directional speed if you press the Block button while landing. Meanwhile the Clutch button can instantly reverse the facing and momentum of certain moves, as well as doing a bunch of other things that help the player perform most “analog” inputs with a digital controller or a keyboard. Like the individual tricks that each character has, the idea is that the more options the player has, the more exciting it can get, but they shouldn’t need to use all of them (and newcomers should be able to have fun without discovering them).
Our main focus is to make new content for the game, and we’re currently working on the new single-player Story mode where you’ll learn more about the characters and their silly adventures. But we also look at tournaments and discussions and try to tweak the balance of the characters when we have the time. Here are my personal guidelines:
-Buff weak or underused moves so they become useful.
-Chaingrabs and moves that combo easily and infinitely into themselves are no fun. These are “nerfed to make the game buffer”, as project lead Elias puts it. If there’s an infinite somewhere, we just missed it.
-After the patch that nerfed Ultra Fishbunjin in ten different ways at once (I’m sorry!), and that time I messed up Jenny Fox’s axes and skateboard (I’m sorry!) I try to only nerf one move per character per patch at most, while buffs are free. Sometimes we may still feel the need to change multiple things at once, but if the change isn’t well received, we try to come up with something better.
Our design process for each character is to draw all the moves on a whiteboard until we get tired, and then keep going anyway, at which point you get things like Fishbunjin’s “trust fall” triple Down strong, and the Goddess of Explosions breathing fire or punching bouncing projectiles around. It wouldn’t be Ludosity if the game wasn’t ridiculous.
We have plans to turn the Free-For-All mode into something where points are scored by doing all sorts of things besides KO’s, including some form of items or modifiers you can earn mid-match. So please stay tuned for that.
When it comes to the “Library”, previously known as the “Gallery”, there’s a lot we’d like to put there in the future. The player is meant to unlock additional pages by finding secrets in the upcoming Story mode – some with silly lore about the world and its characters, and some with information on hidden moves and other tricks. I also want to hold off on updating the little video tutorials until the characters have stabilized more.
Oh yeah, the stages! We try to have a mix of wild and competitive stages, and since the standard Slapball stage is very basic, future Slapball stages may get even crazier than Soccer field and Golf. It’s no fun if KO’s or Slapball goals depend too much on stage hazards, of course, but variety is always nice. And if you haven’t tried it yet, there’s a different Smack the Crystals stage for each difficulty level which can be independently selected in the single player menu.
Please continue to enjoy Slap City! 🙂
December 12th, 2014 by Daniel Remar
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.
August 29th, 2014 by Daniel Remar
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.
June 7th, 2014 by Daniel Remar
Hello, diehard Ludosity fans who spend most of your time walking about our offices asking for autographs. In this post I’ll explain the game’s direction and overall design. If you’ve played the original Ittle Dew, you may or may not be glad to hear that things will be a bit different this time around.
Ittle Dew 1: so many puzzles
The original game was centered on The Castle, and the three items you could purchase from Itan Carver in any order. To beat the game, you needed two of the three items, but most players obtained all three before facing the final boss. The overworld was more of an afterthought – to be honest, the entire game besides The Castle was an afterthought, being designed during the game’s production.
The focus on puzzles meant that designing the dungeons, in particular The Castle, took a really long time. Players could also get stuck on puzzles that were required for progress, and it wasn’t always obvious whether you could solve a particular puzzle with your current items or not – some players thought that getting the items in certain orders was impossible, since the shortcuts could be rather sneaky.
The combat was also not the focus of the game, with simple enemies and virtually no penalty for death.
Ittle Dew 2: opening it up
Ittle 2 takes place on an overworld divided into eight progressively harder areas, each of which holds a dungeon. The dungeons can be tackled in whatever order you find them, except for the final one. In case the player doesn’t want to explore the world themselves, completing a dungeon will reveal the location of the next recommended one on the overworld map.
The warp garden is a place located in the center of the overworld. Finding a warp on the overworld will link it to the warp garden, so backtracking is never much of an issue. Warps are located near dungeons and other important places.
There are four “active items”, mapped to four different buttons, so there’s no need to switch out your gear. The remaining equipment is passive, and can be inspected on the pause screen. Finding another copy of an item you already have will instead upgrade it, making it more powerful or granting it new abilities. Everything Ittle finds is immediately useful for either combat, exploration, or both. Additional copies of the items you’ll find in the dungeons can be also found in secret locations on the overworld, and some shortcuts in the dungeons require items from later dungeons.
Speaking of, Ittle 2 has a bigger focus on exploration and combat. The puzzles are still a big part of the game, and will still get pretty tough, but they won’t be in each and every room anymore.
Making the player feel fairly treated
Every secret on the overworld can be found using only the starting Stick, so you won’t be wandering past obvious metaphorical keyholes, having to remember their locations while looking for the metaphorical key. That’s not to say that finding the secrets will be easy – discovering how the world works is part of the game.
If the enemies beat you up, you’ll keep all your progress but wake up at the entrance to the current dungeon, or the latest warp you went through. You’ll be opening up shortcuts and mini-warps in the process though, and dungeons are designed to avoid dead-ends. Once you enter a dungeon, you can solve it with everything you already have or what is found inside.
There’s also a pause menu option to instantly return you to the start of the dungeon (or the latest warp) while refilling your health, since it’s essentially the same thing as intentionally walking into enemies to run out of health and respawn there. Beside each warp and dungeon entrance is also a gadget that refills your health to maximum, for the same reason.
While there are some humorous cutscenes, mostly involving the bosses, there are no “mini-cutscenes” interrupting the regular gameplay. If you find a chest, you simple whack it into debris in one swing and collect the contents while a small explanatory popup appears. Control is never taken from the player during this time, nor while solving puzzles or opening doors. You can also skip cutscenes or turn them off completely.
The most interesting details about how the game world works are written on secret signs in the dungeons. The signs are not that well hidden, but if you discover something like this by yourself, rather than being told about it in some sort of tutorial, you’ll be more likely to read and remember it.
You should have some sort of conclusion or closing comment here.
You’re probably right.
May 5th, 2014 by Daniel Remar
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!
December 5th, 2013 by Daniel Remar
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! 🙂
December 3rd, 2013 by Daniel Remar
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!
December 1st, 2013 by Daniel Remar
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!
November 29th, 2013 by Daniel Remar
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”!
July 8th, 2011 by Daniel Remar
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.