Posts Tagged ‘Direct’

Things to REALLY consider (dev/submission best practices)

Posted by
Monday, April 11th, 2016 5:12 am

I wish someone would pin this up so everyone can read it – not because I am smart, but because this is really important.

1. Decrease time to download

When the deadline comes, many people go to sleep because they know that tomorrow they will play and rate lots of games. They will do that for the next three weeks (probably with decreasing intensity) so the download process must be easy. I’ve participated in the last three LDs and I’ve rated lots of games. Some of the devs rated more than 300 games per LD (although this doesn’t guarantee that they really played them, but I am not the one to judge that). I’ve wasted almost an hour more than I had to (accross this many games) on downloading the games that are not directly downloadable.

The point is this: games should be easily accessible and downloadable. The less clicks I need to do to run the game, the happier I am (…and you are too!).

That being said, I have several suggestions for developers:

  1. If possible, provide a web version of the game. If your engine does not support that, that’s ok too. Simply follow the next points.
  2. Use download services that allow you to post a DIRECT link to your file. This is how it goes with those typical gaming portals many of you use (the bad scenario):
    1. Chose a link on LD page
    2. *a gaming (or other) portal opens, for example –* – sometimes slowly
    3. find a download link among 10 other links and pictures
    4. *a popup opens*
    5. ignore the donation links and buttons and search for the download link, which is usually small.
    6. click the found download link
  3. If you are using dropbox or onedrive or some other cloud drive – modify the URL so that it leads to the direct download. It will take you 5 seconds but save each of us that are playing your game 5-10 seconds. For example, if your dropbox link looks like this:, change the ending to ?dl=1. This will save everyone’s time.


2. Have mercy on the non-EN players

I don’t know the exact demography of the LD developers, but I guess many of them are from USA/UK or other english-speaking countries. However, please… and I mean PLEASE!, have mercy on players/devs that do not use english QWERTY keyboard layout. That means: X and Z keys are among the worst choices for player actions. Simply DO NOT use those! If you need proof, look at this picture (This is about the ONLY keyboard layout where X and Z are next to each other):


And now look at these (these are layouts that a lot of people use too, believe it or not). Notice how far are X and Z from each other.




You may use the QWERTY layout, but know that many people do not! (And I have not even touched on cyrillic, arabic, chinese etc.)

The solution? Either allow the player to configure the keys or use the keys that are in the same position on all keyboards (shifts, controls, alts, tabs, enters, backspaces, etc.)

And if your engine really really does not make it easy for you to enable the user key binding, use letters C + V or J + K (other than the dvorak layout, these are next to each other on most other keyboard layouts).


3. Folder naming

Fellow developer DesignerNap added another important best practice: Always name your folder (ZIP archive or the folder inside) by the game, not generic names like ‘game’, ‘LD35’ or such. If the game is called “Dolly wants a cracker”, then I expect a folder with that name.


4. Unity (.NET in general) PDB files

(Thanks to Almax27)

PDB files are useful. Very useful. But only to the developer. These files are huge and contain all sorts of different debugging data required to step through your code in your Visual Studio. However, once you build the executable, players have absolutely no use for them. Do not include PDB files in the published version.

On the side note, the only reasonable reason why you could include PDB file with the build is that in the case of the exception logging, you will be able to see the line in the source where the exception originated, which is useful too. But again – only to the developer. And since we do not expect players to send us their debug logs with exception messages and stack traces, they do not need the PDB. Leave it out! :)


5. Good luck Ludum Daring.

Good luck with your games. I look forward to playing them.

Kerinova Studios LD27 Report- Hour: 4

Friday, August 23rd, 2013 11:26 pm

The second bi-hourly post has come, and I am really late for it. One hour and 20 minutes late in fact. Oh well. Better late than never, as they always say.


I am starting to get really tired. Ludum Dare started at a fairly bad time for me. It started at 6:00 PM, so by the time Ludum Dare began, I was already wake for like 12 hours. Nevertheless, I continued on for as long as possible. So, what have I gotten done since the last post?


If you remember, during the last post, I had nothing playable. Just some engine level stuff. In the 3:30 hours since then, I have finished most of the core features. I finished about 25% of the assets, and got more done on ideas.


I now have a working menu :) Which is sort of playable I guess. So goal number 2 finished, Goal number 1 sort of failed.

I don’t really like this menu background. I will probably change it later.

I don’t however, like the menu. I think it is rather ugly, and will need a revamp later on.



The game itself isn’t playable. I still need to finish the tile, player, and enemy assets. Tomorrow will be a lot of asset work, then debugging all the things I couldn’t test, because I didn’t have assets.

You might say a solution to the debug problem, is to use placeholders. However I hate placeholders. I would rather spend the art time doing something that may end up in the final submission.


Nevertheless, I am making decent progress so far. 42 hours and a half to go.



Before the next post, my goals are:

  1. Get sleep.
  2. Work on the game in my dreams.

You can follow my live stream at, and my live tweets at

You can follow my Ludum Dare blogs at

[cache: storing page]