Highschool Student & Programmer. Likes food, water, oxygen, etc..
Ludum Dare 26
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
Ludum Dare 21
Ludum Dare 20
Archive for the ‘LD #22’ Category
Now that the voting’s over, I have some tips on how to make a good concept for the game that I learned from observation and feedback.
1. Aim for completeness over detail
The games that I enjoyed the most are the ones that feel complete. By this I mean that your game feels like any other, but shorter. Definitely work hard to include audio, non-placeholder graphics, and whatever else your game needs. Think about it like you’re trying to sell your game: you can’t give out everything you have in mind, but you can demonstrate why each aspect of it is good.
2. Let the player lose
If your game is based on levels and you only have an hour to do them, you are probably going to need to cut down on your vision. A common mistake is to drop the latter half of the game, where the levels become more difficult. I am much more interested in the levels that will challenge me and that I will fail on than some hyper-detailed tutorial. Let the player struggle with the clever mechanics you had in mind. A great example of this is Increpare’s Puppy Shelter. Even if your game does not involve levels, the player is eventually going to get bored of constantly winning with ease.
3. Reward smart actions from the player
From the comments on my game, I found this lesson to be quite important: the actions that the player can perform must significantly and obviously affect their performance. It is incredibly rewarding, as a player, to, after trying your game for a few rounds (or whatever unit your game is measured in) to be getting better scores (or whatever unit success is measured in in your game). If your concept doesn’t do this, it needs to. Also, remember that just because you, the developer, can see the link between actions and responses doesn’t mean everyone else can.
4. Make the Connection to the Theme Obvious
While it’s entirely possible to go through the competition and just write some short blurb at the end that uses the theme in it once, much of the challenge in this competition is using the theme. The theme serves as a constraint that lets you explore ideas that you wouldn’t have otherwise done. You are likely to be more innovative if you set a goal of yourself to put the theme even in the game mechanic because it rules out what has been done before.
5. Ensure that the player can learn the game
This is another one of the problems that arise when you try something new for your game. Ideally, your game would be completely intuitively – people would just figure it out from clicking on stuff and pressing buttons on their keyboard and no instruction at all would be necessary. It’s unrealistic to think that every concept you think of fits that. If you need to explicitly state anything more than that your game is a platformer and that it uses WASD, you should include some sort in-game tutorial (textual doesn’t work very well. I’ve tried that twice; people need to see what is being talked about and to try it). If, for your game, players need to memorize a lot of keys to press or rules, you need to simplify your concept.
6. Be confident in your game
Please don’t belittle yourself in your description of the game. Try to make your game look good.
7. Have fun
Okay, this isn’t exactly related to the game concept, but it’s always good to remind people of the fact that their ultimate goal here is not to win, but to have fun and that all tips are there to be broken. This is a great opportunity to try out new concepts and to do cool things. You should let yourself do whatever you want. There’s no reason not to; regardless of what you do, this awesome community will give you awesome feedback on your awesome idea.
I’m planning to do an experiment to determine some things about the effectiveness of putting one’s work into various places in a game, and I need the source code of a few games in order to do it. Specifically, I’m looking for games which can run on Windows (or in a browser) and are intuitive to play; it should take no more than 5 minutes for someone to enjoy the game. I will be making minor modifications to the code of the game, and major modifications to the assets in the game and distributing modified versions.
If you’re interested (or, at least, don’t object to my use of your game), please post a link to your game in the comments & any attribution you’d like if I do use your game.
(I will, of course, share the results of this experiment with the community, since they are probably interested)
- Bugs didn’t happen. It was sort of magical. I never spent more than 10 minutes correcting any bug, and there’s no crashes I’ve discovered in the Mac version.
- I had adequate time to create assets. Most of Sunday, actually.
- My game concept is original.
- My timelapse was good!
- I did some serious bloggin’.
- The game concept isn’t quite as fun as I’d imagined. I still like it though.
- The code is by far the worst code I’ve ever written. Yes, worse than both previous Ludum Dares I’ve done.
- The music doesn’t last very long. A longer loop would be good.
I like people who like demos because they can tell me if these actually work!
Now, the instructions. The game will start with 4 dwarves in the corners of the screen, moving about and mining stuff. Whenever they mine stuff, you get points and money. Your goal, of course, is to get a lot of points. That seems pretty easy, given that the dwarves will do it without intervention from you. The problem is that dwarves will explode if they touch each other, and that’d be terrible. Thus, it is your duty to keep that from happening. There is a white bar to the right of the screen. Whenever it runs out, you have the ability to spend money to place traps, lures, and to empty spaces. Dwarves can see things in a 8-block radius, unless they’re blocked by a wall. Anything they can see if highlighted in yellow. You cannot place traps or anything within the sight of or next to the sight of a dwarf. Dwarves scream when they find another dwarf’s body, and the scream attracts all other dwarves in a large radius, so it is unwise to murder a lot of dwarves (well, it will be when more dwarves spawn, so don’t do it)
(Note that these are what is going to be easy mode, although more dwarves will spawn over time in the final version; for more of a challenge, don’t place anything every other round)
Well, that’s all I’m gonna do tonight. I’ll probably think about how to make it more “fun”; I feel that this game could use some more hectic gameplay (you should lose really quickly if you’re not trying).
Have I ever said that graphics were useless? Of course I have. I am, right now, redacting all of those statements because man does my game look more awesome with graphics. I’m incredibly happy with the game grid (everything that doesn’t have words), given that I’ve never done such small graphics before (10×10 pixels for each square), but it actually looks quite nice and effectively conveys the information. Let’s do a before and after. I recreated a similar situation to my first screenshots (but with less deadly traps because they cost money now…). Before is on top, after is on bottom, As you can see, there are no longer invisible buttons, the dwarves sort of look like dwarves, deadly traps look like spikes, sticky traps look like… green stuff. Also, you can determine the value of rocks (diamond = most valuable, then gold, then ruby, then copper) which lets you place traps smartly. Also, the title is now “Dwarven Isolation” instead of “SFML Window”
Then, each a few seconds later also shows some graphics (No longer shall dead dwarves look a lot like living dwarves and also look like traps! Also, no more phantom dwarves). The new one would have the white countdown bar, but I wasn’t quick enough on the screenshot:
The dead dwarf looks surprisingly dead, considering I just took a living dwarf, and put red on its face everywhere. I’m really really pleased with the graphics overall, since, as you can see, they are a MASSIVE step up from what I had before! I’ve got a really good feeling about this Ludum Dare, and if you read my blog posts this time, they no longer give you the picture of “Making a game in 48 hours should be considered a form of torture.” So, we’re at the halfway mark right now, so 24 hours left for polishing, I guess.
- Sound effects!
- 2 more secret traps!
- Making the interface look nice.
- Help screen!
Well, I was hoping to finish the game engine itself by the end of tonight, but I’ve got like, 6 hours before that happens and, as far as I can tell, the game works perfectly, and never crashes. There’s still some balancing left to do, though. I’m really surprised at being in this situation because my code is incredibly ugly, uses a massive excess of pointers, and has plenty of one letter variable names. But it works, so I just need to not touch anything except the rendering code.
Here’s a screenshot from the game. You can see that I have been very focused on the game engine, and less focussed on graphic or interface. For example, there is a black button on a black button that you can’t see, but has a pretty important function. Also, the title is “SFML Window” which isn’t really the most creative title ever.
- Fix a rendering bug that makes a new dwarf spring up randomly whenever a dwarf dies.
- Add some visible particle whenever a dwarf dies.
- Give everything real graphics.
- Differentiate between valuable ore and not valuable ore.
- Label what each button does & what its cost is. Also, actually charge the player money for placing stuff.
- Step on a kill trap, and record the sound I make for use in the game.
So, I’ve got a sketch of the basic dwarf mechanics. They are very greedy. And, in fact, that part works perfectly! Those dwarves will run towards gold they can’t even see! That’s not really supposed to happen. It’s made worse by the fact that they might be able to see another dwarf through the walls, and explode.
Currently, what I have looks as follows. The red square is a dwarf, black squares cannot be mined, the dark gray squares are already mined. The brightest two squares to the left are unmined shinies. The sight of a dwarf is shown as the highlighted mined squares.
Well, seeing through the hardest material in game which can’t ever be mined is probably not a good thing. It sort of seems like it’s only taking the sight radius into account. The game mechanic just… doesn’t work without the sight algorithm working.
Other than that (which, thanks to the fact that my code is… “neat” is easily replaced. I just don’t have a replacement), things are going pretty well. I’ve got a pathfinding algorithm that works (it’s just A*), and I’ve got the dwarf movement code working (well… as long as the sight algorithm works).
What’s left for today:
- Fix the sight algorithm. It’s really important.
- Allow the player to place stuff.
- Make the stuff players place do bad things to the dwarves.
- Implement a money & score system.
- Make a help screen!
Which is odd, this early on. I must be getting better at this whole rapid game creation thing. The name is “Dwarven Isolation”. It is about preventing dwarves from mining into each other, which is important since dwarven handshakes cause catastrophic explosions (but I’m sure a smart reader like you knew that). The dwarves, of course, are attracted to shiny objects, like gold or treasure, and are quite good at whacking stuff and making solid rock walls go away.
More seriously, here’s my entire design document.
In descending order of quality, the ideas I have so far are:
Idea #1: The player’s goal is to keep several people alone, and to prevent them from contacting each other. The game would take place on a maze on a grid (although, if possible, the graphics would be smooth). New people would be introduced as the game goes on, and the player would be charged with keeping them separate for as long as possible. It would likely be a turn-based type of game where there are two stages. In one, the player places obstacles and stuff, in the other, the entities move. There would be penalties for killing people.
Idea #2: Something about splinter cells or something; trying to function without knowing anything about other members of same “team”.
Idea #3: A damsel in distress self-rescues.
Maybe this time we can break 600 games (although that might not be a good thing).
My goal this time is to make a game that DOESN’T crash randomly because that’s not a good thing. That’s in addition to, you know, everything else, but this whole technical thing gets in the way of that whole fun thing.
EDIT: I wonder if I could make a programming game. I mean, this seems like a rather apt community for such a game…