Node 54

[silentlamb]

Hi guys.

I've been participating in Ludum Dare 30 compo and I was able to finish my entry on time. I've decided to create this thread to share my project (with the source code) with everyone interested. SFML lib helped me a lot. I also plan to fix bugs, implement improvements suggested from players and improve this game more and more.

First, disclaimer: LD is a compo in which you have at most 48h to finish game from scratch. Because of that the source code is a total mess. I haven't got enough time (and gamedev programming experience) so I've been hacking a lot just to make everything work. Now it's time to clean that mess.

If you have any questions related or not to the SFML, feel free to ask!

My tools of use:
Programming related:
- SFML 2.1,
- Box2D 2.3.0
- VS 2013 - win version
- Eclipse CDT - linux version (The Linux port is ready, but I haven't published it due to not knowing how to handle binary x86/x64 issues)
- Python - to generate header/source files as I don't know VS much.

GFX/Audio:
- Inkscape
- GIMP
- PyxelEdit
- sfxr

Entry with binaries and the source code:
http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=40102

[Tex Killer]

Nice, another LD #30 contestant

I've played and rated your entry. The connection with the theme is kind of weak, but it is funny and the pixel art is good. Congratulations!

You check my entry out, if you want to (although mine is for the Jam compo): http://en.sfml-dev.org/forums/index.php?topic=16248.0

[achpile]

what is linux x86/x64 issues? maybe I can help (I've spent a lot of time finding out how to distribute linux binaries).

[achpile]

Ohh, now I see... Don't use static SFML linkage on Linux to avoid libs versions mismatch! Link statically only libc and libc++. And build the project with SFML 2.1 (not from the master branch). And make 2 builds. for 32bit and 64bit (like here http://fired.tk/downloads/1/).

this is how I link my project:

LDFLAGS     = -static-libstdc++ \
              -static-libgcc    \
              -lsfml-graphics   \
              -lsfml-window     \
              -lsfml-system     \
              -lsfml-audio      \
              -lm               \
              -lsqlite3
 

[silentlamb]

@achpile:
I haven't used static linkage (except the Box2D lib). Instead, I used -rpath parameter of linker to specify custom path to look for a lib: $PWD/lib folder. And I put there all of the SFML libraries. The reason is that for LD entry I wanted to keep things as simple as I can. I've received feedback from people not knowing how to deal with missing ms*.dlls; when giving them link to proper installer from Microsoft pages people tend to  install wrong version.  I learned my lesson here and now I think I know how to deal with this situation next time.

So for a Linux entry I've decided to use rpath and link SFML libraries this way. I think this it's something good from both worlds: if someone wants to use global libs he might just remove "lib" folder from the game's root dir.

As for issues with x86/x64 architectures. The only configuration I might use for a now is Linux inside VM, and it's 32 bit version. Since I don't know much (yet) about cross compilation I need time to learn new stuff.

BTW. Why do you link libc and libc++ the static way?


@Tex Killer:
Thanks for the feedback! I saw your comment already but I haven't got enough time yet to play your game. But I will for sure, I promise! I am aware of many mistakes that I made. More on this topic here in this blog post: http://www.ludumdare.com/compo/2014/08/30/node54-final-thoughts/


Update on the project:
I am currently in the process of cleaning up the code from mess that was made. Responsibility of some classes got too wide. I also want to add Scene management so I could combine set of objects to be drawn within a given scene + some state parameter passed to drawn objects so they might drawn themselves the other way.
Currently when I want to add some effects like screen shake or a temporary wind I need to add another if statements and this is kind of thing I always try to avoid. Small if-else always tend to grow bigger and bigger. I also learn C++11 in this process as this standard is still new to me.

I also plan to release (and keep it this way) source code of my game after cleanups and implementation of new features, so maybe someone find it useful and take some subset of it to his/her project.

[achpile]

Oh, that's the reason. I had a libGLEW version mismatch. Because you compiled your sfml libs with 1.8, but I have 1.10. This way I don't contribute sfml binaries with the project binaries

[silentlamb]

I see. I totally forgot that SFML itself got dependencies too, now I see the problem. Thanks for the advice!

[Tex Killer]

@Tex Killer:
Thanks for the feedback! I saw your comment already but I haven't got enough time yet to play your game. But I will for sure, I promise! I am aware of many mistakes that I made. More on this topic here in this blog post: http://www.ludumdare.com/compo/2014/08/30/node54-final-thoughts/

I've read your post, and it was like that for me on my first Ludum Dare, except that I couldn't produce a playable game at the end, and you could. This time the game worked very much better than my first try, but it is my third Ludum Dare with my own engine, so that was to be expected. Good luck on your future developments!