Today we’d like to announce a brand new little game, PsyCard!
A cozy cyberpunk minesweeper-like game for iOS and Android, coming soon!
If you’re an avid follower of all things Ludosity, you may remember a game prototype vote a while back. This is the result of that vote. We looked at the result of that, and based on other factors like the downtime we had and who on the team had said downtime, we decided to make the 3rd placer (out of 11) into a full-blown game. It was PsyCard, the versus minesweeper-like! Of course, this doesn’t mean we’ll never make any of the other prototypes. They’re all still ideas from various people at Ludosity, people who would like to see these games get made some day. But for now, the convenient choice was to make PsyCard.
Before I get into the development stuff, let me explain the rules of PsyCard.
PsyCard is a two player game, played with 8×4 cards (for standard rules at least) placed face down on a table. The players take turns picking cards to flip over. The contents of the opponents cards are always hidden (unless super powers are involved).
5 of these cards are ”Fruit Cards”, 2 of them are ”Star Cards” and 3 of them are ”Skull Cards”.
Finding 3 fruits makes you win the round.
Drawing a skull makes you lose the round.
The stars add points if you win the round with them.
When a round is over, the cards are reset and a new round begins. This continues until one player reaches the score limit and wins the whole match.
The trick to the game is that when you draw an ”empty” card, you get some psychic hints about what the cards around the empty card contains. Kind of like those numbers in Minesweeper, you know. And using these hints, and your characters special powers, you must find the good cards and avoid skulls to win.
I am to blame for most of the things in PsyCard – the gameplay design, the character art, the writing (lol!), the card match programming. Basically everything except for backgrounds and music (scroll down for more on those topics). I also made the original prototype. The initial idea was to make something interesting based on the popular game Minesweeper, but with something of an ”anime” twist – super powers etc. The gameplay was pretty much set from the start, but the art had a really bumpy ride even before the prototype was started! Check this out:
One of the things I wanted in this game was for the opponent to be more ”there” during the match than in for example our Card City Nights. So I made these kind of cut-in frames that pop in to let the opponent react to things like thinking they’ll win on their next move, or fearing the lack of safe cards to draw. I also show the full character portrait with some particles and stuff when the characters use their best special power.
As for the story… I tried! Since our resident awesome writer/designer Daniel Remar was busy with fine tuning Ittle Dew 2 (he did draw 3 bonus characters for PsyCard though and help test the game), I wrote this game and that’s really all there is to say on the matter.
Basically it’s a dystopian cyberpunk setting, but that doesn’t seem to bother anyone in the game. It’s just the world they live in, and they want to goof around and play this popular psychic card game.
The main characters that you choose from are a bunch of freeloaders that mooch of their mutual friend who got rich from being in some kind of accident. Then they go out to play cards and meet a bunch of weirdos while doing so, the end.
Honestly, when we put up the poll for those prototypes I had already discarded PsyCard as a dead idea but threw it into the ring anyway. I expected it to place super low, but somehow it didn’t. So I reluctantly tried to rekindle my feelings for the project and get things going. In the end, I think it turned out to be a fine mobile game for picking up and playing in short bursts.
Now let’s hear from some other people who worked on the game!
Nils’ comments (Background art)
When I started making the main story’s background art I only had a few character portraits to go on, it’s a nice thing to have free reins. As the main story had a setup similar to our earlier game Card City Nights with static backgrounds behind Antons character portraits, the heavily outlined cartoon style from CCN’s backgrounds felt appropriate to make a return. However, the mood of the characters where far less bright and wacky in PsyCard. This would reflect on the world as well. Not a lot of details where nailed down early on more than the idea of a darker future setting. To fit the cartoonish nature of Antons drawings, I started thinking back to the cyberpunk infused comic books I used to bury my nose in as a lad (The nerd store the characters visit in PsyCards campaign is heavily inspired by the store I read a lot of those comics in). I went heavier on the dark lines and mood, and easier on the anachronisms and wacky imagery that fills CCN. I wanted a bit of the feeling of those old comics and decided to use a limited color palette for the backgrounds. They also inspired me to segment the coloring; grouping objects together with the same color. To tie the world together, I tried to keep a theme of snow and winter in the areas. As if the city is isolated in a world of ice.
Mattias’ comments (Music)
The short musical themes made for the story were heavily inspired by the random animés I just happened to be watching around the same time. Tracks like these almost overemphasizes the mood of a scene or the character it’s bound to and does so very quickly.
The music used for the battles are all dance electronica tracks with old school sounds, from basic synths to single sample instruments and breakbeats common around the 90s.
Check out some of the awesome song over att Mattias’ SoundCloud!
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, 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.
Hello, Ittle Dew main artist here. Let’s talk about the move to 3D for a bit.
There’s a lot of great celshaded games recently (Guilty Gear Xrd, Jojo All Star Battle to name a few) that look amazing.
Celshading has always intrigued me – one of my favorite games of all time is Jet Set Radio, one of the first celshaded games i believe, a game that still looks so good. So when we discusssed Ittle Dew 2 being made in 3D, I saw this as a really fun challenge. Ittle Dew had a very particular style, with heavy black outlines and a wobbly style of animation (that wobbly style was actually selected because it makes animating so much easier! hah). We had previously experimented with Ittles style in 3D, with a dungeon crawler idea, and it had looked pretty good. However, in that test I used a lot of “billboards”(flat “sprite” objects that always look at the camera, think of the barrels in DOOM or items in Minecraft), while Ittle 2 went on to be a lot more “real” 3D.
Picture of said dungeon crawler:
(The Card City Nights faces are just placeholder, since it’s just a little prototype)
The first thing we did was have one of our wizard programmers make something do we could have wobbly outlines even in 3D, since by now we felt that was a big part of the Ittle Dew style. But just like in Ittle Dew it will only be used on things that are alive or interactive, kinda. To make them stand out. Using it on everything all the time would probably be really annoying to look at.
Here’s the process of a recently created enemy, Safety Jenny, with wobbly outlines:
(Animation is work in progress)
The outlines on both characters and props are not automatically created by an outline shader or such.
I find that to get decent looking outlines you need to create them manually so you can tweak problematic areas by hand.
There’s not much more to say about the surroundings, but let’s look at a picture.
The most important thing is to not lose too much of Ittle Dew’s charm when moving to 3D, and I dare say it’s going fairly well.
Having a (mostly) fixed camera helps a lot here!
And that’s pretty much it for me. Not a lot of informative text, but a bunch of pictures at least!
Hello everyone! Today we will learn how to make lava, and also how to make water.
“But this is blasphemy!” you say. “Only gods may do such things.” While that is a fact, sometimes you have to take the good with the evil.
We start off examining the basic ingredients of molten lava: A greyscale noise and a gradient map. Something like this perhaps:
Now if we just applied that map to the noise we would get a nice boring static lava-like thing, which wouldn’t do at all. It needs to move. Also I don’t know if you’ve ever seen lava, but it’s thick like the slime of a slug and moves faster in the center of a stream than it does close to the edges. We can solve this problem by having the above noise move in a certain direction with a certain speed, and having a different noise texture move in the same direction with a different speed (and don’t cheat by using the same noise texture; you’ll get artifacts and then cry when they happen to overlap). We then blend these two textures based on how close to the center they are (preferably using another texture to determine blend the factor). Now we have a noise that moves at different rates, and this is what we want to apply the gradient map to. With a really simple blend texture, it will look a little something like this:
Making water is a bit more complicated deal, but it starts with two parts. A big old plane mesh with lots of subdivisions, for waves; and everything else that’s going to be affected by these waves. The waves are fairly straightforward; just move them up and down in a vertex program based on some sine function. However you will want to make sure whatever position-based arguments to pass are based on the world-position of the vertices, because we will have to recreate this function in the wave-affected objects later. For convenience, let’s say our wave function is
sin(P.x + t*2π)
where P is our vertex’ world position and t is the time offset of the waves. We apply this function to the vertices of the plane mesh and we obviously get waves moving in the x-direction only. That’s fine for now, but the advanced reader would want to do something about that.
Anyway, now that we have waves, we switch to the other objects. We want to create foam or something at the intersection with the wave mesh. To do this, we first use the same function to calculate the current wave height in their vertex programs, then use this to create a gradient from 1 at the wave height, to 0 at a certain height above the wave height. For extra fancy, apply a noise to this gradient, using the gradient value as a threshold. Maybe move the noise around for a more dynamic look.
Sadly we are not finished yet. It may look okay at this point, but we also want whatever it is to look a bit wet after the waves have rolled by, and also for this wetness to slowly creep down towards the water. We can’t simply use the wave function for this because that will make the wetness move in a sine wave, which looks terrible. We need a function that moves up with the wave function, but goes down linearly, until it goes up with the next wave, and so on. How to do that? Well it’s pretty simple, just make a sawtooth function with the same period as the wave function, offset it in height and phase so the top coincides with the top of the wave function and tweak the slope to your liking. Using the above wave function, our “wetness” function could look something like this:
1 – frac((P.x + t) – 0.25) * x
where x is the slope multiplier value.
Then just take the maximum of these two functions to get the current height of the wetness. Use the resulting value to shade the fragments below darker.
Go all that? You should now be able to make something like this:
The Earth is counting on you!! Good luck!
The music in Ittle Dew was generally positively received, but didn’t really stand out. We did have a pretty cool system for fading between different instrumentations of the same theme on the overworld, but that’s nothing new – I first remember hearing that in Diddy Kong Racing on the Nintendo 64.
Ittle Dew was Mattias’ first score – normally he’s on coding duties – but I think he did a very good job, especially with so little experience. For Card City Nights he really came into his own with a score much closer to his (and mine) tastes, and a strong theme that went through the entire game. All locations have a jazz song as base, and the combat in each zone is a hiphop remix of respective jazz song. This came out great and we got loads of praise for the CCN soundtrack. It’s actually selling a little bit on it’s own in iTunes and Spotify =)
So for Ittle Dew 2 we want to step it up again and do something new and fresh. And not just find a fresh genre, but to do music in a new way. Reconsider the use of music in a game at a more basic level.
This a first, very rough prototype of what we initially came up with. We simply put the musical elements on objects in the world, and let them play only as they enter the current view of the screen.
Steer with WASD. Start by going up, and then go left until you get to the blue area.
The squares represent different elements of a spooky forest; Trees, Frogs, Stars, Flowers and Plants. See the screenshot below for an idea of what it could look like ingame:
We didn’t spend more than a couple of hours on this prototype, but hopefully it’ll come out great in the actual game. As the different elements play they should probably animate a little. We’ll also try putting the music on enemies instead of level elements, or both. Lot’s of experimentation left to do!
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”!