About YSelf Tool (twitter: @YSelfTool)

Entries

 
Ludum Dare 32
 
MiniLD #58
 
Ludum Dare 30
 
Ludum Dare 29
 
Ludum Dare 26
 
Ludum Dare 24
 
Ludum Dare 23

YSelf Tool's Trophies

YSelf Tool's Archive

An Unconventional LD

Posted by (twitter: @YSelfTool)
Sunday, April 19th, 2015 5:42 pm

This time I did not expect to take part at Ludum Dare since my study needs all of my time (and more sometimes), so I took part at theme voting with mixed feelings since it would be – once again – a LD some weeks after I had some spare time left for fun like this.

Saturday morning I took a look at twitter and thought “Great theme!” didn’t think of it any more.

But then, saturday evening, returning from the university, I had an idea that was simple but fitting nonetheless – I had to make that one reality. Back at home I read through grabbing sound and calculating FFTs in JS, since I definitely wanted to make it available through browsers, and usually I use Python or C++ for calculating such stuff.

The bad thing was: All the functions for grabbing audio are still prefixed (I hate that aspect of JS), but they worked. And even better: Modern browsers have build-in FFT-Support (through something called AnalyserNode), I didn’t even have to write that code on my own!

And then, some hours later, I was done. I simplified it and removed some ideas I had since it was hard enough to calculate the frequency of the sounds you make, but on that level it worked and was fun – great!

The special thing: It only needed ~ 5 hours, not the usual 2 times 12 hours I usually reserve for taking part at Ludum Dare.

Thanks for giving me that possibility, once again! And for all of you currently trying to fix last minute bugs: Good look. Please don’t read on here, fix them.

P.S. or better fix them tomorrow, as you won’t have luck at this hour and stress level. I know how you feel.

My worst entry – Postmortem

Posted by (twitter: @YSelfTool)
Friday, August 29th, 2014 4:06 pm

This Ludum Dare was interesting, as it was my most ambitious game. And it failed. I should have known.

What went wrong? As always I tried to include an AI, random generation of something (this time a world), a dijkstra-algorithm (and removed it again, it always needed too much time calculating the paths) and fun.

And… it worked! Except for the dijkstra, which was at least bug free, but still not fast enough to calculate paths for 100+ animals every few seconds. And far from fast enough while running on a Pi. I had animals, the player could build rudimenarily, the villagers spawned, there were not exponentially many of them, things were fun (for me).

It was hard work, as I wanted to do a multiplayer game, using Python as a server language (since I love Python) and JavaScript as the client language (since Websites are the most accessible kind of game, and I like JS). That meant writing Python and JS simultaneously, now I can tell: That’s confusing, fun, challenging and confusing. Did I mention confusing? The way to design a program in those languages are close enough, but the syntax is different. Different enough to confuse.

So, what was the problem? For multiplayer in a website I used websockets, which are great for that stuff, it went better than expected. But then again, it was the first project I successfully used websockets for. I found a python library (ws4py) based on another python library (cherrypy) with which I never worked before, and used them. Bad decision. It was sunday evening, three hours before deadline, when I first tried moving from localhost (lo) to local/public IPs/Domains (wlan0, eth0). Didn’t work. The Python socket implementation has a small bug… crashing connections far too often. I changed some parts, sent smaller packets, added small time.sleeps, It made the connection more stable. Then at least one in ten survived and worked. For a game based on an active connection that’s bad. But at least you could reload and play on.

But then not only did the connections crash, but sometimes also the thread handling the sockets. From the library. The bug is in the python standard lib. Without a chance for me to fix the bug. So… It doesn’t work.

What did I learn? Don’t be ambitious. I should have known that. Multiplayer is a lot of work. Use libraries you have already worked with. Did I ever do that? I guess not, but this time that paid out badly. Don’t use two languages at the same time. Make fun games!

So far, see you in december. I’m sorry my game does not work. Neither did using different backends for the websockets work, nor using pypy for the server.

I’m sorry.

Again, I am in, too

Posted by (twitter: @YSelfTool)
Thursday, August 21st, 2014 12:41 pm

It’s Ludum Dare time!

I guess I’ll use JavaScript, but maybe Python (except for not having made graphics or GUIs with it before), because I like Python. If JavaScript, I may use WebGL, since I looked at it the last weeks, but then again it looks like every OpenGL. Canvas would be easier, so they are possible, too.

Since my ability to draw is epsilon (very small, but greater than zero), I guess I’ll use single colored rectangles as graphics, made procedurally in the code or with any graphics tool – maybe Paint.NET, Gimp, definitely not Pinta (yay, we have features: click here to select a rectangle! ups, not implemented yet, but look at this fancy menu telling you to use it. to take a tip from me: don’t waste your time with pinta).

Sound and music is always fun, but none of my JS games contained any of it. If sound then sfxr/bfxr I guess.

Since noone needs GUIs I will probably use vim/emacs/nano for coding (it’s fun to become used to the key commands – and to use the ones from the other program – always) and Firefox/python/pdb for executing and debugging.

All in all: Let’s have fun, have good ideas, make and kill bugs, draw graphics and create games!

Well, let’s ludum dare again!

Posted by (twitter: @YSelfTool)
Friday, April 25th, 2014 4:50 pm

Alright, it’s near to 2 am over here in Germany, I just did most of the weekly exercises-that-are-normally-done-during-the-weekend for the university, it’s something over an hour until theme announcement, and I finally decided to take part again!

This is somehow unexpected, I thought it would be like the last times, no time etc. But hey, it should work this time! Unlike my last Ludum Dares (#24? #25? or so) this time I will use JavaScript (and HTML5 canvas) instead of XNA, mostly because of the easy deployment of JS games, because it works on every platform and because I recently switched to Linux. (I was testing it and never went back… 😉 )

I could even stream the programming, even if not many may be seeing it, who knows.

So let me take some eight hours of sleep, and then… let’s program!

I/We am/are in!

Posted by (twitter: @YSelfTool)
Tuesday, April 23rd, 2013 7:02 am

After skipping the last Ludum Dare in December because of a lack of time, this time I will participate again!
After working alone for the compo the last April and summer this time I will probably work with two frieds, for the jam of course.

Which tools will we use?

XNA with C# as the language
Visual Studio Express (2010 or 2012) as IDE
Paint.net for images/graphics
sfxr for soundeffects
cgMusic or autotracker.py for music
Git for versioning

Let the games (programming) begin!

Finally, done

Posted by (twitter: @YSelfTool)
Sunday, April 22nd, 2012 12:55 pm

Finally, I am ready with my first LD game.

I did not need the full 48 houres, but more than I expected. I wanted to make a platformer, and there it is. It’s not completely what I have planned (e.g. there are no enemies), but I like it.

I planned on doing more animations, but my XNA-Frontend failed at it. And my xml-Model-Loading-Format was totally messy, blocky and made huge files, but I got ready.

It was a lot fun, and I liked the time (I never coded that much without a break :) )!

Now I know what to do next with my GL, but now I have to work for school and then fall asleep. :)

 

Thank you, everybody!

– YSelf Tool

[cache: storing page]