Posts Tagged ‘unity’
A friend and I recently decided to enter the Indie Game Maker Contest and we just submitted our entry earlier this week. Would love for some of you to take a look at it and let us know what you think. We ran out of time to do everything we wanted, but it is in a very playable and fairly polished state. We plan on adding a few more features and then giving it a full release.
The concept is something I had considered doing for a previous Ludum Dare, but ended up not having the time. It is pretty unique, I think, combining the procedurally generated gameplay of an endless runner with the scaling mechanics of Katamari Damacy. Yes, you can play it forever if you’re good enough. It’s also got a very nice hand-painted art-style.
On our contest entry page you can find more screenshots, longer gameplay video, and links to either download (Windows EXE) Miopia or play it in your browser (via the Unity plugin).
Well, after some tuning and graphics updates, I decided to submit Tiny Haunt, my LD29 entry, to IndieCade. While the LD feedback was vastly positive, there was one common complaint: the game wasn’t hard enough. I intended the game to be fairly sandboxy, and to that end, fairly easy if you choose. However, I ran out of time to implement the mechanics that made it more than that. In the IndieCade build each of the four levels has its own optional challenge, which might be defeating enemies within a certain amount of time, or using only one ability. I’m happy with the progress I’ve made so far, but there is still so much to do! A big part of the future experience will be enhanced interactions with enemies and more objects put at your disposal. On top of that I have plans to add an exploration element that allows you to uncover the long lost secrets of your castle. Exciting times ahead!
Early in the jam I had a bunch of different ideas. This is pretty normal. I liked the theme, so much so that it almost gave me too many options for achievable small games I would have enjoyed making. In the end I went for my ‘fallback idea’ – something I’d wanted to try if I could tweak it to fit the theme: a Descent-like game with visuals similar to Zombie Gunship.
What I wanted to achieve was:
1) Set up 6DOF ship controls that felt good. Not necessarily identical to the original Descent, but along those lines.
2) Recreate visuals similar to Zombie Gunship (essentially inverted greyscale, with object highlighting)
3) Incorporate this into a small prototype game, as a sandbox for something bigger.
I’m happy since I feel like I largely met goals (1) and (2), with some detours, while the gameplay component of (3) isn’t nearly refined enough.
Get ready to jump on ice as long as you can to survive in this first update !
This post compo game contains the following improvements :
- Controls : camera improvements and strafing available
- Gameplay : some ice will gradually spawn and surface to let you survive longer
- Graphics : add anti-aliasing & bloom effect !
Play the compo & post compo here !
This is my 3rd LD and this time I wanted to write a postmortem to share my thoughts and experience. Deep Descent is the compo game and you can play it here. It’s a game where you have to get to the center of the planet by killing monsters and using your totally physically accurate harpoon gun that bounces off enemies and gains their power.
- Good concept: To make use of the theme we came up with the side view. A sectioned planet made the theme evident both visually and from a go
al standpoint: you can see your progress clearly and it’s not a very common concept to use a spherical world (I miss you, Populous 3!). To add gameplay to this idea we wanted an original weapon. Not just X diverse weapons, but one unique weapon that can function as X weapons. That way we came up with the harpoon gun. It makes use of gravity on a spherical world so it’s pretty unique to control, and it bounces off enemies acquiring their power, which makes for some cool combos.
- Diverse team: It was the first time I worked in a jam with so many people (4 programmers, 1 2D artist and 2 musicians). Most of the jams I’ve done
up until now were by myself or 2-3 people that were always programmers. It was a great experience to work with and coordinate so many diverse figures in the not-most-ideal conditions (but more on that later)
- Experienced team: Each of us had previous experience working on other games or jams, experience wi
th the tools we used and some of us had even worked together
- Good music and graphics: At the end of what seemed like the 1000th hour of programming I had barely listened to the music our guys had composed and hadn’t really paid much attention to the graphics, but I was amazed at the end to see how nicely everything fell into place together and raised the enjoyment of what I could only describe as “a buggy mess”. Erika‘s cute character design and drawings (made so the game could be enjoyable to her little brother) and Igor‘s and Roland‘s compositions gave life to everything!
- Remote communication: We couldn’t find a place to fit so many people for 3 days so we made due with Google Hangouts. I all of the jams I’ve done I’ve always worked with my teammates face to face. Online communication is slower, and it gives you less incentive to work, because you’re not as committed as when you SEE your mates working constantly. It was obvious that organizing 7 people online would be a huge challenge, but considering this was our first time I think we managed to do it pretty well.
- Overextending design: “4 programmers can implement X amount of features” I thought. What I didn’t really consider was what would happen when 2 of them didn’t work full time on the project. They had told me this from the start but I was hoping to convince them to invest more. The design of the game needed 4 enemy types (and consequently 4 weapon types) and a boss to be fun. A layered design would have been better in this case (and in general really). Features that are most fun should be implemented first and the others left last. For a jam, I have come to believe that a single mechanic should be designed at the beginning. When that’s working it can be:
- Polished: Juice it up and make it clearer/more fun
- Extended: everything that falls in the “more of this” category
- Scratched: if it’s just not as good as you though
- Lots of bugs: In the end we actually had 4 enemies, but their intelligence, attacks and powers given to you harpoon gun were all very bugged and unreliable. The teleporter to the next level works 1/10th of the time, and the player was even invulnerable when it was first published. While some of these bugs were patched and will continue to be patched soon, it was a terrible state for the game to be in for the voting stage.
- Lack of polish: If you’ve read this up until now this was obviously coming. There are things can be done to improve the experience, like the fact that you don’t have much to do on each layer except jump and kill enemies. The game mechanics are not clear and have to be explained before: you can’t tell what powers your harpoon has, you can’t tell what the objective is or how the teleporters work
Hope this was an interesting read and see you guys in 3 months when I’ll be using all the stuff I’ve learned.
or Blue-Moltar Goes Digging
Hey, everybody! Dan reporting here in place of Josh, since he says he’s “no good at this.” If you haven’t had a chance yet, you should totally try out SPACE DRILLER.
It’s about a guy (who ended up looking like a blue version of Moltar) with a drill, in a space-mine, fighting ghosts, slimes, and giant tiki-heads. This was the first ever LD in which I’ve been able to participate, and I have to say that it was quite the experience. All the tales of the fun and the stress and the reward were all quite accurate. We all had a blast making it, and it was a very fun ride. Some time after the ordeal, we’ve both had a chance to mull over our experiences. Lots of things went right, equally many went wrong, but in the end it got finished!
What went right
- D – It didn’t take us very long to get rolling. SPACE DRILLER was our second idea to hash out, and we kind of stuck to it. I thought the idea of a guy in space with a huge drill that he used to kill things was hilarious. It was kind of a jumping point for more ridiculous ideas that everyone seemed to like.
- D – It was pitched as a Metroidvania game from the get-go, which also didn’t take very much convincing to get everyone on board. The idea of a melee-range Metroidvania seemed like it might not work for a moment, but the prospect of a few ranged powerups (that didn’t make it in!) made us stick with it. Then Josh showed me a gif of him surfing atop of a horde ghosts with a drill, and I knew that we were golden.
- J -
- D – We’ve made games before, both together and on our own, so we had a good grasp on how to get going quickly. It let us know where we could go nuts and when to dial back, as well as cut out a lot things that would normally have been easy mistakes to make. The allure of entirely hand-drawn and painted assets is a strong one, but that bit me in the ass twice already and I wasn’t about to try again in a 72 hour competition. I had personally never done art on a pixel-by-pixel level, but it went smoothly enough after getting started.
- J – Having used the Futile framework for almost a year now was definitely beneficial. It let us get rolling quickly and we knew what was reasonable and doable in the 72 hours.
-Implementation of elements
- D – It seemed like as soon as I finished the art of something, Josh would have it in the game and working in the next five minutes. I’d draw some tiki heads, turn around, and then they were hopping along my screen.
- J – Programming art may not be fun or nice to look at, but it lets the programmer implement the objects and as soon as the actual art is done for it there’s no waiting time for anyone.
-Setting realistic goals
- D – We wanted more. So much more. But that’s true of every game dev out there. Personally, I had no problems in dialing back the amount of things to have in the game. We were really good at cracking down and being realistic at what we could and could not have in the game, which is what let us put as much polish on the game as we did.
- J – Yeah many features didn’t make it in and many features were cut out at the last second, but that is a part of LD eh?
What went wrong
-The OTHER deadline
- D – I had a business trip scheduled for Monday that could not have been changed. The plane left at 7am, and I was sweating it pretty hard over not being able to finish what I needed to do. My plan was to get a few levels designed, sleep an hour, then do the rest on the plane trip. Turns out I got no levels done, sat with my eyes closed for 30 minutes, and had even more levels to do while on the plane (I was 95% done when I touched down, though!).
- J – This was terrifying. For a while I wasn’t sure we would have a playable game to submit.
-Lack of experience
- D – So this was my first foray into Unity. As well as the Futile framework. And the level editor we used. Though I got my levels laid out on my plane trip and felt great about it, it turns out that I had set it up in a funny way that meant a little more work to actually get it all working. There was also an issue between the two of us that caused some slight panic. As it turns out framerates are kind of important when calculating jumping height, and my dude was jumping far different than from what Josh had. Thankfully, he’s a wizard and fixed it.
- J – This was my first time programming a Metroidvania and I overlooked the fact that gravity was applied to the player based on the amount of time that passed since the last update. It was quite a revelation when I realized that Dan and I were playing essentially different games with different jump heights. Luckily I was able to fix this quickly but this could have easily been a game breaker and wouldn’t have happened if we were physically in the same place at any point during the jam.
- D – I discovered some limitations with Photoshop the hard way. It could have potentially been a bug, but it eventually started giving me crap about slicing images that I did not appreciate. Also, upon my plane landing and securing a bit of time for myself to work before the deadline, Unity decided that it did not like the texture atlas. I was reduced to worrying and testing whenever possible in the final hours.
- D – We didn’t meet up face-to-face once throughout the entire weekend. We easily could have, but for some reason decided not to. Communicating entirely through text chat can be counter-intuitive a lot of the time, and I left Josh confused with many things I said in regards to some very important aspects.
- J – This was definitely a big problem. Several issues came up that would have otherwise been no problem at all. Also some ideas took longer to get across than they should have.
- D – Virtually none happened whatsoever. What testing that did happen was frantic and last-minute. We might have saved a lot of headache had we done it sooner, and it’s definitely on the list of things that need to happen in the future.
- J – The lack of testing definitely left some of the levels much more difficult than we had intended.
- D – More of everything. Enemies, art, locations, powerups, and an actual story! We had some pretty rad stuff that we wanted to implement initially, and we’re going to try and go forward with it. The Incredible Flying Drill might not make a full return, but I promise that more fun things will take its place.
- J – Don’t listen to Dan. We’ll still have flying drill. I’ll hide it in the game somewhere.
With the weather being so nice outside last weekend, it was really hard to get psyched about sitting in front of the computer all weekend to make a game. However, I’ve participated in every Ludum Dare and mini-Ludum Dare since #26, so I felt compelled to make something even if it was really simple. I really didn’t have any good ideas for “Beneath the Surface”, so I decided to create a treasure hunting game. For my LD29 warmup, I made a simple MineSweeper game, so I thought it would be neat to expand on the basic concepts of that game. Instead of avoiding mines, you are trying to find buried treasure in a three dimensional world.
At first I just got the hidden treasure pieces to randomly populate on the game world, which are the items you must find. The digging unit was the first that I created, which I renamed “excavator” since it sounds fancier. He just uncovers whatever is hidden at his location. However, randomly adding excavators to the map really didn’t seem challenging.
Then I got the idea to allow the player to “ping” the map to get a general idea of the treasure location. This reminded me of the news stories about crews using scanning devices to find the missing Malaysian airplane off the coast of Australia. I originally wanted to have a heat map showing the pinged locations and the amount of treasure in the area. However, I had to settle for just colored circle areas on the ground representing the amount of treasure in the area. It was fitting that this is very similar to the job that an archaeological surveyor does, so I created a “surveyor” unit specifically for this job.
Finally, an excavator only knows about digging, and only a true expert would know the value of a lost treasure. Therefore, I created the “appraiser” unit to determine the value of each discovered treasure. The inspiration of this unit came from shows like Pawn Stars and American Pickers, where they will call in an expert to determine the value of a given “piece”.
I had plenty of more ideas which had to be cut. There was going to be rocks on the game world and an explosives expert unit which would destroy the rocks so that the excavator could dig. I also did a little research on some of the most famous lost archaeological artifacts from around the world, which I wanted to include in my game. However, I just had enough time to include one treasure piece which looks like a golden chalice. I also got suggestions to add adversaries like spiders, floods, and diseases which could eliminate units, but I didn’t have time to include any of those.
For this game, I wasn’t too worried about creating the best looking game ever. In my previous Ludum Dare entries, I spent much more time polishing, but it never seemed to have much of an impact on my ratings. I’m much less concerned about ratings this time, and more focused on learning new things. For example, this time I got fully functional map controls working with the mouse, including zoom in/out with the mouse wheel. I figured out how to create a unit on the game world at the position where the player clicks. When implementing that feature, I got stuck when trying to cast a ray from the camera to the plane on the ground. For some reason, none of the camera API calls were working. I thought my Unity libraries may have gotten hosed or there was some issue with the compiler. After taking a break and coming back to it, I realized that on the title screen I had created a script called “Camera” for moving the title camera. All calls to camera were referring to that script, which explained why I could not access any of the Camera API methods. Changing the name of my title camera script resolved that problem.
Another issue was with the appraisers. Since the player could add an appraiser at any location in the world, the appraiser would need to walk to the nearest treasure. I did learn that I can access all of the Treasure objects by tagging them with “treasure” and then calling the GameObject.GetObjectsWithTag method. This also resolves a Unity problem that I was never able to figure out, which is referencing game world objects (in the Hierarchy) from a Prefab.
I will admit that there are some things that I’ve done so many times when creating a Unity game, that it just isn’t fun anymore. One of those things is creating human models. Unfortunately, in the 48 hour compo pre-existing assets are not allowed, so I had to create a human model from scratch again. I guess it’s good for the Blender practice. I used one model for the three different units, but used a different texture and animation for each unit. I originally started by creating the excavator with a shovel, but I found that it was going to be way too difficult to animate the character with the object, so the shovel was removed.
In the end, I got most of the basics working but it really didn’t look like a completed game. There was a bug which sometimes prevented the appraisers from collecting treasures. After looking into it some more, I found that this was because I thought that code execution stopped when Destroy was called on a gameObject. Actually, the script attached to a gameObject will continue until the Update method finishes. In my code, the appraiser was targeting the next treasure after Destroy was called, so that no other appraisers could target the treasure and appraise it. That was a simple one line fix to solve.
The biggest mistake that I think I made in this Ludum Dare was spending to much time basically re-inventing the wheel. I really don’t like the default Unity GUI buttons, so I decided to make my own. However, the process of making custom buttons is not a trivial one and is time consuming. Before the next Ludum Dare, I would like to have my own personal Unity library for things like graphical toggle buttons, menus, camera controls, font outlines, and dialog boxes. That way I could spend more time making the game, rather than trying to get a button to illuminate.
I liked the concept of this game, because I haven’t seen it done before. Therefore, I spent a little time this weekend making some changes for the Post-Compo version. I looked into how to modify the Unity terrain at run-time, so now when the excavators dig, it actually makes a dip in the terrain which is what I had originally envisioned. The biggest problem I ran into is that the terrain map starts at 0 height, so there was no way to make the terrain go any lower. Setting the base terrain level to 300 fixed this problem, and I just subtract 0.005 from the terrain height where the excavator digs. It took me a little while to figure out that the height array is from 0 to 1, not actual world units.
Overall, I’m happy with the results of this game. It definitely isn’t as visually impressive as my previous Ludum Dare entries, but I think the gameplay is much deeper. Adding adversaries to the game would probably make it much more exciting. If there is enough interest, I would be willing to port it to other platforms, since I think it would make a great mobile game. Online features such as leaderboards would also be nice to have. If I ever felt really ambitious, I could have an online server containing treasure data for everyone playing the game, so everyone is excavating from the same online world.
New Dawn was the first Ludum Dare entry for both members of our team, and the first game jam/compo of any sort that we’ve done. We went in with little preparation and an overdose of optimism, but overall it came out pretty well! We weren’t able to do as much as we’d hoped – that probably goes for everyone here – but we finished in 72 hours and still came up with a solid little game.
We had a general idea of what we wanted to make before LD started: some kind of mini-RPG or adventure game. We couldn’t help brainstorming as we were voting on themes, and we really liked the idea of setting the game in a dystopia. A few of the themes could’ve made that setting difficult, but luckily for us,“Beneath the Surface” fit really well. It led to an interesting post-apocalyptic setting where the action takes place underground because the surface is no longer habitable. Plus, a dystopian setting was perfect for adding layers of secrets and false pretenses, which meant we could interpret the theme both literally and figuratively. We didn’t get to do as much of the latter as we originally planned, but we think it still comes through pretty well.
Although we started with the idea of a “mini-RPG,” we knew we probably wouldn’t have time to add many RPG elements. As it turned out, we ended up just sticking to a point-and-click adventure game. In order to have time to code extra RPG features, like a combat system, we would’ve had to spend less time on art and the dialogue system. That would have led to a very different kind of game, not necessarily a bad one, but we felt New Dawn would be better served by focusing on the story and the atmosphere. Having a better dialogue system and more detailed art helped to strengthen the story and atmosphere, whereas RPG mechanics wouldn’t really add as much in that sense. That said, if we had more time, we would have liked to add those as well.
Stefan (Coding, Art, Concept/Gameplay Design): Going in I knew I was going to use Unity (and C#), along with 2D Toolkit. I had laid out a basic plan which was to try to implement all the features by the end of the first 24 hours, then all the art by the end of the second 24 hours, and leave the third day for testing, bugfixing, and polish. I did this because I know that games always take longer than you expect, so this gave us some room to work with and helped curb our ambitions and expectations. As it turned out, this was a great idea, because although I did finish all the crucial features in the first 24 hours, the art ended up taking much longer and wasn’t done until well into the third day (and I didn’t sleep at all Sunday night either!).
Ultimately I’m a programmer, not an artist, so I’m not very efficient at that stuff because I haven’t done it much. However another big reason it took so long is that while 2D Toolkit is very convenient, it has some very tedious interface problems that require manually doing repetitive actions over and over, which really should be automated. These actions can be automated by script, but at the time I wasn’t sure if the amount of time it would take to write those scripts would be less than the time it takes to do the stuff manually. In retrospect, I think for the amount of art we had it probably wouldn’t have saved us that much. However, if I could do it over again, I would have set up those automation extensions to 2D Toolkit before LD started, because that definitely would have saved a lot of time.
The art itself also took a lot of time because I chose to put a lot of detail into it, despite it being very low-res pixel art. The details are largely in the shading, which ate up a lot of time, especially for the tilesets which required many different versions of each wall tile in order for the shading to match up. This also meant more work for Olivia when placing the tiles to build out the levels. The shading, especially on the tiles, is a very subtle effect, which I don’t think most people would notice unless they’re familiar with how tilesets work and are specifically thinking about it (which you usually don’t do when you play a game even if you are familiar with how it works). However, I still think it was worth it to spend this extra time, because although most people won’t consciously recognize that the shading is there, when it isn’t there it really stands out and looks noticeably worse. In particular, I think the atmosphere of the game was really well served by the extra shading detail. After drawing the basic shape and applying the shading, I also applied a noise filter to all except the character sprites to give them a bit of extra grit which I think fits the setting well.
On the third day, once the art was finally completed, we only had a few hours left before the submission deadline. At this point I implemented a few extra features that I didn’t consider crucial, most notably the ability for NPCs to move. At this point it struck me that the ending we were planning was going to be very anticlimactic; so I decided to spend the rest of the time quickly building out an additional final level to provide a more climactic ending, while Olivia was finishing up the penultimate level. I think this was definitely a good decision in the end, however it was risky, because we ended up cutting it very close; if it wasn’t for the submission grace period we would have missed the deadline. But overall it definitely makes the game feel much more satisfying when you finish it, so I’m glad I made that choice.
Olivia (Writing, World/Level Design, Music): We knew the general kind of story we wanted to tell before LD started, so once the theme was announced I started hashing out the details. I spent most of the first day planning the overall plot, with input from Stefan, and writing descriptions/dialogue for generic NPCs and a few items. Though I didn’t implement them that day, all of those descriptions made it into the game, and really helped the world feel more inhabited. I also wrote text for an intro screen which eventually turned into our game page’s description.
Saturday and Sunday were mostly spent setting up levels: I’m pretty new to level design, and that turned into a huge, unexpected time sink. One of the original “exterior” areas I’d made was close to the size of a real city block – way more space than we had time to fill with interesting stuff! That time would’ve been much better spent populating the existing areas and doing additional writing, but…lesson learned. I said goodbye to my hopes of having all the levels finished by midday Sunday, and had to cut a plot branch and simplify the remaining ones to make sure I’d have time to finish the story.
Monday was mostly a rush to implement the last of the plot. Thankfully I’d planned it all and written some of it beforehand. The penultimate level, two crucial dialogue trees, and two optional but pretty significant NPCs didn’t exist in-game until late Monday afternoon. I also wrote the second (and shortest) part of our music that day, since I wanted at least a little variety. In our rush to submit, there wasn’t time to put the intro text on a starting screen, but that’s something I definitely plan to fix post-comp.
There were a few things I’d hoped to fit in, even with the deadline looming, that didn’t make it. The main one was a set of PA speaker announcements (in the form of text dialogue) which would’ve given more backstory and context to the world. I also wanted to implement sound effects – we’d made a bunch in bfxr – and additional music. My next priority would probably have been adding waypoints so generic NPCs can move and putting more decorations and ambient descriptions throughout the world. In spite of all those cuts, though, we still managed to tell a complete story in 72 hours, and I’m pretty happy with it.
What We Learned:
After we submitted the game, we got a lot of great feedback from commenters. Several people had problems with the click-to-move interface, and since we didn’t anticipate that we hadn’t put in any alternate control schemes (though our post-LD update lets you click and hold, which should alleviate much of the problem). We also made the main quest a little easier to figure out in some post-LD tweaks, since several people were getting stuck. Additionally, given the amount of content we had to cut due to the time limit, some of the areas ended up feeling a little empty. They probably should’ve been shrunk down. On the whole, though, the story and art that we had came together really well, and we ended up with a short but atmospheric adventure game.
LD was a great experience, and it really motivated us to make a game of our own from start to finish. We might do something totally different next time around, but we’ll definitely be there!
When I discovered the theme I first thought about a game with a people living on ice. But a monster was living beneath the surface and regullary killed some of them. You goal was to investigate and find the monster … but a least I decided that it was too complex for a week end and at the end of the first day I changed the game (below screenshot of this first idea).
So I kept the iceberg but it became a frenetic survival game. I worked a lot on sound and lighting to get a great atmosphere even if the design was minimalist. I took a lot of time to get the feeling on/under the surface. About the code the AI of the monsters isn’t very evolved but combined to the stress of sinking iceberg I thought it was enough. I added a scoring, a system to randomly add some iceberg and it was already the end!
- lost too much time on the first scenario, no music this time, controls not enough polished, wanted to try Open GL
+ sound & lighting quite good, quite productive (I worked about 15h on it)
Coming soon : I’m working on a small update!
Hey, folks. Coin Flip Games here to tell you about our entry for LD29, Bitmite Blitz. We’re incredibly proud of this game and wanted to make sure YOU got a chance to play it. If you’re not convinced, here’s some of our favorite reviews we’ve gotten so far!
“Super fun game. I have highscore! for now :P” - tehryanx (Still has the high score, btw)
“I love games that put me in a perspective I never would have thought to explore. Great game!” - greysphere
“This is definitely one of the most polished games I’ve seen in the LD. Having an achievement system is an impressive addition, given the time constraint.” - StencylTuo
“Good game, it gives me the same feeling as Flappy bird which is a good thing.” - Sparrow
Back? Okay. I wanted to talk a bit about how we accomplished the global leaderboard. I’d love to see more games with this feature because I think it adds a whole new dimension. So, to start, you can implement this in any language or game engine you would already be using. Some (like Unity) will make it easy than others, however. You need 3 things, a server to host the scoreboard api and scores, you game and a communication layer between them. Ideally, you want to have something in place to prevent people from adding fake scores as well.
Set up a database of some sort. Use whatever you would feel comfortable with and if you’re not comfortable with anything, use MySQL or sqlite. You can get away with, as a bare minimum, a single table: scores, but that’s not so much fun, is it? You can easily use this in a bunch of games if you do it right the first time.
- Set up your database engine (mysql in our case)
- Add a database and user. Make sure that the user permissions make sense. Don’t give them GRANT access to anything. Ever.
- Add the tables as below:
Alright! Done with the database for now. Now we need to setup the API. I’m going to leave the actual implementation up to you (as an exercise or something), but the functionality you’ll need is…
- To receive input from the web in some well defined format. I used PHP to get data as JSON. You could use Ruby, Python or whatever fancy language you want. You could use XML too if that’s what you’re into.
- Check the input to ensure that it’s valid. (Did this come from a legitimate source? Does the input make sense?)
- Sanitize the input. (Can’t stress this one enough)
- Perform some action on the data. (Run the command ‘getScores’)
- Return results in some well defined format. (Package up the results of the command as JSON and pass it back)
And on the client-side (game) we need to do the same thing, but in reverse. The client needs to build these requests and be able to parse the responses. Since I used JSON, I’ll show our request as an example.
api_key: ‘…’, (I’ll get back to these)
And the server would spit back
['name': 'Awesome Bitmite Blitz Player', 'score': 100000],
['name': 'Awesome Bitmite Blitz Player 2', 'score': 10000],
Easy enough. The trickiest part is ensuring that the scoreboard can’t be tricked into allowing scores that aren’t legitimate. That’s where the API key and secret come in. For every game that will use this leaderboard, generate some random string for the API key and some random, hard to guess string for the secret. The database knows what these are and your API can check them out no problem. You’ll also need to let your game know what these are and if you’re lucky enough to have a compiled language, they’ll be safe from curious eyes. (if you release the source code for your game, strip both out).
So now the server API and the game both know the API key and secret. Great. Now let’s use them to generate a signature for all the requests that the game client will make.
So the idea is that both the client and server can construct the signature independently and compare them, but prying eyes cannot. The key, secret and a time/token are needed so that requests to the same API resource (getScores) won’t always generate the same signature. It’s secure because the secret is… well… secret.
(There might be some of you that recognize this pattern. It’s basically the same model that Amazon Web Services uses.)
So that’s the basic idea. Here’s some resources to use if you want to implement it yourself:
Cheers! I hope someone can get some use out of this!
That’s my second LD. I was so tired and sleepless by reaching the compo deadline that I forgot to make a post about my entry. I made a kind of shooter, a ‘kind’ because you will control a small army of archers and catapults. All graphic was made from simply unity3d primitives. So here it is :
Defend Your Kingdom
You are in times when legends are reality, your medieval companions and yourself have to defend the realm from evil.
The earth cracked open and demons started to crawling to the surface.
You and group of knights you’re commanding are bounded to stop them.
Protect the kingdom from demons coming forth! Keep them beneath the surface so that no poor soul get devoured!
Hordes of demons trying to reach the surface:
Single catapult witch archer:
I appreciate any rates and comments!
Hi there! Daniel Snd here, the arts half of Infection Team. I’m so happy with all the positive response from the community about the game and the art of it that I’ve decided to write this more detailed postmortem on how I created everything in under 72 hours
After working on a few jams I picked up some tricks to work faster and get more assets out in less time, so I’ll be talking a bit more about those tricks. Also thinking of doing a few video tutorials on the creation of those kind of assets later.
So, in every Jam the first thing I create is the Character. It usually takes the longest out of all the assets so I like to get it out of the way first. I also try my best to be able to use the same rig and basic animations for all the characters in the game, as rigging and animation take a longer time.
I’ve created the basemesh out of an 8 sided cylinder, using another cylinder for it’s arms and extruding the legs out of each side of the cylinder. That gave me a quick lowpoly basemesh to work with, and make all my characters out of. For the main character I’ve included a little smile on his basemesh, and big round eyes, because it’s cute. The eyes are higher poly than the rest of the body (I really wanted them to be round haha). I took it to ZBrush to give it a more natural organic format (I like the Move Topological tool to move things around until they look right, wish maya had better sculpting tools.) then went on to UV the Character.
When doing art for Game Jams I usually try my best to make my UVs Mirrored, so both sides of the character are occupying the same space. That way I only have to paint half the character and the other half will already be painted as well, and I have to worry less about seams. As you can see on this picture, since all characters share the same Basemesh and the same UVs, it’s pretty easy to adapt the textures from one to the other, creating variation without spending much time. For extra enemy variation I also played with Hue & Saturation in each of the textures to have a bunch of color variations, with almost no extra developing time.
For the Big Fat guy with all the teeth I wanted to have a bit more detail (He would be bigger than the others in the game, with more health and slower, so I wanted him to stand out) I subdivided the basemesh and Pulled a lot of spikes out of his back with the extra topology.
With that basemesh ready to go, went on to pull it around creating enemy variations, you can see on the picture above how all of these are created from the same basic mesh. I took extra care to not move their arms and legs out of place. That way I was able to recycle the rig and the animations. I actually exported the Rig with all the meshes together animating at the same time, and let Sebastian just Tick on and Off the meshes he wanted for each character.
So with the rig working, I started to do the animations. Before getting involved with Game Design, I studied to be an Animator, so to me that’s one of the most fun parts to do and I love to experiment with it. For Game Jams there are also a few tricks I do to make the process quicker.
The first thing I do is creating a walk forward animation. There is a really great and detailed tutorial about creating walk cycles here. With the animation working, I’ll select all the frames of the copied animation, go into the Dope Sheet and scale them by -1. The animation will then be playing backwards. I’ll then select the COG controller, select the curve on the right rotation for the whole animation and drag it until the character is tilted backwards. With that I already have a Walk forward and walk backwards animation.
From there I make a new copy of the walk forward animation. This time I’ll pick the main controller (the controller that moves the WHOLE CHARACTER at once) and I’ll rotate it so he’ll almost face totally to the side. Then I’ll pick the COG controller, select the whole yaw rotation curve and drag it until the character is facing more to the front, while his legs are moving to the side. I’ll do that to the other spine controllers until he is doing a nice strafe. I’ll then do the same to the arms to make sure the weapon hand is still pointing forward and the other one is not crashing into the body.
And that’s how I take 1 walk-cycle and turn it into 4 walk cycles without having to re-do the whole thing.
Next thing I do is the Idle. The Idle is really important since most of the other animations should have it’s first pose being the idle pose, for better transitions. Usually for Game Jams I just keep the idle simple, using a moving hold with a few rotations on the spine to simulate breathing. After the Idle is done I’ll go on to do the Hurt animation, starting from the idle pose and finishing in the idle pose.
I’ll then Duplicate the hurt animation, delete the part where it ends back in the idle pose and make it end into a pose with the character on the ground dead. I’ll usually also add a little pop after falling for a nice extra detail. Lastly attack animations, starting from the idle and ending back on the idle. I usually do at least 2 so it doesn’t feel like only 1 attack.
With that, I finished the basic characters (It took from 8AM to 12:45PM according to my time lapse screenshots, so about 5 hours). I only made 3 characters at first, and made the other 3 in the last day when I realized I had some extra time for details.
Now it’s time to start creating the assets for the level.
Usually the first thing I do for a level is a floor texture. To speed up stuff, I didn’t want to proper painting with properly blended colors and gradients and all that stuff, so I decided to just try and do my textures with the Pen tool in Photoshop, Vector drawings! Started with the plain color, added some random shapes with a brighter color, then created smaller shapes inside those shapes with a even brighter color. Lastly I used a filter offset to check how well it was tiling, then fixed the tiling by changing some of the shapes, and added some shapes in darker color between the big shapes to make them pop out even more.
I did the same for pretty much all the other assets, with some assets getting an extra AO multiplier here and there for extra pretty shadowing just because.
After getting the floor done, it’s time for the walls. I started with a subdivided cube, deleted everything but the front and top. I then created the uvs for it and wrinkled it up taking EXTRA CARE for the vertices on the side to be in the same Y and Z position, so they would match. It’s also important to note that they were perfectly aligned to the grid. That way we can easily snap the walls together to create levels. In this case, we used an old procedural level generator script I wrote that does that job creating a level with the modular walls we feed it.
With the Half-wall done, UV’d and Wrinkled, I would mirror geometry so we would have a wall that’s front and back with it’s sides free. I did a couple of different variations of the wrinkled wall so they wouldn’t all look the same in the game, and look less like a modular piece and more like a regular wall.
Now that I have a proper wall, and it connects to other walls perfectly like a good modular wall should, I need some curved walls, so I can curve my levels, otherwise my level will end up being composed of all straight walls XD
For that, deformers in maya help me a lot. I can use the bend deformer to create a start for my curved wall (it won’t just magically be modular by just using the bend deformer, but it’ll give you a good place to start. From there I would position a wall on the adjacent grid from it and Snap the vertices so it matches that wall
From there I’ll usually put 4 Curved walls together to form a column. Columns are awesome to hide imperfections and to place in the middle of the map to create branched paths. One last thing is creating a more diagonal/less curved corner wall. So it can form straight walls in a diagonal pattern in the map. I would select the middle edge with a soft select making sure the vertices that I need to stay in place for the modularity of the asset stay untouched and punch it inside.
Now we have all the assets we need to get our levels being generated.
I imported those assets into Unity and brought with it my old Procedural Level Generator, that I created for another project, based off the C# example on this Cellular Automata Method for Generating Random Cave-like Levels on Rogue Basin.
In almost no time I had a LITERALLY INFINITE variety of interesting base level shapes for me to pick from and start decorating my level. Kept pressing the space bar until I saw a shape I liked, copied it over to a new level. Now I needed some nice decoration assets for it. At this point it was about 5pm of my first day (I started working 7am). So right now I’m 10 hours of work into the project.
At this point I’m thinking what the hell kind of decoration one would find inside the human body, first thing that came to mind are red blood cells and white blood cells. Created a red blood cell out of a cylinder (again using half uv for quicker textures, and same flat vectorial texture painting). In the interest of having more assets in less time created a variation of the red blood cell “damaged” by pushing one of it’s sides in. I also created a white blood cell out of a sphere, by using the SAME TEXTURE as the floor, but tiling it more and changing it’s color with photoshop’s Hue & Saturation tool.
Next I figured I could make some sort of vein-arteries thing and rig it, with that I was able to do a lot of asset variation just by contorting it into different positions. I shifted the UV to have one red and one blue in the same texture. Then I figured I could take it one step further and use other deformers to create more interesting assets with the same model in seconds. You can see there an example of using the Rig (Joints), Twist Deformer, Twist + Flare, Twist + Flare + Squash, and Twist + Flare + Bend. As you see we can combine several deformers for even more variation of results/assets.
So out of that one cylinder and a few deformers I created a whole bunch of different assets. For the grass I actually ended up cutting the bottom part of the cylinder and using only the tip, also edited the mesh a bit by merging some vertices.
From there I built a kind of Geiser thing (I have lots of those around the map with bubbles and goo popping out of) starting from a Red Blood Cell (It was there already and kinda had the upper topology I wanted so… why not?). I did have to Redo the UV for it though.
This one asset became SOOOO many others, using same UVs too. So I saved A LOT of time of doing UVs and Textures.
Cutting the bottom half it became the entrances for the enemies spawn and objective. With Bend Deformer, Flare Deformer and Squash Deformer it became a lot of Goo Cauldrons and Goo Droppers. With Inverted Flare Deformer and some extrusions it became a base Tower Body, from which applied Twist Deformer, Flare Deformer and Inverted Flare Deformer became 4 Tower Body Variations.
Closing it off at the bottom and adjusting the mesh it became a Tower Head. With sometimes mesh adjustment, sometimes Deformers, it became 8 tower head variations (Even though we only have 3 Towers in the game lol, talk about overdoing!) I made Body and Head separated to give Sebastian more freedom to choose how to mix and match those, and for it to be easier for him to make the head turning towards enemies without me having to rig the towers.
And lastly, From the tower heads I pulled a handle from the bottom and fitted some extra entrances in there for the guns.
I also made a rock of fat (or random gooey thing) and made variations out of it by using deformers/soft selection and by deleting the bottom and using only the top on the case of the smaller ones. The gooey light thingie is the same mesh as the white blood cell (pretty much a sphere with ends fixed so there is no star) but more squashed. I also put some Veins on top of the Floor texture and added some Alpha to it. I got the Fat Rock mesh and squashed it into the ground, and used it as a decal in several spots of the level, Sebastian later used it in the back of the Shop. Since I was in an alpha kinda mood. I made that green goo texture to put in a Quad with alpha. I barely used it, but it’s there somewhere.
And that’s pretty much every 3D Asset used in the levels. All of the other looks is Hue & Saturation adjustments and Color Balance in Photoshop to achieve different looks through colors. Since I was doing pretty well on time and I already had plenty of assets at this point, I decided to do some extra details and animate some assets.
I didn’t even properly rig those assets, just placed some random joints and animated them directly to the joints. Also some of the Arteries/Veins that are standing up have a little script that constantly rotates them, so it’s kinda like those barber shop things… It’s some really small details, and probably no one will notice them in the game, but they make me happy to look at, so I think it was worth it XD
So I set up the level, I populate it with nice decoration and send it to Sebastian. Once he gets the game working he sends it back to me and this is how it looks like:
So yeah… The assets are all in there… Why doesn’t it look good? Time to do some lighting! And change that camera, that camera is not cool D: Can’t see almost anything of all the cool assets! let’s show off those assets!
So at first I just changed the directional light a bit, it did look better than it was looking before, but I realized quick enough that it wouldn’t make much sense to have a sun inside the human body. I turned it down to get a more darker vibe and decided to fiddle around with point lights.
Now the thing with lighting, is IT HAS TO MAKE SENSE. You don’t just throw a point light in there and that’s it. You need a logical explanation for that light to be there. So I started to go through the assets in the scene that could be emitting light and positioning some point lights at them. The game instantly looked better. (Also helped that I found a better camera angle that showed the assets a little more). So I started positioning more and more of those assets that could be emitting light and filling the level with different colored point lights.
After it was all populated with cool lights,I started messing with some Unity Pro Post-processing effects, and I was pretty happy with the results. On this screenshot it looks slightly darker because it’s farther away, but you can see the whole scene in there. You can click the picture to see it in it’s full resolution.
Now we needed a Menu Scene and a Game Over Scene. We knew we wanted to make it outside the body, so it would be something completely different. Since the game is beneath the surface… we need at least to start outside! Even though it’s a completely different scene, I still manage to reuse some of the assets. The grass in the cemetery is the same “arteries/veins” grass that are inside the body. The tubes that connect to those bags are that first tube I rigged to create the veins/arteries. The thing that hangs the bags also come from that first rigged tube. The bags, bed, pillow, monitor and tray all come from a Subdivided Cube. The guy I did have to model it from scratch, I pulled up a cylinder and modeled his face. He doesn’t have a body at all, just a piece of shirt and that’s it. The sheet is a plane that I pulled the mesh around to cover him.
With all that done Sebastian asked if he could have some animation for those scenes, so I dropped some joints in there and animated directly without properly rigging, since it’s not much motion.
Now we had 3 hours until the end of the jam, and I was pretty much free, the only heavy workload was with Sebastian since there was still a lot of bugs to squash and new features to add. So we decided it would be a good idea for me to work on a Second level.
I started by doing some Hue & Saturation changes on the walls and floor, and found a cool blueish/purpleish point that looked good in the level generator. We wanted this level to be bigger, and have 2 opposite enemy spawn points, for extra difficulty.
Sent him this quick painting over the generated level and he liked the shape so I started working on it.
Since I had the first level already with all those cool pieces put together I just copied it over, moved it to the right of the level, deleted all the walls and floor to leave only the decoration. Then I started pulling pieces out of there and placing them in the level, it went by WAAAAY quicker than doing it for the first time. But of course I also added some new combinations of things to make things more interesting. The result is that the level 2 looks even better than level 1 (at least to me). Which is a funny thing, because when you see how good the level 1 looks, you might think it’ll just look the same from there on, but you get to level 2 and it looks so different, and better! So it’s a cool little surprise for the people who make it this far
And that’s it, that’s how the art for this game was made Sorry for all this text, and all the heavy images. I thought this would be some nice/fun information to share.
If you would like to know more be sure to check Sebastian’s Behind the Scenes video.
Also there are my Art Creation Timelapses where you can see me actually doing everything I talked about here:
https://www.youtube.com/watch?v=zdEAC3X4zN8 https://www.youtube.com/watch?v=xBYieapEfgQ https://www.youtube.com/watch?v=UQDtm_DiAjU
And of course, if you haven’t already, please play Infection \o
First of all, here is our entry: check it out
This was our first time entering Ludum Dare. We are a team of two and we have one released game so far. One of the problems we had when we made our first game was planning. So we thought the Ludum Dare Jam was a good place to test and refine our planning abilities.
- As I said, our goal was to see if we are able to think of an idea and then finish it within the time limit. We succeeded at that! At this point everything else is just a bonus!
- The idea. I think we have a good concept here. What we basically did was replace the A B C choices in dialogue trees with a minigame and we think it’s an exciting idea. (and we believe we can take to many directions in the future)
- The production values. Admittedly, we did pull characters from Lost Echo and most of the music was from bits and pieces I had already written in the past, but it still surprised us how much we were able to produce in the 3 days. I also really like the splitscreen we did.
What Sort of Worked
- The physics. It was the first time we worked with Unity’s physics. I realise it’s a Ludum Dare sin to use things you are completely unfamiliar with, but we managed to pull something usable out of it. But at the same time, the block and push moves are completely unreliable.
What didn’t Work
- The level design. The 4 stages in the game are, well, very basic. That’s not exactly bad, we were going for more of a proof of concept game here, so the stages being barebones is fine. But at one point, we realised the gameplay would feel better if we allowed the player to move while he was attacking, or he had a bit of a faster walk speed, but we didn’t do any of that, because the stages were pretty basic and the game would have been way too easy.
- The story. Well… There isn’t much of it. And what’s there is pretty basic. Which is fine, but it felt really cheesy when we tried to make somewhat “moody” endings, that had little to no build-up. In the end, it works as a proof of concept, but that’s all.
Regardless of what kind of ranks we get (although I have to say, the comments we are getting are generally positive and we are really happy about that!), our first Ludum Dare was a success for us. We also have a concept in our hands now that we like. There were a ton of ideas we had during development that we immediately scrapped because of lack of time. Hopefully we’ll be able to revisit the concept and make a complete game out of it.
Thank you all. This Ludum Dare has been amazing.