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”!
We are basically finished with Ittle Dew for tablets, and we’re just about to submit and send out review copies.
I wanted to show you how it looks (and works). When you start the game for the first time you’re prompted to choose between two settings, gestures and on-screen buttons.
Playing with gestures is super comfortable since you can play with just one finger. Hold to go there, and use one of the four gestures to use the items. As you unlock the items, Tippsie will show you how to perform the action.
I know there’s a lot of players out there that don’t like on-screen controls, but actually they are my personal preference. We’ve iterated and tweaked the feel many times until we got them as good as we wanted them.
It’s easy to change controls at any time too, so try them both! We hope to have Ittle Dew out on tablets before the end of this month.
Our game “Card City Nights”, that Haku introduced in the last post, is in fact a crossover type game. With just Ludosity-related games! Games like Ittle Dew (of course – our one somewhat known game), Space Hunk (the bizarre Mojam game), Healthy Weapon (my android fighter) and of course Daniel Remar’s beloved games such as Iji, Garden Gnome Carnage & Hero Core. Plus many more, that you’ve never heard of!
In the game, you collect cards featuring these “franchises” but you also meet & battle people that are kind of characters from these games but “remixed” as various regular, urban card game enthusiasts.
Which means 2 things:
1) Almost no one will have any idea what the hell is going on with this baffling game.
2) I have to draw the characters from Daniel’s beloved games and not screw them up!
So let’s talk about 2. Here’s what I did, I had Daniel draw a sketch for his characters, to give me a pose to work with and ensure I don’t misinterpret details about their design.
Let me show you the process for my favorite character from Iji – Iosa the Invincible, reimagined here as a scientist working at the Card Science Lab:
One thing to note about Iji is that the sprites were first made in 3D, and then rendered out and touched up. So for the Iosa card art, we opened the 3D model and posed it a bit, and used that as the basis for the picture:
The idea for ‘Card City Nights’ came to me this last Easter, when the itch to code started to creep up on me after a few to many(2) vacation days. The initial idea was simple enough, I wanted to combine the three-in-a-row game play from ‘Might and Magic: Clash of Heroes’ with the chaining of cards from ‘Tetra Master’ (the card game in Final Fantasy IX). After a couple of hours I had a game with gray boxes with different symbols that could link with each other to bring down the opponents HP. A couple of days later I ripped the card graphics out of Ittle Dew and had something that looked like this:
The final version of the prototype for Card City Nights.
The project is now well on its way, with new elements inspired by games like ‘Pokemon: Trading Card Game’ and ‘Professor Layton’, graphics in the same style as Ittle Dew and with jazz and hip hop inspired music.
Here’s some screen shots and some music from the development so far! Enjoy.
A conversation with fishbun.
A game of Card City Nights.
Ittle Dew is progressing nicely, and we have it up and running on the majority of platforms supported by Unity. That’s Windows, Mac, iOS, Android, and now also PS3! It’s slightly awesome to see your own game on a PS3 console, a bit like magic really.
But we weren’t really satisfied with only those platforms, one is sorely missing. You can’t really call a launch ‘multi-platform’ unless it’s on the ZX Spectrum! So without further ado, here’s a snapshot from the game in its full glory. 16 colors, 8*8 tiles, no transparency – the way we all really like it. Stay tuned for a release date.
With our two 3DS projects being in the final stages of development we felt that we could move a human resource away from the 3DS projects to our backburner project: Ittle Dew. As I am that lucky resource I thought that I would write a blog post about the project – and my work on it – and steal some of the limelight from the 3DS projects. Being a programmer one would think that my blog post wouldn’t be interesting (just a bunch of math – amirite?) but this week I’ve been working on one of my favorite and also the coolest subject within game programming – shaders.
Image1 – Screen shot of the game before we added lights.
The last time we worked on project Ittle Dew it looked something like in image1. There’s nothing wrong with this picture, it’s still a nice looking game, but we wanted to do something more. We wanted to get rid of the flatness of the graphics and add some dynamicity to it. We accomplished this through lighting as it is one of the keystones for compositing a great looking image.
Lighting in games can be troublesome. For example, games are dynamic in nature it can be difficult to keep the lighting of the scene perfect in all scenarios – maybe the player destroyed the light source, maybe he/she moved it. There are also some technical problems – how do you shape the light to fit the environment. For example; Light can be represented as a sphere, brightest in the middle and fading as we get further away from the center. But what If that light is on a wall, we would have to account for that wall and change the shape of the light to a hemisphere so that the light doesn’t pass through the wall. Further still, what if there is a ceiling right above that light, we’d have to reshape that light to a quarter of a sphere (see image2). And what if there’s a suicidal robot frog just next to the … you get the picture.
Image2 – A sphere representing light being reshaped to fit the environment.
Since project Ittle Dew is a game in two dimensions and its level design is built up from cells in a grid the problem with lighting gets easier. First of all the light would be represented as a circle and not a sphere and secondly the grid based level design means that level objects always blocks one cell of light (not one and a half, not a third, etc). The solution I came up with was to draw a line from each light source to all the cells within the lights circle and check if that line is colliding with an object. If it is then it means that something is in the way of the light and this cell won’t get lit. If not, it means that the light has a straight line to travel and will make this cell brighter. Finally we added some fuzziness to this to allow the light to pass slightly through corners – to add the illusion that the light is bouncing on the objects.
Image3 – Left: The cells of light the fire creates. The brightest cell is in the middle of the fire, the darkest cells are where no ‘line’ of light could get to. Right: Smoothing out the cells over the actual game creates this result.
Watch the before and after below!
Image 4 – Before
Image 5 – After
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.
It’s about time we start talking about our next project, Mama & Son: Clean House!
Really Shooter and his mother Poor Mama are running a cleaning service business, with Really taking commando jobs on the side. One day, aliens invade (!) and Really doesn’t hesitate for one second, he heads over to their mother ship and begins to mow down the invading forces with his trusty machine-gun. And of course, as usual it is up to Mama to clean up the mess after him.
Clean House features dynamic two-player gameplay where Really takes care of business while protecting his mother, and Mama cleans up the mess and support her son with ammo. You can play with a friend or with AI, (or play both with one controller in hardcore mode). There’s Story Mode and Survival Mode with online highscore, all for less than a can of soda on Xbox Live Indie Games!
Me and Daniel started talking about this idea way back when we chose our bachelor’s project in uni, but we didn’t realize the idea until NoMoreSweden 2009, where it pretty much cleaned house (even though it was called poor cleaning lady then..) Since it turned out so fun and unique, we’ve now decided to bring it to Xbox in full HD!
It’s coming along really well – in fact it’s almost done! It’s currently in playtest phase and will go into certification early next week.
In the mean time, check out these wallpapers our lovely artist Stefan has put together!
Just wanted to let you know if you have some cool heavy metal-kind-of-music that you think would fit our upcoming game Mama & Son: Clean House please let us know! We are looking for musicians that can contribute to the game project. This is for you guys who already have songs finished so we can put them songs in as soon as possible. We are only looking for free tracks since the game itself had had very small budget. Off course you will be in the credits if we use your music!
The game is feature complete and Daniel Remar only needs to tighten up the graphics 🙂
Anyhow. Mail me! daniel.kaplan at ludosity.com