Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!
Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created. You NEED ratings to get a score at the end. Play and Rate games to help others find your game. We’ll be announcing Ludum Dare 36’s August date alongside the results.
New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.
Will be on a fligh back from the US to germany on Friday and was hoping to use the flight-time for good. Only problem will be that the theme should not be anounce before I board my plane from Washington to Munich… lets hope for a delay
This sunday I was finally again able to do some work on Boskovice (my initial October Challenge; now November Challenge game). I mainly worked on performance topics, enemy AI some new entities and game content. This includes different door types, collectables like health, ammo, coins and diamonds for score (be honest: who does not like to collect coins? ;-)), fire, explosions, barrels that can explode or inflict pain and glass walls.
I noticed quiet quickly that creating pixel art for complex enemies with movement/walking animations is quiet time-consuming, so I mainly tried to add some more static content for the beginning. I really like how the explosions and fire turned out. Check this latest video go get a feel for the progress so far.
In the next days I hopefully will be able to actually create some levels for the first episode of the game. Up to now, I am still working in my demo-level that basically contains all content that is there at the moment.
As I was not able to participate in the October Challenge from the beginning of the month, I started the November challenge for myself: I want Boskovice to be ready at the end of this month. And due to a long weekend in germany it is not looking to bad. Check out the the latest gameplay video directly on an android phone (performance is great on the Samsung Galaxy S3; still have to test with older models). Quality/lighting of the video is quiet poor, but it might give a basic idea where I am heading: Retro-style FPS ala Wolfenstein 3D.
I have been putting in some hours of this week’s vacation to work on my October Challenge entry but finally have to admit that one week just is not enough. I will continue to work on Boskovice for the next month, hopefully will be able to keep motivated and maybe at the end of the year have some version ready to put in the android play-store.
Overall Summary: This has been my first time tinkering with the android platform and I have to say that I am impressed with the hardware and software-side. I started with my Ludum Dare 24 entry, which was using raycasting-based software rendering. After porting it easily to android (its java), I noticed that this approach is not working on a mobile device: software rendering is too slow. I started from the ground up with libgdx and reimplemented the graphics in OpenGL ES 2. As libgdx allows you to build for android and the desktop, I was able to use all the advantages of developing on the desktop. Including the goodness of hot-code-replacement. Only to test the touch-input, some shader differences in OpenGL ES compared to desktop OpenGL and test performance, I had to use the android phone at some points. And it is rather impressive that I almost ran out of the box with 60 frames per second on the Samsung S3. It is a new device, but anyway. Oh, and I had to reimplement the raycaster** as this was the main bottle-neck draining the CPU. Turned out that i was doing a little to much floating-point calculates and my math was much more complicated than it needed to be.
The game is still missing alot; physics, particle system, content, content and content.
** Note that the raycaster now is only beeing used to calculate the set of visible tiles and walls, the actual rendering is now done via OpenGL.
I am entering the October Challenge. Better late then never. One week of vacation should give me enough focus to complete something that is publishable, I hope. I am planing to port my LD24 entry to the android platform as I have been getting my first company smartphone lately and would like to tinker with it anyway.
As my LD24 entry was using only plane Java JDK APIs and pushing every pixel to the screen manually (a raycasting-based software renderer) there was suprisingly no big effort to get the code running on my Galaxy S3. Only the speed was really bad due to not leveraging the GPU in any way. 5 fps made it clear that even some optimization would not get me to a smooth 60 fps easily. So, I am planning to reuse the general game-idea and architecture to build a simple 3D game using OpenGL ES 2.0. I am not sure if the theme will keep the same, but I am planing on mainly tinkering with some lighting, shadowing and physics. Whatever theme will make good use of the technical things I come up with will be fine. Learning something new is still the focus; earning money is only secondary for now.
Main tools will be as usual eclipse, Java. MS.Paint and Bfxr. Additonally, I will put libGDX for rapid development on the desktop and iNudge for some music into the mix for the first time.
This was the first time ever for me to successfully complete a Ludum Dare. I have tried 4 times before, but never was able to finish. The reasons varied from other real-life distractions and no good ideas to simple exhaustion. And also this time it felt the whole time like I will not be able to finish it or submit something really bad not even close to the theme. But with a week now to look back, I have to say that I am pretty happy with the result. The story and the feel to the game is more then I could have expected to develop in about 35 hours (including breaks but not the sleep).
Already a few days before the LD I decided to go with a ray-casting-based 3D game in a Wolfenstein-like fashion if I would somehow get the game to match the theme in some way. So, I briefly read an article on ray-casting to get the idea and the math straight …at least in theory. Also, I wanted to do 3D but the problem is that you can easily get caught in the art-trap: doing highly polished graphics that take up a lot of time. That’s why I love pixel-art: It has a great visual style but (depending on the resolution) requires not so much effort. Well, that sounds wrong; great pixel art takes a lot of time but you know what I mean: You can have a visually pleasant game with rather simple and fast pixel art. Would I have used OpenGL, you often get lost in detail because you can display a lot of detail (one of the previous failed attempts made me realize this).
Result of day one: basics renderer including texturing are working.
Come the announcement of the theme, I was sure that I made the wrong bet because I could not immediatly think of a good gameplay idea. I decided to proceed with implementing the raycasting-based renderer and postpone this problem to a later point in time. This lead to me spending basically 1.5 days of the time on implementing the renderer; i.e. rendering perspectively correct walls and sprites, getting the math straight and implementing all edge-cases. I was sure that I would not be able to finish this time. Espacially because thinking straight and doing the math got hard after one day and I struggled a long time to get the textureing and sprite-rendering right. And I also discovered a bugs that got my rendering spiral out of control once I went out of the defined bounds of the world. But I learned a lot from these two things:
Result of day 1.5: Everything is almost finished (main-menu, story, weapon animation, level, sound) except the sprite-rendering
Having to tackle a “hard” problem (it was hard for me at that point) actually made me get frustrated and push the problem aside a lot of times. I did not get the sprite rendering done before 4-5 hours in to the end of the compo. This lead to the situation that I was doing everything game-related that I usually have the least fun with: doing menus, sound, story, optimizing the mechanics, nice graphical gimmicks. In the end: improving the overall atmosphere of the game. I did all of this in quiet fast succession. In between I always tried to tackle the hard problem but failed or was not motivated to do it. So, 4 hours to the deadline I have a “polished” game that was only missing one core element: the enemies; because I had trouble getting the sprite rendering right. Then I got back to the problem and was so motivated to get this finally done because it was the only thing left for me to release an actually pleasant game for a 48h compo. And I finally cracked it.
I realized that you sometimes get blinded by problems that are no actual problems you need to care about. As said, the rendering went haywire once I exited the bounds of the game world. Some trigonometry where I though there is a symmetry or math itself takes care of it but actually wasn’t. After struggling with it for an hour I came to the realization that the player will never be exiting the game world. Why would he? Per definition he keeps in the game world. So, I just implemented the checking that the player cannot run past the bounds of the world and everything was fine. This is not the solution that makes the math-addict in me happy because I know there is some wrong thinking in my calculations but for all practical purposes it does not matter.
Game development is almost over; the sprites animations of the blobs are finally rendered correctly.
So, actually everything went good in the end. Also the story was ok and somewhat in line with the theme. I guess you can always push a shooter in the direction of a theme if you want but I was not happy at first with going this easy road. But as I did not have any good gameplay ideas, I got pragmatic and am quiet happy now that I did. Otherwise, it would have been another failed LD with the excuse of having no good ideas.
Once the sprite-rendering was working, the low-resolution art style again came to my rescue: the blob with it’s two animation frames was done in zero time and I could focus on improving the feel of the gameplay. What sounds are played when the blob get’s hit? How many times do I have to hit the blob? When is it getting to hard/easy? How many blobs and where are they located in the level?
I actually did not spend too much time on this questions because there was still one final thing that I never did before (due to always dropping out) but actually turned out easy: Actually releasing the game. A quick question in the IRC revealed that most people use dropbox to host the download, so I went with that too. Especially because you can also host a static website (which I did not know). So, packaging the game as a Java applet to run in the browser should be an easy task in theory… Also in practice: I never before developed a Java Applet (maybe once in a Java course at university) but was hoping that it would be easy as my game was based on AWT as the window system. And I was not going to be disappointed: Embedding the game-frame within a JApplet and done. It was so easy, I was impressed. While doing this I actually lost track of time and noticed while writing my final progress post that I was minutes away from the deadline. I guess it was because I really wanted to package the game as a web-version to make it as easy as possible for everyone to try it. No download and bad feeling to start some random executable on your local system. (Side note: I still don’t understand why not more people make this a higher priority in the choice of their dev tools/language. The exposure of the game gets so much better.)
Looking back, I am happy to have finished the compo with a game I feel is not too bad for 48 hours and me knowing that I can do this; there is no excuse anymore to drop out of future LDs.
I am feeling exhausted and happy all at once. My first successfull LD entry. I finally managed to solve my sprite bug and was able to submit a small game that is using the raycasting-based software renderer that I have been spending most of the time on. I am not happy with the gameplay of the game; it is just a small and shooter without any special mechanics. What I am very happy with, is the art still. I really like low-res games.
That’s it for me and good luck to anybody still spending the last minutes to polish the game. Post Mortem and timelapse will come somewhere next week I guess once I had some time to reflect.
Progress has not been like expected. I guess I did not have enough sleep; because I always have to push the sprite-rendering; just can’t focus. At least I have some artwork, sounds, the menu and even some minimal dynamic lighting for the the weapon-fire ready. Only the enemies are still missing…
I’m at the brink of dropping out. Let’s see what a break will do for me…
Oh; please note the moon: After hearing the sad news of Neil Armstrong’s passing, there was no other option then paying proper respects.
Day 1 with 19 hours of coding (including some breaks in between) is coming to an end. As usual, I did not progress as far as I would have liked, but it is definitely better than in previous LDs; at least technology-wise. Even though I did not prepare anything, I was able to build a full raycasting-based software renderer on this day. I wanted to replicated the feel and art-style of a Wolfenstein 3D-like game. The idea was/is that this will allow even fairly limited pixel-art to look nice and retro. So, more time coding, less time spent in Paint.NET. And I like the idea of pushing each pixel on the screen myself and having full control. I have already discovered some nice visual effects by accident.
The software renderer was actually the main thing I was working on today and I had some occasion of thinking to drop out. The simple case of rendering one quadrant of the the map correctly was done after a few hours. The funny part started with the edge cases and making the code work for all four quadrants of the players facing direction.
I actually had looked up a tutorial about raycasting before the LD, but did not use it extensively. I wanted to judge my understanding of the problem and I am quiet happy with how it turned out. Especially, I am surprise how fast the implementation is running (>1200 frames per seconds) considering that I did not do any optimization and bit-shifting tricks. It is all floating-point operations which is slower in general, but helps the understanding of the code.
Even though the attached screenshot looks fine, I still have some glitch in the texture-mapping for the walls. This will be the first thing to get fixed tomorrow morning. As it is quiet late already I rather spent the time on some art and the bitmap font. I noticed hours ago that bug-free coding is not happening anymore today…
What else? I did not spent much time to think about the actual game mechanics and story, yet. I hope something will pop up over night; if not, it will become a standard shoot-em up.
What’s on the agenda for tomorrow? A lot:
– Soundtrack and game sounds
– Artwork: textures, sprites
– Speaking about sprites: The renderer still needs support for the character sprites. But it should be “easily” possible to reuse the wall-code for that purpose.
– Enemies and Game mechanics: Still not sure about the actual goal of the game, so not sure what the enemies/characters will do. A theme like “Evolution” actually dictates to build something heavily AI-focus. But, I haven’t been doing AI since university and I don’t want to open up another can of worms in the last hours I have left.
– Menu system and Highscore board; I like Highscore boards
– If i have lots and lots of time, I would like to extend the renderer to also support textured floors. Up to now, it just a color-filled rectangle at the bottom half of the screen, simulating the floor.
Oh yeah: As I was spending the last hours on art-work, the logo for the game is done. You see it on the screenshot. I don’t have time to waste on redoing the logo, so
“Shit! It’s Evolving” it is. No idea yet “what” is evolving, though…
Some random walls and a textured block. Doesn’t look that fancy for 19 hours of work…
I go inspired by the (actually failed) SpaceX launch on Saturday and wanted to make the game around a rocket-flight. The art was quiet quick to do, but then I got stuck regarding the goal of the game. Steering the rocket seemed not very interesting. Especially, because rotating the rocket slightly on a resolution of 18*64 lead to obvious aliasing problems. So, the only obvious possibility to me was making it about shifting the rocket left to right. Not very interesting… In the light of no obvious ideas for a good game-goal, I decided to drop out.
Was fun and the theme is actually quiet inspiring but I have to drop out. After 10 hours of coding I did not make the progress I anticipated. And as I only wanted to spend one day, I already now know that I cannot pull this off until the day is over. Have to get back to my MITx course.
For whoever reads it: I wish you a successful second day of the LD and may the reward be a great game!
Currently MITx’s Electrical Engineering Online course264 is taking up most of my freetime and the midterm is also next week. So, I might not be in for the full duration. One full day is planned. Everything more will be decided on short notice based on how much I can work ahead for the course in this week.
I will be joining with a minimalist toolchest: Java (plus Eclipse IDE), MS Paint and bfxr for sounds.