Posts Tagged ‘progress’
Hi all, just an update about #speccyjam; Many more games were started but in the end 22 games were submitted
The developers and myself would love for you to go and play the games, and also share them / Like them / Tweet them / and comment on them (each game has its own Facebook comment section)
You can check them out here:
Hi lovely LD game-makers! You may remember me from my last 4 LDs, I’m the gal who worked on Kumiho, Trina and Legend of Troll.
Well, in my day job I’m an illustrator/animator, and this is a game I’ve been working on for a year and a half.
It’s going to be a kick-ass casual strategy game for iOS, Android and PC.
We are launching a kickstarter campaign this week, to fund its completion, since it’s about 60% done.
I’d greatly appreciate it if you could like our facebook page or follow us on twitter, and/or donate to our kickstarter. You’ll find the link on facebook and twitter as soon as we launch the campaign (within the week)
Show us some love! Oh, and get ready for a video of myself wielding a lightsaber… The shame!
Shameless promotion over
I’ve said it again: I love LD and want to keep doing it till I die.
So, recently I got bored and got an idea of creating a new game. First idea: MMO. Then “well, I’ll need to write both server and client and deal with networking stuff”. Goes out.
Second idea: make something small. And, after an hour here’s it:
HP and MP are hardcoded and unchangable, but hey, that’s alpha
Then decided to move forward. Already got mapping stuff (currently hardcoded table of integers, to be replaced with files), working walls (with deleted ghost-mode :] ) and with some nice green grass. Doesn’t it look beautiful?
Hey, this is my first game without using Game Maker or any other stuff, don’t blame me
It’s confirmed to be working on Debian, Cygwin and WinXP. Tested it through SSH on my phone, too :
If you feel interested, have a look into sources hosted on my GitHub. You’re welcome to drop your hates below, too!
PS: Maybe it’ll go for next 48h, who knows..
So we finished our Second Ludum Dare! It feels great
Boy was this one FRUSTRATING
But we learned SO much……
-POST – MORTEM-
First the things that went WRONG
-1. LIMIT THE AMOUNT OF BETA SOFTWARE USED-
Heres the first thing I did wrong. I am running on a OS 10.9 beta. I am writing my code in Xcode 5 beta
Besides all of the crashing, one night I hit a total dead end bug in Xcode where I could not distribute my app. I almost QUIT the dare.
-2. MAKE SURE IF YOUR STREAMING/TIME LAPSING THAT ITS SET UP AND WORKING BEFORE THE JAM-
I spent too long trying to make sure my stream was exactly the right way, plus because of rule 1, it kept crashing, total productivity bust
-3. PREPARE YOUR TOOLS/CODE BASE/LIBRARIES BEFORE THE JAM-
This jam I switched over to SDL for the first time. I hit so many little snags that were simply because SDL works different, a number of times my productivity stopped was because SDL would be handling Floats as Integers, and leaking memory when it renders text, or flat out dropping sound because of an extra curly bracket.
Things that went RIGHT!
-1. Work with friends-
Luckily I had the support from two close friends of mine. Both of which worked with me in the previous jam, but had dedicated time this jam to help. Having three people working on the game felt nearly perfect. The conversations were always motivating and productive. Also having two other people critique your code/sound/music/art is always great. A number of times Id find myself implementing something , and because of lack of sleep/reality/food one of my friends would remind me that what I did looks or sounds RIDICULOUS
-2.Have a Plan-
My friends and I prepared better for this jam. Last jam we did not realize the theme was announced so soon, so we scrambled after work to get together. Not this time, we were together as soon as the theme was announced and spent a good 3 hours whipping up ideas. I have a HUMONGOUS white board that worked so well in capturing and reducing our ideas to the very best ones. We could then get down to work, and glance at the checklist of things we needed to do on the whiteboard.
-3. Share often -
Try to have people test your game as soon as you can, some of the weird little things you know about the games rules or how it plays may not be apparent to others. You have to develop a sense of “communication” to your player , and there is no better way than to see how another player plays your game.
Overall, I feel extremely accomplished having finished a second dare. This time the pieces fell together much better than before. We had the idea down the first night, then got cranking the next two days. My friends and I discovered new talents and developed some since the previous jam. We look forward to finding out when the next jam is, and now I can’t wait to try some of your games!
—Don’t forget to try our game FSCK! Bit needs your help!—-
It looked real bad for a moment, we didn’t implement all the features we wanted, but we made a game! A game that’s actually kinda fun to play, and at least made us laugh (YMMV, we have a terrible sense of humor).
Great jam, congrats to everyone who managed to make it in time, stiff upper lip to those who didn’t; don’t give up, there’s always next time!
Yay for game development <3
Ludum Dare 27 has been my first ever Ludum Dare competition.
I was not sure of what was going to happen, if I were capable of finishing a game in under 48 hours, if I would have felt stressed or relaxed, et cetera.
For the competition, I decided to use C++11, SFML, and my own framework, SSV, which is free, open-source, and always looking for contributions/critique.
My development environment was Arch Linux x64, using QTCreator as my IDE, and Sublime Text 3 as my text editor.
The development machine uses an Intel Core i7 processor, NVidia GTX275 and 10GB of DDR3 RAM.
My goal was producing a game that was worth playing in under 48 hours, with native Win32 and native GNU/Linux x86 binaries.
I’m very happy to have reached that goal, and I’d like to share my thoughts about the whole development process.
I worked on the game for about 30-32 hours. I slept, worked on a video for a friend’s birthday, and relaxed for 1-2 hours (played some Spelunky and browsed the internet).
The first thing that surprised me is that I felt constantly stressed. I do not know if everyone feels like this, but I couldn’t stop thinking about the deadline, about the end result.
I have to say that, as far as personal feelings go, I didn’t dislike the 48-hour deadline development process, but I didn’t find it fun either.
However, after finishing, I felt a great sense of satisfaction and reward, which kind of made up for the stressful coding hours.
The second thing that surprised me is that my framework, the SSV framework, was up for the task of creating a game from scratch.
It literally took less than an hour to get a prototype where I could walk around.
A big effort in SSV was put into development of SSVSCollision, a header-only pseudo-physics library intended for retro-style games.
It handles collisions very differently from all other engines out there, and, while not suitable for realistic physics simulations, it is great for retro-style games, where physical bodies do not interact much with each other, but have infinite stability and very precise collision resolution. Here’s a video of it’s performance.
It also lacks all sort of issues that would arise with a realistic physics engine, such as the common error where bodies get stuck between tiles in tile-based worlds.
Anyway, I also created a player sprite, which I had to divide in two parts (arms and body) to avoid repeating unnecessary frames. I used Pinta for the task, a Paint.NET clone for GNU/Linux.
I’m not an artist, and that is obvious by looking at the poor end result of the player sprite. I used the same tool to create all other graphics in-game.
I dealt with sounds by using sfxr, the free, open-source sound generator advertised on the LD website itself.
For music, I used LMMS, a GNU/Linux production software with an UI similar to Fruity Loops. I’m not a musician either, so the end result was poor here too.
The game concept was actually created after the prototype version. I had no idea what I was going to make. I just made stuff and tested stuff.
Then I had the idea of this cool throwing mechanic, where suddenly turning your character would increase the force of the throw.
This is where stuff started getting interesting. I had to deal with my peculiar physics engine in order to allow the player to grab/throw/release blocks.
It went pretty smoothly.
This is what the first grabbing prototype looked like. I also had added the number on the crates but had no idea how to use those yet.
I also had no idea how to use the crates yet.
Then I combined the throwing concept/mechanic with a time-based constraint (10 seconds theme), and had the idea to make the game into a reflex-based, time-based puzzle platformer.
I designed some game elements and threw some test levels together. But I didn’t have time to create a level editor, or to write a JSON level specification. So what did I do?
Tab based in-code level editing. Dear god.
Yep, I used tabs, newlines and spacing to re-create the structure of the level in the IDE itself, so that I could have a rough idea of where I was placing elements.
After making some levels, I created a menu screen, which was very easy thanks to the SSVMenuSystem module of the SSV framework. And that’s pretty much it.
There is a problem with level 5, which is almost impossible because I forgot a game element. But it is actually possible, even if insanely hard.
I’ll judge the game myself, now:
Innovation: I’d say the game is not unoriginal. The turn-based/jump-based throwing mechanic is pretty fun to use, and the game elements, while simple on their own, can be combined to create some interesting puzzles.
Fun: This is a very subjective point. The game is not easy, and can be very frustrating at times. Honestly, I find hardcore games pretty fun – I enjoyed playing my game, even if trying the fifth level for one-hundred times got frustrating quickly.
Theme: My interpretation of the theme is not very original, but I think the 10-seconds constraint that resets works well here.
Graphics: I’m not an artist, and it really shows. The sprites are of poor quality. I tried to redeem myself by creating variations of tiles that appear randomly and maintaining a simple flat look for the game.
Audio: Sfxr is a godsend. I love retro sound effects, and they work well here, I think. Music, on the other hand, is not catchy or memorable, and it’s just a simple loop. It was my first time ever producing music. Here I tried to redeem myself by adding a no-sound and a no-music option to the main menu.
Mood: I tried to create a simple story/world around the game. Basically, you’re working for this company, 10corp, in a futuristic (I guess) setting where getting a job is very hard. In order to survive, you have to work for this company, even if they terminate slow workers to maximize their profits. I used in-game messages (broadcasts from 10corp) to give the feeling of the player being observed and judged during its tasks.
Overall: Overall, I am satisfied with the end result. I’m still not sure if the game is worth improving, but as a less-than-48-hour product, I’m happy with how it came out.
I really hope you enjoyed my entry and this postmortem. Thanks for reading!
We’ve made some real good progress the whole time, but this far the game has been pretty… well, boring to look at. Now we’re finally making some progress with the visuals, so here’s a screenshot of the title screen. We’ll try to get some more updates leading up to the deadline, but we tend to cut it kind of close with deadlines, so we might not have the time
We took a bit of a cop-out, and made 10 second minigame-marathon, but the game is fun to play, and feels nice and hectic <3
I just finished my LD27 entry!!! It’s called Defense of the Zorion! You have to defend your ship from enemies by using first person shooting and strategic turret placement!! You have 10 seconds for each wave and between waves you have to run back and forth to unlock more turrets and weapons!!! I also included a ton of Easter Eggs and references to my previous LD’s
You can play the game HERE:
Happy gaming!!! I will write more later!!!
In case you were wondering, we are doing pretty good with our schedule. We have some enemies chasing you, a good amount of the animations already in the game and some cool visual effects.
But wait… What is Antarctic Glitch?
Antarctic Glitch is a game about a bearded doc, evil government agents and parallel worlds.
A bearded doc?
And what about the “10 seconds” theme?
Be ready for an infinite brawler packed with action, lots of characters and a compelling story!
My game is fully playable and, so far as I can see right now, bug free! As you can see in this screenshot, though, I need to put the scoring into the game itself – right now it just shows up in the console. Also still like to redo my temp art… there might be time for it. Also more sounds? That’s low priority. Probably won’t happen.
First, the team:
- cybek, main programmer and BabyMetal listener (he wanted to add that)
- me, everything else (partial programming, awful graphics~ )
Second, the game – simple top-down shooter. After entering the building, you have 10 seconds to destroy the target. If you fail to do so, after another 10 seconds new enemies will spawn, making your retreat more difficult. If you manage to destroy target, walking around will be easier.
Third, story – player’s character, unnamed girl, was asked to buy tomatoes. A lot happened and now she is fighting some kind of evil organisation (SERN or anything you want it to be). Whole story told by black-and-white images.
Fourth, word from main programmer: “BabyMetal”.
It’s getting late here, so good luck to compo’ers and good night to everyone else~
Play this while looking at the GIF: http://dragonlab.de/projects/ld27/Song%20Ingame%20v2.mp3
(Made with Abudant Music. That thing is incredible.)
It’s been a long, busy day, but we’ve made lots of progress! The fact that I’m just now getting around to writing our Day 2 summary well into Day 3 speaks volumes about our efforts.
Our main goal for today (yesterday) was to get a basic Alpha build up and running; all of the core gameplay elements without any of the bells and whistles. I’m happy to report that we were able to get that and then some.
Most of the gameplay takes place at the entrance to a creepy house in the middle of the night. In order to create a more immersive experience, the game takes place in first person. We wanted to use depth and perspective to help establish a sense of place in the scene, but none of us are actually 3D artists. We came up with the idea to just use a set of 2D assets, a bit of parallax, and a couple of simple textured cube mesh doors to achieve a somewhat pseudo 3D effect. I think what we came up with looks pretty nice!
In addition to the art assets, we have a nice suite of really creepy ambient and effect sounds ready to go. Our plan is to play around with 3D positioning of the sounds that play so that you feel like you’re really in the middle of a tense situation. We may have to add a splash screen after the title card that recommends using headphones!
After knocking out our core gameplay, we finally got to work on fleshing out the storyboards for our ending sequences. If we’re able to do all of the work we have planned, there will be six different endings. The ending the player gets is determined by their performance and we’re hoping to have some really interesting sequences play out. Currently, this is our top pick for points to expand on. If we have some extra time at the end of the project (yeah, right) we’ll probably put some time into a few extra endings.
Sunday will be mostly about trying to wrap things up. Our biggest tasks will be getting the ambient sound placement working, and implementing our ending sequences. If all goes well, we may even have the game submitted at the end of the night for everyone to play! For now, we’re all gonna crash so we can get up in a couple of hours and do it all over again… Almost there!
Here are some screenshots from my game. The goal is to exit the room as fast as possible – 10 seconds. It would be easy, but you are left in the dark with only few toys to help you find your way out.
Lights demo (45 lights)
And here is actual gameplay. Left is release version, right is debug window.
So I ended up going to sleep at 4-ish last night and not getting back to work until 9-ish. Just over 10 hours remaining now, and there’s a lot of code left to write. On the down side, the way I code takes a while to get to a point where it’s possible to really test or see much of anything. On the up side, once I get to that point, things can come together really quickly! Hooray robustness!
In the past half-hour or so I’ve finally hit that point! My parts draw on the screen, and I’ve got about half of the user input handled. Now all that’s left to implement is the actual game rules for how to attach rocket parts, and then to figure out how to score the game. I’ll also need some way to display the final score, which will be a burden since I haven’t prepared anything for that. That comes last though. Play first, scoreboard last.
Here’s a screenshot of my game with the timer going and my lovely programmer art properly rendering to the screen. What you can’t tell from this is that I’ve also added a few basic sound effects! Yay for that!
My game is a working thing with a beginning, a middle, and an end. It needs balance and a score display and a way to reset when you lose. It will have at least two of these things by submission time. :/ But right now? Right now, I am following my coding brain into that great purple abyss we call dreaming.
P.S. — Oh, #!@&… What am I naming it?!
I (Aapo, the creepy scarlet-haired programmer dude) woke up about 90 minutes ago and sat down to write some code. I got some good things done, and will probably get some breakfast before I continue. We’ve made a lot of progress in the last 24 hours. We fleshed out the idea we’re going with, Alvar has already done some real nice graphics work. Ville is (I believe) almost finished with a really awesome tune, and I’ve got the gist of the core gameplay nailed down. Stream still going strong, although before Alvar arrives, the webcam will mostly be off the empty livign room
Anyway. Good job everyone, keep at it!
To the compo-heroes: KEEP AT IT, FINAL STRETCH.
To our fellow jamians: Halfway point coming up, gut check time!
Yay for gamedevelopment <3
Hello there fellow programmers!
My idea is “10 seconds to die”. You have 10 seconds to die and the game won’t let you die too easy. You will have to collect coins (and skip medpacks and the girl) to pay the ninja to let him kill you. Each coin gives you 1 more second and the clock stops the time for 2 seconds.
The progress is better than expected (good thing) but I won’t add all the things I wanted to add (bad thing) Anyway, I think the gameplay is pretty solid (and hopefully funny)
Of course, it isn’t finished yet, I need to work more on it (add sound, more levels, etc)
Plan is to provide several mechanics that will be randomly selected for the player to complete. Providing a basic of 5 mechanics, and escalate the difficulty via procedural. Each mechanic can only be completed for 10 seconds, and once completed will advance to the next randomly selected mechanic with a higher level of difficulty.
For example, there are mechanics A to E. The player enters the game and system randomly chooses a sequence of challenges, let’s say 10 with a sequence of mechanics: A-D-C-B-E-D-E-C-A-B. The first challenge will be level 1 with mechanic A, while the 9th challenge will be the same mechanic but on level 9 (more difficult).
I’ve finalized the list of mechanics available in game, which are:
- Frogger-like mechanic. Riding hood need to get to the other side. Small streams filled with piranhas lurking to shred Riding Hood if wrongly jumps to the streams. Luckily there are logs floating about, with varying speeds. Player can only touch to make Riding Hood jump. Jumping to a log will make her continue, otherwise if she falls to the water or time ends, game over.
- Riding Hood moves automatically left to right and needs to survive rolling boulders. Player can only touch to stop Riding Hood temporarily. Each stop switches directions (from left to right, vice-versa).
- Defend the basket from hoards of bears. Riding Hood stands to defend her basket for Grandma. The only way to defeat the hoarding bears is to throw food at them. Player touch + drag Riding Hood to set direction and throwing distance. Similar to AngryBirds but from top view. Bears that encounters food will return back home.
- Sneak up past patrolling owls. Similar to mechanic #2, but this time Player touch to move Riding Hood upward, and release to stop. Owls move from left to right, with a range of view extending the owl sprite.
- Climb up a hollow tree. Riding Hood only moves from left to right, and Player touch makes Riding Hood jump. Inside the hollow tree are ‘platforms’ for Riding Hood to jump to the top of the tree.
Currently 3 working prototypes of the 5 mechanics are done. I feel this are still so many to do, with less time, since I’m juggling through family time as well (bad Daddy ). I might pull an all-nighter tonight .
Here’s a screenshot of mechanic #1: