Main forum > Competitions

Ludum Dare 25

<< < (2/3) > >>

Wampus:
Great prep. Sounds like you are using MIP mapping for dealing with higher resolutions. Do you export with AutoSD in Texture Packer for that?

Still 5 hours to go before the start. I like the sound of themes Fortress, Journey and Time Loop. Hope you get a fun one.

Good luck.

finnk:
I actually ended up running into a lot of trouble with my timing and animation. I think I need to take another look at overhauling everything. Or starting from scratch. By the time I was rushing to finish the game on time, I was inserting code all over the place hahaha. I would have liked for the framework itself to remain untouched. I also had to modify several random functions in ways that affected their intentional purpose. I had to cut features because of the time that I lost due to these issues.

I learned a lot though on the spot and on top of that I've come back with many questions that need to be answered if I ever want to do a solo project like this again. I'm not a very experienced coder though, and I run into similar troubles all over the place where the very system performance affects the gameplay mechanics/math, so I need to really think about it. In general I've had issues with objects with independent behavior.

- How do you properly implement time based animation and make sure it's really tight so that when you tell  an object to animate, it actually animates? I had a major bug that took 7 hours from my dev time involving a character that would randomly not switch to the "dying" animation when killed. Sometimes the game slows down and things don't work right. There's got to be a way around that.

- The proper way to check for inputs. Someone said I was constantly checking literally all keys so they couldn't screenshot my game.

- I had a character who I ended up keeping stationary on the screen, while moving all elements (parallax layers) of the world around him. When I instantiated 45 or more characters, I noticed a lot of slow down. What's the best way to handle the main viewport and moving a character around? I feel like i was updating every entity, and it was a lot of math, when it would be nice to have a panning camera instead... but then that also effects the layers because I can't really move them at different speeds if I'm only moving an orthographic camera/viewport.

- Box2D seems slow on a mac. It caused some inconsistencies in speed, but this was really only a problem because my timing/animation code wasn't working properly. I would be okay with choppiness as long as the game still runs at the right speed. As it was, it speeds up or slows down which tells me I got a lot wrong. I would like to see some working examples and adapt them.

Yeah for texture packer, I'd export the 4x size and then Texturepacker would automatically create 2x and 1x sizes. Another issue I noticed is that GLBasic at some point refused to import any more files. It would just get errors and since I was importing XML files with Genfile, I had to limit myself to a certain number of sprites. I initially used tiles to handle big graphics, but after sprites started disappearing, I had to just turn that cave into a big load image and reclaim the slot for an extra character.

Lots more things to think about.
Anyways here's my entry:
http://www.ludumdare.com/compo/ludum-dare-25/?action=preview&uid=17759
and also timelapse video

Wampus:
Was intending to reply just after LD25 yet didn't...er. Thought this was a very funny entry. Loved the geeky reference to Altered Beast and the general tongue-in-cheek zombie Christian theme. Some of your questions are a bit vague without clear ways I could think to answer them without also sharing the same code libraries you use.

How do you properly implement time based animation and make sure it's really tight so that when you tell  an object to animate, it actually animates?

Have no idea what would have caused that bug. For the game slowing down and causing animation errors you'd need to implement some kind of delta timing to compensate. Useful topic that covers this here.

The proper way to check for inputs. Someone said I was constantly checking literally all keys so they couldn't screenshot my game.

Don't have this issue on Win 7. Maybe its a Mac or Linux thing where the key press is treated like a buffer - if key press is detected the buffer is cleared, or something like that. Anyway, I guess a workaround would be to check only for relevant inputs, e.g. only the three main keys the game uses.

I had a character who I ended up keeping stationary on the screen, while moving all elements (parallax layers) of the world around him. When I instantiated 45 or more characters, I noticed a lot of slow down. What's the best way to handle the main viewport and moving a character around? I feel like i was updating every entity, and it was a lot of math, when it would be nice to have a panning camera instead... but then that also effects the layers because I can't really move them at different speeds if I'm only moving an orthographic camera/viewport.

I don't know what the best way to handle the viewport is. I know how I do it, which is to simply add/subtract the viewport co-ords from the drawn objects when they're displayed. In addition I check whether something has to be drawn at all, i.e. will it be visible on-screen.

Updating every entity shouldn't be demanding enough to cause slowdown, unless running on a mobile platform with very slow CPU/GPU. So, I suspect it must be something unexpected. Maybe there are a large number of redundant objects being updated and/or drawn. You can use the GLBasic Profiler to see where the code is most demanding to narrow down the possibilities.

- Box2D seems slow on a mac. It caused some inconsistencies in speed, but this was really only a problem because my timing/animation code wasn't working properly. I would be okay with choppiness as long as the game still runs at the right speed. As it was, it speeds up or slows down which tells me I got a lot wrong. I would like to see some working examples and adapt them.

Don't know what it would be slow. For running at the right speed using that delta timing thing is important. Also, this might help: http://www.iforce2d.net/b2dtut/constant-speed

finnk:
Thanks for the response, I'm overhauling the whole framework at the moment and right now stuck at some scaling issues.

If I make my game full screen and dealing with different aspect ratios or even smaller viewports where there should just be a black bezel around the screen, what's the best way to keep objects from overlapping this other than drawing a box to conceal it?

Wampus:
At the beginning of your drawing loop you can define the drawing area with VIEWPORT. For example:-

VIEWPORT xborder, yborder, xscreensize, yscreensize

where xborder and yborder are the left and top boundaries and xscreensize and yscreensize are the adjusted screen size width and height measurements to keep the game aspect ratio as originally intended.

Additionally, in your sprite drawing function you can check whether the sprite will be displayed at all by seeing if the top left and bottom right co-ords of the sprite are within the adjusted screen size. You should do this after scaling co-ords to your adjusted screen and before calculating rotations (<- I can explain why if this bothers anyone). This speeds things up a great deal when drawing large areas that would extend far beyond the screen boundaries set with VIEWPORT.

Navigation

[0] Message Index

[#] Next page

[*] Previous page