Hi,

I’ve just created an upgraded version of my LD entry.

I’ve added drills, mines, best scores, better Android controls, and infinite digging.

Have a look on the play store: Diggity

Whats on the dark side of the moon?

Back in LudumDare #27 (10 seconds), Mission Luna was my entry and it surprisingly got some reviews on media and some players asking about post compo version. So, here is the first preview from new version gameplay where (finally) moon landing is implemented along with new graphics, models, ship upgrades and a sure cliche alien plot.

My first game has just landed on google play. The game is made in a style of the 80s, it is linked to the games like:
– Donkey Kong
– Pac Man
– Popeye

The joystick can be placed wherether you want to in the game, just for your own comfort.
Free Lily link

Hey all!

I have finally decided to start a weekly-ish blog, and I have started it off with a post about Forerunner. Please check it out, and let me know if you have any further feedback!

Hi! I’m Max.  I collaborated with @petey123567 on DIGHARD for LD29, and it felt so good I’ve decided to keep the ball rolling and go in for MiniLD51.

In general I’ve been developing with Unity, but it’s been kind of love-hate.  I love the content management, but the programming interface is a bit of a minefield (e.g. did you know that .transform is just an alias for .GetComponent<Transform>(), and it’s nontrivially expensive to call a whole bunch every frame? Ew!).  So I’ve been wanting to transition to SDL2, but first I need a better content solution, since SDL2 doesn’t have one, and some higher level rendering primitives than OpenGL.

Enter the Little Polygon Toolchain.

Firstly, there’s a pile of python scripts for plotting sprite and font-glyph atlases, parsing tilemaps, compressing audio and userdata, and exporting everything to a fast native format with a pointer-fixup table that load quickly with plain SDL IO and no fat third-party libraries.

Secondly, there’s efficient Sprite and Spline batchers for using the assets and a GameJam-friendly context-setup-and-teardown object, as well as other handy utilities.  I’m even playing around with Mono bindings for doing mixed C++/C# development and opening builds to end-user modding.

Making tech is fun, but collaborating is even more fun, so I’m totally game to help if you’d like to use this for your project or help me turn this into a proper shrink-wrapped open-source toolkit for general consumption 😀

Excelsior!

So my announcement post yesterday for my Asset Toolchain was a bit technical.  Here’s a concrete example using features I finished this morning: you design a level using Tiled, and would like to load up the data in SDL.  Parsing the XML and compositing the images is tedious in C++, but super-simple in Python, so let’s do the content construction at build-time, and just hand SDL a “ready to go” native asset.

Step 1: Define a Native Format (just plain-old data – pointers OK!)

Step 2: Transform Portable Map Data to Native World Data (offline)

Step 3: Dead-Simple Bootstrap!

Step 4: Profit!

I’ve been working hard on a polished post comp version of Dead Men Tell No Tales. New features added so far:

• Better balance and control over waves
• Multiple decks on the ship to defend
• Choose location and deck where to place pirates (instead of random)
• Limited the number of pirates (for balancing). Instead:
• Pirates can be upgraded
• The ship has a heartstone, you lose the game when this is destroyed
• Pirates faint instead of die and come back on the next wave
• Bug fixes, improved pathfinding, visuals and UI

Hot off the press, here’s some of the new pirates (from top to bottom): Swashbuckler, Gunslinger, Grenader and Rogue. The upgrades are shown left to right.

Next on the to do list:

• Animation states – idle, running, attacking, fainted and when taking damage.

Hey guys

Here’s the current state of the tilemap editor, I’m writing for the Tool Jam

Of course I’ll develop further and enter into the Tool Jam.

With regards,

Frank

This entry was posted on Monday, May 26th, 2014 at 7:21 am and is filed under MiniLD #51. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

I decided that I wasn’t happy with many of the bugs that people were reporting on my game, so I decided to do a post-compo release fixing most of the bugs, adding new music tracks and refinements to old music, a new movement system, and overall just more polish than before.
Since I changed too much to just update the original #LD48 page for the game, I’m just going to post the newest build here.

Hope you guys like the improvements!

Windows Build (Mediafire): http://bit.ly/1mtE5fo

So I made this cookie cannon game as a warm down from LD29 , but I got demotivated at the last moment. I Just finished it though play it here http://boaheck.itch.io/cookiecannon Post you’re highscores. I got 50.

Enjoy

~Boa Heck

the logo

Main theme:Cookie quest

Hey, tool jam is on and i might manage to create a really cool tool (its cool at least for me) until this weekend despite my homeworks (i have years of school ahead of me)!

Hope you guys are gonna like it :D!

My brother did a great job presenting our LD29 participation. But he still asked me to write a post-mortem post on Ants at War. So, more than speaking technically about the project, I will focus on presenting my personal feedback on my first participation to a LD event.

Graphics

Being the developer of the project, I ran the game for a while with just colored square on the screen. It was already nice to see the things moving as expected but it was even nicer when the objects started to obtain their final look and animations. Importing the graphic into the game gave me two important points:

1. Adding the graphics, especially when they look nice, really boost yourself during the competition. So I think it’s a really good point to import them not too quickly to have something bringing back motivation when you start to be tired (this doesn’t mean that the time at which you will import the graphics will depend on your tiredness but just that it is a great side effect).
2. Graphics are not totally disconnected from programming and, in this sense, a part of them has to be imported completely (and not only in some test applications/scripts) to be sure that the whole chain from the graphic artist to the game does not bring any problem. In fact, as the graphic artist could prepare and export the graphics in different ways, the programmer has to check that the process is going the right way. Additionally it will give an information about the time you may need afterwards to import the whole and will help checking the game’s behaviour with the final graphics. Just to give an example on this last point, if you are checking collisions between objects according to the visual bitmap, you may have some trouble with noisy pixels (close to zero but non-zero pixels) in alpha channel (eventually, collisions in Ants at War are not dependant on graphics but it was the case at first).

External libraries

In my opinion, it is not a good idea to look for and use an external library you are not used to use. Having a limited time, it is better to focus on the game and ensure to be able to bring this game to an acceptable point than creating a kind of proof-of-concept using unknown libraries.

But, the second conclusion on this part is that even with known libraries, do not try to use them further than what you have already done in the past. During Ants at War conception I tried to create different perceptions of the environment for the ants. For example, the red ants would have not been affected in path-finding by black ants’ buildings (and vice versa). Using one map for path-finding was already well-known on my side, but using multiple maps eventually turned out to be not possible with the library used (in fact, in multiple maps scenario, one and just only one function of the library was always referring to the first map created). This is a waste of time and looking at the current result, using only one shared map is already good. Consequently, do not try to push libraries out of known states! You will probably not obtain something worth it but more certainly waste your time.

Conception

To finish this post-mortem post, perhaps just a note and conclusion on the way the game has been designed and what should have been done. With the limited time allowed, we focused almost completely on designing the game and make it work as expected. This may sound great but in fact it is loosing sight of one important point: the player. Even if we were playing the game to check that everything was working fine, we did not try to see it from players point-of-view. Therefore, the game was lacking enough explanations how to use and play it. We really should think and focus on the player, even if the time is short, during game conception.

Conclusion

This Ludum Dare participation was really great. A little bit stressful at beginning, I should admit, but worth it at the end. Jam competitions are great at allowing a team to work on the same project for a short time and to see progress in another area (like graphics, music and so on) what really boost yourself. So more than the result obtained, it is really this time shared with my brother on a specific project that made of this LD 29 a great and fun experience!

So, hopefully, see you another time for a new LD 😉

ouly

So this is the first time I have seen a tool jam occur.  I really like the idea but can’t come up with any ideas I started working on a key generator but I don’t see how that could be helpful to a LD game. If anyone has any ideas please tell me

Hey!

I have created a tool that is still being worked on for MiniLD51 -Revenge of the Tool Jam. It’s called Better Parsing for Java. This is made for easier data saving to files, and dummy-proofing user input in games. For example: You could ask the user his/her age, and the user replies, “I am 14.” The Better Parsing would read the whole line, and pick out 14 from that String, and convert it to an Integer. With save files, you could save the data “Can Fly = false” and Better parsing could load that String, pick out “false”, and convert it to a Boolean. Right now there are Integers, Booleans, Doubles, and Bytes. I plan on more to come!

I streamed the whole thing, which you can find here.

Have a great day!

– Gandalf1209

It’s taken a while to get around to composing this from the notes we scribbled down after the jam, but here we go!

What went well

Teamwork

Overall, our team worked really well together, given that this was our first “high-stakes” deadlined project. Being able to work in the same physical space was a big part of our productivity over the weekend, and we were able to help each other with problems or changes quickly and effectively.

Planning

We felt it was important to spend an appropriate amount of time discussing ideas before we settled on making anything. This turned out to be several hours. We took a walk around the neighborhood and brainstormed ideas that would fit within the theme, eventually settling on a much more elaborate version of what would become our game.

Sleeping & Eating

While Ludum Dare takes place within a limited time frame, we had no intention of staying awake for the entire duration. Overwork and sleep deprivation leads to inefficiency. We also made sure that we remembered to eat food at regular, human intervals. This helped maintain a positive mood and keep us from consuming each other and/or the neighbors.

Map Editor

We decided to use Tiled to create our map. We spent a bit of time getting it to integrate with Excalibur, but being able to graphically edit everything in the level on the fly was definitely worth it.

Art & Effects

Overall, our art process went better than expected. We leveraged an existing tileset for our geography and map background. We put together the ship and kraken sprites ourselves with Photoshop and Paint.net, and they turned out well with relatively few frames of animation. We used color blending to darken up the map, which really helped set the mood of the game. The ship spotlights were created using a radial gradient effect, which was pretty simple to do and looked great. Additionally, we added a little bit of camera shake into the game when the kraken attacks ships. This was easily the best payoff for the least amount of code.

Stats

The end-game score screen was a last-minute alternative to a boss fight that we cut from our scope. It ended up adding a good deal of replay value to the game, and encouraged players to come back and try to beat their previous score. We also hooked the game up to Google Analytics, which we think everyone should look into doing if they can. It helped give some insight into how people were playing the game, as well as give us an idea of how difficult the level was.

TypeScript

If you’re developing a game using JavaScript, we recommend giving TypeScript a try. Static typing really helped us during the rapid game-building process of Ludum Dare.

Testing Excalibur

One of the main goals we had in mind for this jam was to put our game engine through its paces. We were able to push the limits of Excalibur and find a number of opportunities for improvement. The more we do game jams like this, the more filled-out the engine should become.

What didn’t go so well

Testing Excalibur

On the same hand, we encountered several critical issues that halted game development for several hours each. Excalibur, still in early alpha, didn’t fully support a lot of the features we tried to use it for. While this was expected, we spent a lot of time fixing bugs and adding features to the engine instead of working on the game. Next time, we plan on prioritizing quick workarounds when we’re in a time crunch.

Deadlines

We often didn’t stick to our self-imposed deadlines. For example, we had planned on halting development several hours before the submission time, but we ended up working until fifteen minutes prior to the end of the jam. In the future, we definitely need to timebox better and set more realistic goals around task completion.

Playtesting

As a result of ignoring all of our deadlines, we hardly did any playtesting of the full level. While this luckily wasn’t a huge issue in the end, it had the potential to be absolutely disastrous.

Game Controls

The game ended up with slightly unintuitive player controls. The kraken followed the player’s mouse pointer, but we required you to press the spacebar to attack; we should have just used mouse clicks for attacking the ships. We also only played the attacking animation when the kraken was within attack range of a ship; while this contextual logic was a cool idea initially, it ended up being confusing for players. In addition, the kraken would spin wildly on occasion when attacking ships, which we affectionately referred to as “Spinning Squid Syndrome”. While this rotation was somewhat intentional (it was a workaround to avoid doing a lot more sprite animation), it definitely needed some fine tuning.

Another surprise for us was that many of the players we talked to were much more interested in sneaking around the ships than attacking them. We didn’t really reward this in the ending score screen, as we had always assumed everyone would want to attack the ships.

Tools & Process

We encountered a problem with deploying the game to Github Pages. With very little time left until submission, we all vaguely thought we were doomed. Luckily, we were able to deploy straight from Visual Studio with Azure publishing, which royally saved our collective asses.

Improvements for next time

Know the tools

We had never really used Tiled before, and while it was definitely helpful, it took some getting used to. Next time, we’ll use all of our development tools beforehand to gain some familiarity with them.

Test the process

In the same vein, we should have tested the entire development process on a small scale, end to end. We could have set up the code repository, ran through a sample game to test the workflow, and deployed it to make sure the entire pipeline worked before the jam started.

Work around issues with Excalibur

While discovering issues with our game engine is an important goal for us, it shouldn’t get in the way of finishing the game. The next time we encounter a show-stopping engine bug, we’ll consider changing the mechanics or creating a simple workaround rather than dropping everything to fix it. For example, we spent hours smoothing ship rotations, when we could have just had them snap to their new travel direction.

Define the scope more clearly

While we did a pretty good job of cutting features and scope from the project as we went along, it would have been better to cut those things earlier; there were several things (boss battles, different enemy types, etc.) that we still planned on implementing even when we didn’t really have any time to do so.

Add more stats

We plan on adding even more stats and analytics from now on. We could have kept track of player pathing information to see if there were any problems with the level design, or gotten more insight into the play style choices that everyone was making.

Future plans

We have been working a little bit in our free time to clean up the game code and add more features. It would be really cool to add more of our original scope back into the game now that we’re not under any time constraints. You can take a look at the post-dare branch of the repository to see how we’re doing.

Conclusions

• Teamwork is key
• Your scope is too damn big
• Prepare your tools
• Have an idea of where you’re going before you start

Overall, Ludum Dare 29 was an amazing experience, and we will definitely be back for another one sometime in the future.

My game for LD29 was Radix, a game about growing tree roots. I got very constructive and helpful comments, and my ratings are higher than ever (see graphic below), but I’m not at all satisfied with how it turned out. However, thanks to your feedback, I know how to improve it and I’ve already started developing it further. I’m trying out a new graphics style, and since I’m terrible at drawing, I’m going minimalistic. I know it’s still not very good, but at least it’s better.

Ratings of my compo entries.

Before – after.

Before – after.

Thank you, Ludum Dare community, for making me make better stuff.

Hi, can anyone please tell me until when are submissions for tool jam open?

I have already started making my tool after LD29, but i will submit for this event to see what do you guys think about it.

My entry will be a 2D HTML5 Game engine which can be used with the Dart language.  It’s name is DartRocket and you can already found it on github and on Pub(Dart package manager).  My plan is to make it a more usable during Tool Jam and I hope I can show that Dart is capable of making HTML5 games.

So what did i implement in my engine?

• Background is working and can be animated.
• Text class is made more simple to use.
• New Sound class for making sounds and playing them.
• Reworked the Space Invader example: moving background, score, sound for shooting.

It’s a fair amount of work, but I’m not too happy because i had to think about how to implement some stuff and i think i wasted some time overthinking these problems.

That is the question.

I got some good comments on my game but feels I need a bunch of suggestions to help. I also feel I should change my graphics style, I think minimalistic could be better

Any way go mad! Critisize. I dont care. JUST GOPHER IT

(Yes I am a fan of puns)

oranebeast.co.vu – This is just because I opened a blog up! Yay!

http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=33501 – the game