Posts Tagged ‘unity’
I made this entry for the rebellious candy jam… pretty sure it’s my best game so far!
Check it out!
Made with: Unity, Inkscape, Sfxr, Autotracker
Once, in a place not too different from ours, there was a people yearning for a life in peace. But they were ruled by a ruthless King who only loved one thing more than to see his people suffer. He loved candy. Most of all he loved playing a game he himself had “come up with”.
Each time the King got three candies connected, he scored. And when things were going badly, he cheated. The people had to produce new candy at an alarming rate to satisfy their King.
They had to resist.
The people started removing candies on the playing field right under his nose. They even went as far as to condition the King to play faster when they pressed a special buzzer.
The most daring used it quite often.
To gain the most, they needed the King to loose quickly while removing as few candies as possible. It was after all they who had to produce them.
Good luck, and save us all!
UPDATE: NOW FIXED STUPID TRANSPARENT MENU THING THAT WAS BLOCKING PLAY…
Give it a spin and let me know if you find it fun. Or if something could have been made better. Become the world record holder.
Lesson learned from this blunder of uploading games in the middle of the night while very tired and quite stressed: Don’t do it.
I have no idea what I’m doing! But I’m still having a good time.
My minild 48 game so far:
Hi there, Ludumdarians!
We have some news. We are working on fleshing out faif (our Ludum Dare #28 jam entry) and we decided to make a pre-release for your Android Devices!
You got the game before anyone else with an exclusive 50% discount. WHAAAAT?
What is Faif?
Faif is a puzzle/rpg game with a unique battle system based on gambling.
Try to defeat as many opponents as you can and unravel the secret story behind the game.
Look how gorgeous it is:
So download the game!
But hey! Listen!
if you don’t have an Android phone/tablet nor .99 cents to spend, you can still play the web version HERE!
Cheers and have fun!
* Note: Faif is still in development, we will be improving and uploading new versions of the game almost every week until final release for you to test it and help us flesh it out. You can use the “Tell Us” button in the game to send us your suggestions or comment right here! Thanks for all the support and hell yeah, just faif!
Since there’s less than a day left until ratings are finished and I haven’t gotten around to doing it yet, I figure I might do a little post-mortem of my LD28 Entry One Jump (not to be confused with a couple of other entries with the same name). This was my 2nd Ludum Dare game but the first submitted for the 48 hour compo.
My primary aim during the weekend was to avoid some of the mistakes I did in my last entry (such as time management) and submit something playable in time for the 48 hour compo. Prior to the competition, I decided I wanted to use Unity (specifically the new 2D tools) for a couple of reasons:
- Familiarity (I’ve used Unity before but not for a Ludum Dare entry) instead of trying to learn a new language/engine in 1/2 weeks
- More widespread deployment: Compared to my last entry (which used XNA), using Unity meant that I could easily deploy my entry to the web as well as create standalone versions in one go.
I also decided that I wanted to create a platformer (mostly because I haven’t made one before and also because I didn’t want to create a top-down game where you move something in 4 directions and shoot stuff). The day before the actual theme was announced, I did jot down a couple of ideas based on some of the themes that made it to the final round of voting (although I didn’t actually have an initial idea for the one that eventually chosen). After the theme was announced however, it took me some time to think of a core mechanic that would fit it (To be honest, I didn’t really like the theme although ironically, due to the primary mechanics, my last Ludum Dare game would have been an absolute perfect fit for it). Eventually, I decided to interpret “You Only Get One” as being able to do something that you can normally do many times only once. In the case of a platformer, the primary mechanic is jumping hence the main objective of my game: To simply reach the exit but being only able to jump once per level (which led to some rather strange and interesting level design)
What went right:
- Planning and Time Management: Compared to my last entry, I actually made much better use of my time thanks to the Unity workflow and managed to submit my entry in time for the competition.
- Levels: A common complaint with my last entry was that there were too few levels (about 4/5). Thanks to Unity, I was able to rapidly prototype levels in the editor without having to recompile and restart the game and created around 8 levels for my entry.
- Mechanics: Initially, I thought that being only able to jump once was too gimmicky (trying to design levels based on that mechanic was pretty hard as well as I wanted to make the player use their only jump at the right moment). In the end however, I was pretty satisfied with the end result.
What went wrong:
- Graphics: I’m not a very good artist so I decided to use simple shapes again for my entry. Unfortunately, I didn’t have enough time to change those shapes into something more plausible (but still somewhat crude).
- Lack of background audio: I initially created a small audio loop for my entry but I wasn’t able to get it to loop properly in Unity.
- General Platformer Physics: Although the game generally worked, some of the primary platforming mechanics were a bit buggy (having to create some momentum in order to jump, unintended wall sticking etc.). Some platforming elements such as the moving platforms didn’t work as much as I had hoped.
Feedback for my game so far has been fairly ok (and better than I had originally anticipated) with level design being praised the most and some platformer physics/controls being the main criticism.
Overall Experience and What I’ll do in the Future:
Compared to my last entry, I didn’t enjoy this one as much as I’d hoped (mainly because of the theme) even though I managed to submit something in time for the compo. I did have a fun time however and if there was anything new that I’ve learnt during that time, it’s that I shouldn’t be afraid of submitting to the jam instead (rather than treat it as a place where I didn’t submit my compo entry in time): if my entry needs one more day of polish then I should take advantage of that extra day. During the period of time before the next dare, I will try to make at least some improvement with my graphics skills (or failing that, just collab with an artist friend for the jam instead).
Faif is all about gambling. Take this spin for example. There is 3/5 chances to get a skull (-1 heart), 1/5 chance to get a heart (+1 heart) and 1/5 chance to get a sword (making +3 damage to your opponent, one for each skull in the selection). So what was the outcome? Victory of course!
We are currently fleshing out faif, uploading new versions every couple of days here, improving gameplay, balance and general performance. We added a new tile type (gems), a shop (even some “sale” logic into it!) and a couple powerups. We plan to add instant spells (playable during your turn), more tile types (weapons, effect tiles and so), boss battles, story mode…
Next week will be uploading and Android version to Google Play! (iOs version is coming later in the development process).
- Jam version: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=26231
- Post-compo version: http://beavl.com/faif/post.html
Cheers and have a great weekend!
Hi Everyone, our take on the theme was an action/arcade game based on a randomly generated grid that was filled with colors and mines. The player could select one color to reveal at a time, thus showing the safe cells. This game came out much harder than we expected since there was little skilled involved. We ended up creating special abilities to balance it out: such as armor, reveal, jump, etc. Also, we tied each ability/color to a positive character traits: courage, perseverance, resilience, and forgiveness. Here’s a run down of the good and the bad:
What went right:
- Polish. The game had logo, sound, artwork, and there were no bugs.
- Although difficult, the game was generally fun.
- The visual design was minimalistic, colorful, and most importantly, something we produced within our skill and time limitations.
- We experimented with a new creative process and the result was not too shabby. We plan to keep refining our approach.
- Easily published for Web, Windows, and OSX using Unity. We wanted the game available to as many people as possible.
What went wrong:
- The game was really challenging because we didn’t have enough gameplay elements to empower the player. We could have identified this sooner and planned accordingly.
- It was more based on luck than skill. It didn’t feel like you can improve skill and overcome the challenge.
- We aimed for 5 minute game session, it averaged 30-45 seconds.
- The introduction story was conceptualized after the core mechanics. It was trying to provide purpose via a “spiritual elements” concept, which was too abstract for such a literal game.
- There was no tutorial or instructions. We just tossed the player into deep waters without teaching them how to swim.
Even though our creation is essentially a “glorified minesweeper variant’, we are very happy with the game. We are continuing to work on it and making it the best it can be.
I noticed that many Unity users are now exporting a standalone version for Linux. This is great news, because otherwise I coulndn’t try their games, as there is no Unity Web player for Linux
However I’m not being able to run most of these standalone executables, and I was wondering if other Linux LDers are having similar issues. The most common symptom is that the game just fails to start without any error messages, or displays the screen size/depth selection window and exits right after that.
I guess this could be related to the target architecture – I have a 64bit version of Fedora 19, and the exported games seem to be for 32bit, but I don’t know if there’s a log file somewhere that might give some insight about what’s going on.
1) Keep it simple, no gravity, no physics.
2) Think of new patterns, learn more about engine.
2) Test content pipeline for full-HD graphics.
4) Have fun.
And i broke the first rule almost immediately after i started working.
At first i wasn’t quite sure if one limb mechanics is going to work, so i spent about 2 hours experimenting with physics model configuration, character mass and different approaches to moving the limb until i hit the fun combination. After that i started adding variants to basic grabbing and moving mechanics.
The pistol was the first thing i did (because GUNS):
But it didn’t get into the Jam-build, as i didn’t have enough time to make bullets and shooting mechanics. Controls in the game are hard to master, so i had to slowly introduce player to the motion and physics. First few level were going to be just “acrobatic”, and i only managed to make 3 levels.
I used the free Unity with the new Box2D physics, and my library of Unity classes with all kind of maths, utilities, and base objects (that’s why i’m doing jam, i can’t work without an extensive library of functions, mad props to everybody who can use bare minimum and do all the math from scratch in 2 days).
I have my own free-transform thingie:
I know, unity now has default 2d-transform, but this one works in 3d as well as in 2d, allows to transform all meshes and physics objects (not just 2d sprites in 2d), has shortcuts for depth and also does all the stuff that default transform does (including multiple object transforming). It saved me so much time on level editing. Also not using default 2d graphics.
I used my animation editor and playback system again:
There’s not much animation in this game though.
And here’s a tip:
If you are working with Unity, i suggest you to make an editor-window like this and put there all the frequently used functions. This one allows me to quickly lock background/foreground, add shapes/sprites/bodies to objects and bunch of other useful stuff.
I did a lot of drawing this time. There are total of 70 sprites:
I spent a lot of time choosing color scheme, and then cutting all the platforms, but it was fun.
What went right
1) I spent most of the time working on mechanics, graphics and level design instead of code.
2) Engine didn’t break down, all the custom tools worked as planned, so i didn’t waste any time debugging tools.
3) All graphics were made to look crispy in resolutions up to FullHD.
4) It was fun XD
What went wrong
1) Didn’t manage to implement some of the mechanics i wanted, and didn’t make enough levels.
2) The game becomes too hard too soon, again, could be solved with more levels and more gentle difficulty slope.
3) No sounds, no music. I didn’t think about it, but i should have chosen some free music before the jam.
And the links:
Thanks to everybody who participated, having a lot of fun playing your games!
Please remember that Unity can make Native binaries for Mac and Linux! It is just a click away:
File > Buildsettings > PC, mac and linux standalone > target platform > build.
In particular, don’t make JUST a web version, because some browser/system combinations don’t play very well with Unity’s web Plug-in.
Thank you, and hope to play your games soon!
faif – Battling with the odds
faif is our entry for Ludum Dare 28. It features a novel combat system based on… gambling!
faif was a 12 hours concept we decided to make because of… well, Ludum Dare! We love the jam and we really liked the theme, so why not? After finishing and sending an early concept version of the game (no sounds and some single-battling against dumb AI), we started receiving really encouraging feedback. Lots of people seem to love the core mechanics we came up to!
What we’re working on (post compo)
Despite currently working on another game (The Narrow Path), we resolved on making a post compo version of faif. So we started working on a to-do list with some specific goals in mind. This is what we’ve achieved so far:
- Infinite Battle Mode: fight one opponent after another until you are defeated! Every opponent has different behaviour and intelligence types).
- New visuals and retrofuturistic aesthetics!
We will be improving and uploading new versions of our weird battle game for players to enjoy it, test it and help us flesh it out! In the next days we will add new tiles and special powerups. (Note: Check our post compo version and please use the comment section if you have any suggestion o want to share any feeling about it).
Thanks for reading and being so awesome! Cheers everyone!
This was the second time for me at giving out a game.
Both times, I’m gathering people have enjoyed the games but found the character controllers funky. To this I agree.
This time around there were so many other things needing my attention that the controller had to be good enough as it was. Still not happy with it. Especially since I think we made a really quite interesting experience otherwise.
The two games are quite different, but I can’t help feeling like there’s something general I’m not seeing.
First was a 3D platformer from first person perspective Run with the Revolution and this Ludum we made a 2D platform puzzler:
In the latter, I opted for linecasting from the character’s center to three points below it to test its grounded state rather than using collision-detection on its box-collider.
I wanted to avoid being able to jump upon vertical wall touching, I also experimented with frontal collision using the same method as testing for ground. Idea was to have the character bounce back from walls it ran into so that it couldn’t and wouldn’t stick them. It seems that these attempts didn’t really work. Or it seems like I was missing something.
Having played some games this round and last, I know I’m far from alone in the defunct controller compartment.
So to those of you who know how to make smooth controllers within physics engines (I was using Unity), whats your magic?
(And yes, you should try our game, fortunately the controllers aren’t that important to it!)
I’ll be back with a proper what went which way… but I’d really like to see some comments on character control.
(Posted to my blog as well)
This past weekend was another Ludum Dare game competition, and the second one I’ve taken part in (this first you can read about here). I also organized a local meetup with the Knox Game Design group and we had five games in total submitted by the deadline. So without further adieu, here is my wrap up of what went right, and what went wrong!
Theme “You Only Get One”
For my game, YoGo Burger, I used the theme in a few ways. The setup is, due to some budget cuts, you can only put one topping on a burger. The customer will either be okay with it, or hate it and this will affect the amount of tip you get. To make matters worse, if a single customer complains to management you’ll be fired. To keep this from happening you use your tip money for bribes.
In practice the game is like playing multiple games of Mastermind at the same time. Customers will get back in line and order a second burger and if you remember what they liked before you can use that to get it right the second (and third, forth, etc) time. To make it interesting I reset the customer preferences each day, added more customers, and I also upped the value weights behind what they like and don’t. The effect is you’ll probably be deep in debt and fired by the end.
The design was very emergent. The initial idea was a Burger Time / Tapper / Diner Dash clone with one ingredient. It’s fair to say I didn’t really have a strong direction at the start, but as I added mechanics it began to take shape. I’m very happy with where I wound up and think that this kind of creative exercise is what the Ludum Dare excels at (even if the game isn’t fun for very long).
Programming in Unity
Just like the last time, I used the competition as an excuse to learn new technology. You might say this is the wrong time to learn something new, but twice now I’ve done it and shipped a game so we’ll have to agree to disagree. The new tech this round was Unity 4.3’s new 2D support.
Having working in Unity before, and having read up on the new features, this wasn’t so bad. Prior to the competition I had started porting my XTiled library to Unity, so I wasn’t completely green for this project. I had to google an issue here and there, but for the most part things went smooth. For the most part. Let’s talk animation…
Unity revamped their animation system for the 4.x release, and it’s now called “Mecanim”. It’s a very complex, yet powerful setup allowing you to define animations then link them with a state engine and create smooth transitions procedurally. That’s all good, but I need to move a sprite a few steps to the right and this seemed impossible. I’m sure spending more time with the system is what’s needed, but I have reservations about any system that cannot handle a simple, common use case well. If you cannot do the simple well, how am I to trust you won’t make the complex a nightmare?
In the end I wrote a few lines of code to handle all animations. I’m a programmer, it’s what I do.
Nothing good to report here.
I am no longer satisfied making excuses that “I’m a developer” or hearing “not bad for developer art” or worse “it’s so bad it’s good – you nailed the MS Paint ironic art style!”. See, I’m not trying for that. I don’t expect to be amazing, but I think it’s perfectly fine to expect decent. I commonly tell people I’m not “talented” I’ve just spent a lot of time writing code and anyone can reach where I’m at. I believe this to be true of anything, and it’s time I took my own advice.
So next year I’ll be reading up on art 101 and spending quality time with Gimp, Inkscape, and even Blender. Check back with me after 10,000 hours.
I needed exactly one sound effect for my game, so why is this even a section? Because it was my favorite part of the whole competition!
I wanted a cash register sound when a customer paid for their order, but because of the rules I cannot use anything I didn’t make during the competition and this include sound effects. Normally I’d use the amazing bfxr app to generate game sounds, but it wasn’t really suited for this task. I grabbed a portable microphone and headed out to hunt samples Foley style!
In the end I used a bell from my daughter’s bicycle and the opening and slamming shut a wooden drawer full of screws, bolts, and nuts. I then edited and combined those samples in Audacity, speeding up the playback by about 150%. The end result was a very convincing cash register ca-ching!
While I’m a horrible graphic artist, I am “decent” at music. This time I wanted to use my own guitar playing (as Dylan and Levi have done), however I’ve never actually hooked up a live instrument to FL Studio with my current audio gear. This led to a frustrating session of attempted guitar recordings before I decided there wasn’t enough time left to keep fooling with it and went with all synths – something I’m pretty comfortable with. (Yesterday I tried again, and it turns out I made a very simple mixer error).
The music inspiration came from the depressing, you-can’t-win-gameplay and reminded me of Papers Please. To get in the mood I loaded up some depressing Russian folk songs and waltzes until I had the right state of mind. Not going to win a Grammy, but I think it fit the game well.
And finally, as it tradition, here is a time-lapse of me making the whole thing – 17 hours compressed into 3 minutes!
Mama is Sick can be played here:
My first Ludum Dare! And my second game jam ever.
This post will cover what mine and @GarrickWinter (Guerric Haché)’s game is about, a summary of the process we went about making it and the top 3 things done well and the top 3 things we could improve on.
Quick description of our game (taken from the instructions screen):
“Mama is Sick” is a resource-management, hard-times simulation game.
YOU ONLY GET ONE DOLLAR A DAY to look after your family (thanks to a generous family from overseas) while papa is away and mama is sick.
Buy food and water to make sure the food, water and health bars of you and your family don’t reach zero or death will occur.
If your education bar reaches zero, you won’t graduate high school.
You have to last 50 days until papa comes back. Will you manage to graduate? Will everyone survive?
You can work in a clothing factory to earn 50c a day, but be careful not to miss too much school. You also need to study at least three days a week or risk not being able to graduate.
As soon as the theme was announced, Guerric and I decided to make a list of 10 game ideas based on the idea. This is always a useful exercise, jam or no jam, because it means you get to think up a few ‘less-inspired’ ideas, throw them out, then go with a better one.
We ended up with a list of 12 items:
- Menopause (This was my favourite until we settled on #9)
- Child (This started a conversation about China’s one-child policy, but we decided that since it was recently overturned, the issue would be dated in a game)
As soon as Guerric said ‘dollar’, we both knew it was what we wanted to do, and we started spouting off the potential things we could do with it.
Both Guerric and I are passionate about social activism, with my particular interest lying in feminism, so whenever we design together, we try to use mechanics to explore a social issue.
We also knew that given the time-frame, we had to design a game that would play to our strengths.
Guerric is basically a wizard programmer, but neither of us had worked with Unity properly in a few months (we both attend Vancouver Film School, studying game design).
Meanwhile, one of my goals is to be a narrative designer. Neither of us are artists, although my basic photoshop skills do tend to outshine Guerric’s adorably shoddy programmer art :P.
So we knew we weren’t going to do an open-world 3D game.
After settling on the ‘Only Get $1 a Day to Look After Your Family’ mechanic, the rest flowed pretty easily. We knew that interface design was going to be one of the most important things to get right for our game, so that was the first thing I worked on.
We worked on our mechanics for the first day and a half before I even got around to touching the narrative, which I did by writing a few pages of character design, then writing out the interactions I thought family members would have with each other.
Guerric, in the meantime, was busy figuring out how to optimise the GUI elements I had given him to work with.
We started putting in audio on day 3, leaving us with a full day to play-test, fix bugs and working on extra polish.
THINGS DONE WELL:
1. Planning and Documentation:
I wrote nearly 8000 words of documentation in total during the jam, with classic document titles such as ‘Audio To-Do List’, ‘Halved Numbered Narrative’ and ‘Guerric’s To-Do-List’. If you want polish for your game, make lists! Plan! Think ahead! We utilized Google Docs during the jam, meaning when I was play-testing, I could quickly point out a bug, add it to the list, then Guerric could cross it off the list when done.
Synergy! Just kidding. But seriously. The last time I had a working relationship this good was when I was in a band and my singing partner and I could improvise in harmony.
When you work with people who are interested in similar mechanics, passionate about similar issues – productivity triples. You don’t waste time arguing about meaningless items.
Guerric and I think of ‘Mama is Sick’ as our game. Not mine, not his. Even though elements of it were tasked to one person responsibility-wise, we still communicated everything we did to each other, constantly asking for feedback. Guerric proof-read my narrative and reminded me of elements to include in the GUI, I helped him think of programming solutions – synergy!
3. Play-Testing (and Scope)
On the second night of the jam, Guerric sent off a half-finished prototype to our friend Danilo. Even though it was nowhere near ready, this proved invaluable as it helped answer some questions that Guerric and I had been asking ourselves, such as, ‘Are the character stats bars enough? Does the player also need numerical values displayed?’ This helped relieve some of the worry we had. On the flip side, it also gave us confirmation for changes that needed to be made.
Furthermore, I was able to play-test the narrative 3 times – and would you believe that at one point, our game ran 90 days long instead of 50? On my first play-through, I reached day 56 when I realised, hang on. I don’t want to do this anymore. This is getting tiresome. Shit. I need to cut the narrative in half!
But none of this play-testing would have been possible without proper scoping. We knew our abilities, we knew the time restraints, and we knew what we had to do.
THINGS FOR IMPROVEMENT:
I feel like this is something that can almost never be done perfectly, as you’ll always have that one player who gets confused about something you hadn’t considered.
During the ’Girls Like Robots’ post-mortem presentation at Unite this year, designer Ziba Scott mentioned that the tutorial should always be made first, and that by following this principle, he discovered that he had already made a third of the game.
In the past day of playing other Ludum Dare games, I’ve found that the most common gripe people have is that they don’t understand how to play the game – whether that be confusion with the interface, what the goal is or the controls. And it’s a huge barrier for getting people to properly play-test and rate your game.
So although we spent a good few extra hours putting in things like hover-text explanations of GUI elements and an instructions screen, we definitely could do more – like an animated opening tutorial day (that would take a better artist than me to implement).
2. Don’t Learn the Engine on the Day
Although Guerric and I both have experience with Unity, we only took a brief period of time the day before the jam started to familiarise ourselves with the latest version.
This leads to precious minutes being spent learning how to use certain elements of the engine during the jam that could be spent otherwise.
It also leads to mistakes that can’t easily be fixed.
For example, I made all the GUI elements 300 dpi for a 800 x 600 game, when I should have made them 72 dpi. This led to an unnecessary decrease in picture quality, that was somewhat circumvented by a fix one of my old teachers recommended.
3. GET AN ARTIST
Oh boy. So yeah. I’m not an artist. All the GUI photoshop work I did could have been done better, in a shorter period of time, by an artist, had we had the foresight to bring one onto our team. That would have also freed me up to do things I’m more passionate about, like narrative and mechanical design.
Overall, I’m super glad that Guerric asked me to do this jam with him. I’ve had an amazing time, learnt lots, and am proud of the game that we’ve produced.
For me, the most rewarding part has been reading the comments that the community has left us, and I’ve certainly learnt a lot through playing the games of others, and the amount of talent and creativity crammed into this weekend by thousands of fellow designers awes me to no end.
Mama is Sick can be played here:
Hi! It’s Stalek from Evil Indie Games.
This time I was making LD28 jam game alone (without my brother:( ).
And… It’s a very strange game! ;D
The title is something like: superfrozenkittengetsonlyonesecretbottleforyou.
And the screens look something like that:
Tools used: unity, flash, photoshop and garageband.
It was very fun to work on it, too bad I didn’t have enough time to put all planned art, sounds, and many extra super features in it:/
Here’s superfrozenkittengetsonlyonesecretbottleforyou LD28 page <- come, see and play!:)
Wow. We finally finished the game. And almost all of what we wanted is in it.
This is my 3rd LD and 2nd in team. I didn’t write here before but should I start sometime? It’s a deep night here in Kyiv and other teammates is already sleeping (what-a-hell!).
So, this game is about the captain stuck in a distant galaxy. He is looking for parts for the new ship on the nearest planets.
He’s only one assistant and the best friend is his board computer GO-1.
Take a look. It’s not so fast or casual. Well, it’s hard despite the fact that it does not require fast reflexes. But it worth time I promise.
I’ve been wanting a programmer as a friend all my life! Finally, I have one, and he’s amazing! I’m so thrilled to have an outlet for my own graphic design skills I’ve worked to develop over the years. Please rate our game. It takes a little time to download, but it’s a solid experience all the way to the end.
Click and drag on the planet to rotate around it.
Click on problems that arise to try and balance the planet out.
As new problems develop, there are new solutions you must choose from in your tool bar.
Thanks alot! I can’t wait to play everyone else’s submissions too!
Completely forgot to formally announce my Compo game, so here it is!
Dinosaur Ranger Interview: Burrito Challenge SUPREME (DRIBCS) is a quirky, fast typing game made in Unity3D.
It’s the job of your dreams: dinosaur ranger. You’re on step away from living your life to its fullest. You’ve trained for years for this moment and all you have to do is pass the interview.
In a fit of foolishness, you snarfed down a huge burrito for breakfast, and now it’s trying to make its way out! Quickly type your responses, avoiding mistakes and try not to soil yourself!
Yay! That was so much fun, though. Unlike LD25 with the team, I felt so little stress I thought I was dreaming!
I don’t currently intend to become the best game jam dev evar, hehe, I just had fun making something, even if I didn’t get all the way with it in the time limit, I will always have the ability to return to it and flesh it out. I love LD because of what people end up doing with the always loved-and-hated theme both during and after!
Postmortem and top-down, plot/world-focused game design heuristic (for those of us who ain’t so good at starting bottom-up from a gameplay mechanic) after the jump: