Home | Rules and Guide | Sign In/Create Account | Write a Post | Reddit | #LD48 | #ludumdare on irc.afternet.org (Info)

Ludum Dare 30 — August 22nd-25th 2014 — Theme: Connected Worlds
  • Judging Ends: in 12 days, 17 hours, 55 minutes, 43 seconds
  • [ Real World Gatherings | Ludum Deals | Warmup Weekend (Games) | MiniLD #53 | Wallpaper (1) (2) (3) | Mailing List ]

    [ Play+Rate | Edit | View All Games | My Game ]


    Game Development

    Posted by
    February 1st, 2014 7:18 am

    Hello Ludum Darer’s,

    I find that when I go to develop a game for Ludum Dare, or any other time for that matter, I find that I can never get anything done quickly, and that is because of the way in which I attempt to do things.  One of the things that doesn’t help is that I have no real idea of how a game should be laid out, this causes issues when coming to add new screens, new levels, and other objects into a game.

    I am hoping that someone out there will read this post and have some ideas to help me on in my journey of developing games, and how I should be tackling the task.  I see people who, in the same amount of time that I have had, create much more of what is starting to look like a game when I have nothing because of the problems I encounter while trying to make one myself.

    Comments would be appreciated, so please, if you have any ideas of how I should move forward please leave your ideas in the comments.

    6 Responses to “Game Development”

    1. Photon says:

      First, don’t forget that most vets put in a lot of work to get where they are and be as efficient as they are. They didn’t learn how to throw a game together in 48 hours overnight, and it can take a long time to get comfortable making games. I’ve been at it since about mid-late 2012 and I’m still no expert. I’ve been trying though. :)

      Personally, I found that using and familiarizing myself with a game creation tool can really open one’s eyes to what it takes as well as helping one along with those crucial first steps and games. You may not have your hands dirty with all the fine details, but it can really help you come to grips with all that has to be handled.

      The tool I’ve been using is Stencyl (www.stencyl.com). It lets you focus more on gameplay logic as opposed to framework issues. I made both my LD27 and LD28 games in it. Even if you decided later down the road to get back into hard code, you can explore its “code mode” or take what you’ve learned and apply it elsewhere.

    2. sorceress says:

      I have no real idea of how a game should be laid out, this causes issues when coming to add new screens, new levels, and other objects into a game.

      We each have our own favourite ways of doing things. From time to time we’ll see that a technique we’re using isn’t perfect, because in some situation it becomes awkward or inefficient to use. This can be saddening when it happens, as it breaks our creative flow, and shatters our beliefs about how good we are at coding.

      But it is also an opportunity to take a few steps back and open our minds to new ideas and new ways of looking at things. It can be hard and time consuming trying to make stuff work better. It’s often very experimental.

      But eventually we’ll have an idea that should work. It may take time to work out how to program it, but once we can successfully do that and see it work, it becomes our new favourite way of doing things.

      This kind of knowledge is hard to teach because the nature of the problems can make them hard to see and explain. It’s something you learn through experience, by running into problems, and having the courage and resourcefulness to find a way out.

      The solution we find won’t be the only way of progressing. There isn’t one true “correct way”, or a way that it “should be done”. There are “ways that work” and “ways that work better in this given situation”. If you find yourself wading through a river ten times a day, you might begin thinking about building a bridge. Others might think about taking a horse across, or a boat.

      Over the years, you’ll develop a deeper understanding of how you can do things in different situations, and you’ll build up an arsenal of techniques as you go. But programming takes years to learn.

    3. My two first attempts at making games in adult life took about half a year and seven days respectively. The latter was submission to a miniLD. The reason they took very long time was not so much that I wasn’t working on them. Rather I was inexperienced and I was trying to do everything myself. I was coding in python with only pygame to help. The very next game I switched to Unity3D and I did something that actually worked as a 3D game even if I had to learn both Unity and Blender during the 48h of the LD. Now Unity is just one in an array of tools out there that all share the nice feature of taking care of all things you really don’t need to be bothered with. I would, start by investigating these type of platforms (you can find them by seeing what people have used in the last round of LD for example). That is the technical starting point. E.g. if you feel you get stuck in programming details, maybe try using puzzlescript or similar and see how that works.

      Second is more personal, how to get focus in 48h (or 72h gamedev). I find myself formulating “what if” questions a lot of the time. “What if Wikipedia pages and links were the playing field for and RTS?”, “What if the world rotated 90 degrees every 10 seconds?”, “What if the objective is to stop someone from aligning three in a row?”, “What if the camera follows a ball, so you have to carry it to pregress?”. Some of them are quite interesting questions, some are not very novel. They do however all give a quite clear direction on what to focus on in the game. Then the LDs are so short I only allow myself to implement that feature (first). So by the end of first day e.g. the world should turn 90 degrees every 10 seconds and the character should be able to survive that if the character is in the right spot. That is basic, core mechanic should work. So before I start working, as soon as I have the idea, I strip it down to what is absolutely necessary to make the idea into a game. Then I put tiers outside of that for what I would like if I have time (music, sound effects, eye-candy/juice etc). Once I have the plan, then there are no choices, I simply start at the core. As soon as something works, I move on. Never look back, never redo things that are OK. At least not until you have everything nailed down in that priority tier and probably wait until you’ve got the next tier of objectives done too.

      I haven’t done any great games yet, but I’ve completed all sufficiently well to submit them. I’ve worked like crazy each time. But it’s quite clear that I could now progress much further than I could in the beginning.

    4. racarate says:

      One thing that worked for me was to start small. Before my first public jam (GGJ2012), three of my friends held a one-day jam at my house. That was good practice. See if you can organize the same, then critique each other’s pieces afterwards and try to teach each other tricks you discovered.

      Another good way to practice is “Klik of the Month” — it’s a two-hour game jam:

      http://www.glorioustrainwrecks.com/node/44

      Get some simple graphics on-screen, some simple sounds and music coming through the speaker, and some simple rules + interactions… a “bigger” game is just more of the same (and more interesting rules + interactions).

      So… practice! Even if it’s just you by yourself for three hours every other Saturday, you’ll inevitably get better.

    Leave a Reply

    You must be logged in to post a comment.


    All posts, images, and comments are owned by their creators.

    [cache: storing page]