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!