Well, I think I’m making good progress on my entry.
Good luck to all, and may the best man win!
I think I’ve done alright so far for my first attempt, I have a tiling game world, you can run around and EXPLORE. Exploration removes the Fog of War. Every island is procedurally generated when you start the game, check out rivers and forests!
http://www.ericmcquiggan.com/Gameuploads/ludumdare/LudumDare48.swf
Use your WASD keys!
I wouldn’t have thought it, but game development is going pretty well. I refrain from posting another screenshot.
Things I need to do
I think I will work for another half hour and then go to bed for the final rush.
Next up, some semblance of gameplay.
and dysentery. Musn’t forget dysentery.
Probably won’t get this entry finished.
Here’s a look-and-feel mockup though.
second preview of game
The instructions told me to eat the brownie first. Sort of.
Dinner Progress
Functionality has improved a lot, but I’m feeling discouraged about how much is left. I’m also feeling a bit burned out, so I’m going to take a break.
Tags: foodphoto, screenshot
I got about three hours of sleep, then was woken up by a nightmare.
See, in the dream, I Googled Google (As I’m sure many have), and th “I’m Feeling Lucky” too me to this thing called Joogle. Joogle was apparently something my subconscious made up that performs Google searches for you. I was feeling “clever”, so I searched for Google in that. I was then informed by a crazy fullscreen popup that I was banned from using Google until I sent in an apology. In this dream, I was half-asleep in my recliner, and thus decided to write it later. I woke up from the dream, figured that I’d just nodded off in my recliner, and considered just writing the apology right there before realizing it was a dream.
Worst. Nightmare. Ever.
…doesn’t suit the theme anymore. ):
Tags: tigs flixel
Oh, so much work to do, but I’ve learned so much (about masking images, hehe). I’m tired but I’ve got so much to do if I want a playable game. Well, maybe I’ll take a little break.
Anyway, here is the first screenshot of the game in progress. Santa is in the process of being devoured by a very anger Misfit Teddy.
test level editor
readme included it creates the .map files for my game if you want to check it out go ahead
well thats it for tonight
Awesome pixel artwork is going to accompany the approriate areas. I don’t think my final game will have an ending, per se, though it could. I just want to keep adding content till I get bored, really.
I’m the one with the text based castle themed TextAge game.
a (nearly) finished image:
WIP image:
I’m retiring for tonight. Have fun, everybody.
I came up with the concept of this game when the was theme “exploration” was announced:
In a desolate and vast snowscape… A man collects rocks. what comes next? you decide! no really, im having trouble coming up with the point of the game.
I wanted to see what i could with this setting while seeing how much i could accomplish in a console app.
the screens are getting less boring at least. those footprints took a while!
suggestions welcome!
I just tested my world generator. New, this thing was supposed to create a game world on-the-fly. I was anticipating huge logical errors that would take hours to fix.
Instead, it takes loads of time. Heaps, even. So… I’m going with a backup plan.
Here’s what I’ve got: I’ll create a bunch of premade world areas. I’ll store them as PNGs, and load them as such. This will allow me to rotate my big world sections in 90 degree increments, and place them randomly. These chunks won’t be too big, just big enough where I can have a wide hallway around them (To ease designing them) but not so big that they can’t be loaded quickly. This will hopefully run at a reasonable speed. At the very least it’ll be quicker than that nightmare world I made previously.
Entities will still spawn psuedo-randomly, but they will choose between preset spawn points.
It’s a setback, but I won’t let it stop me!
(I’m glad I decided to get this out of the way earlier than last time!)
—Mr.Dude
I made it! I wasn’t sure I would be able to participate in this Ludum Dare, and I did have to cut my development time, but I’m pleased that I was able to make a realistic, scaled back project with the time I had. I give you: In The Field!
In The Field gives the player the challenge of finding the end point in a large level. The catch is, the player can’t see areas of the level until he has explored there. There are also randomly placed red fields of death that will destroy the player should he wander into too heavy a level of red. What you end up with is a maze that you can’t see, trying to get to a goal of unknown position. The levels are procedurally generated, so you can play as long as you want.
You can get the game (for Windows) here. Have fun!
Every time I use pixel perfect collision in a game I try a slightly different approach, trying to perfect the algorithm.
First it seems very very simple. Let’s just check 1 pixel at the center bottom (at the players “feet”) for a non-transparent pixel. If there’s a collision, follow Y-axis upwards (say, max 5 pixels) until we hit a transparent pixel (non-terrain). Put player there. This will make him walk on the terrain.. and also climb 5 pixel high obstacles. Higher obstacles needs to be jumped.
Cool enough, just checking one pixel and we get all that.
But then you realise you can jump into the roof.. and player will only stop first when his feet head is way into it and his feet his touching the roof.
So you check another pixel for collision, one at the head of the player, now you can stop him when he jumps into the roof. It works well.
Then you start painting more levels, and soon enough you’ll make a pointy object. The player jumps into it, not hitting the head or feet, just the mid-section. Player falls down by gravity, head hits the floor of the pointy object, and the player gets stuck.
You could either not paint pointy objects.. or you could extend your collision detection algo. One of the reasons I went with pixel perfect collisions is that I wanted levelbuilding freedom, just being creative and painting whatever fun terrain in paintbrush or graphics gale. I WANT pointy objects. Makes for nice ladders the player could jump on :).
So, we add pixel checks on the left and the right side of the player so we don’t jump into pointy things. It works decent, but you realise just checking 1 pixel at each side doesn’t cut it in all situations, objects you jump into could be Very pointy. So you basically end up checking all pixels on all sides. A bounding box if you so will, and we check all the pixels along the borders of it.
This is totally ok if you got a fast get_pixel()-method for your disposal. Now, how I usually do small games is I have a “physics”-behavior which I plug in into my player-class. This adds some instance variables to the player-object, velocity_x, velocity_y, acceleration_y etc. Before each update() the plugin will read those and modify x and y accordingly. Then I land in the update() method of the player with my new x and y (the behavior even saves previous_x and previous_y for me if I need to revert to the most recent position).
So, I’m in player update() and I got a new set of x and y .. and I got my collision_left?, collision_right?, collision_bottom? and collision_top? methods (I do Ruby so “?” is totally OK in method-names).
Still sounds like this should be simple, but it turns out it’s not.
What side do I check collisions for first? Depending on what I start with I’ll get different player controls. If I start by checking collision_bottom? and reverting y to previous_y on collision, then checking left/right and reverting x to previous_x on collision I will be able to stick the player to a vertical wall just be jumping (say to the right) into it and keep holding right arrow-button. And if I check right/left first there’s other effects.
Though this might an effect of first doing all the physics and then doing all the collision detection. Maybe it’s a must to them at the same time, and with that I mean, if a right arrow key is detected, you “fake move” your player 1 pixel to the right and if right_collision? is true, you revert instantly. And so on.
I want to end up with something simple and readable, and I feel it should be possible.
Here’s a screenshot of the game I’m fiddling with, to give you a sense of what kind of terrain we’re talking about:
Who’s got the perfect pixel collision algo with simple physics? (only acceleration_y / gravity is OK)
I decided to go with penguins again! I’m sorry! But these were kinda interesting to make. Today I woke up at 6am and somehow felt that I ‘overslept’, which shows that I have a lot of work to do. I need to focus on the essentials only, and see if I can bring this together.
So, now I need to investigate some breakfast and building the environment for these guys to play in!
istringstream in(data);
int me = 0;
while(true) {
char ch = ' ';
in >> ch;
if(ch == 'p') {
cin >> me;
} else if(ch == 'h') {
