Ludum Dare 25

[finnk]

I'm doing the Ludum Dare 25. My first.

I will probably be using my event-driven framework, already announced on the official site.
Phoenix Framework

There are still things I want to add before the competition starts, like file loading, a list and sort function (also one I can use for Z-sort), object-attached listeners, and basic colliders/physics if I have time.

[erico]

Welcome Finnk.

I´d wish to be able to participate too, but time has been an issue later (december and all that) and the free time will go to some team projects here.
Good luck, keep us posted on the goings.

[Wampus]

Awesome, Finnk.

I really want to do 25 but I'm worried about taking away focus on my Chaos remake. Its a surprisingly big project and I'm feeling the pressure to get it done.

If I did do Ludum Dare 25 I'd be using a better framework than last time (text, easing functions and particle engine stuff). Also, I want to try the Jam instead of the Compo since I found the last Compo completely exhausting. Took me ages to get an idea and I finished something submittable with barely 10 mins to go. Ugh. It killed me. Hated it. Didn't help that I decided a large map with 57 separate tiles and animation was a good idea. Lesson learned. Need someone else doing visuals and helping out in other ways. Also, must leave time for music creation and polish for last day.

If more than three of us on this forum decide to do it then I'll join.

[finnk]

So I hadn't touched that framework in a year and spending time with it recently, I realize I never really got anywhere with it. Kind of embarrassing. It think it was because exported Mac had the font sprites loading out of order or something, but anyways... I looked at it and it was crap. A lot of stuff was broken and I would've been going in without a working framework.

So I updated it, and it's beautiful. I could hand it to a newbie and have them make a game in a day.
- Added basic Box2D physics with the help of info from this forum. Still need to add some more stuff like custom shapes, but it's workable for now.
- File loading/saving
- Import basic orthographic Tiled maps.
- Import Texture Packer-made sprites and manually add animations to the object by frame values
- Tween Towards coords. Fade (except on fonts and objects with physics)
- I noticed I didn't even have sound functions in there, so basic ones are in

Still want to add more stuff, but getting close to the start date now. Also realizing I should add some preloading functions because when I play in higher resolution and it uses the 4x textures, it takes longer to start up.

Anyways, just prepping for this competition has been a good lesson. Oh yeah, I think that when exporting for Mac the font sprites are still loading weird. No idea why, but it's fine on Windows so that'll have to do.

[erico]

You are sure well prepared! Go!

[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.

[bigsofty]

Very interesting watching your dev video, well done! That is a lot of work for just 2 days! 

[erico]

That video is awesome and quite frantic, finnk! Congrats!