Just Don't Die

Map making

Fri, 06 Nov 2015 21:17:00 +0000

Sooo… I started making maps for my program. Just figured out how hard that is. I don’t want a bunch of text that the player is forced to read when he is playing the game. Rather I want him to learn by ‘accident’ which is not as simple as I thought. That and my Gimp skills aren’t the greatest. Makes me wish I had an artist that would work for me for free.

I guess I will get back to you with more info once I have some more info.

Reset, map making and windows compile

Mon, 26 Oct 2015 23:41:00 +0000

So, last few commits have all been about fixing the reset command. I recently added an object known as the GameStateController which is intended to handle what state to render (eg. Splashscreen, loadingbars or actual gameplay). Once I built it I moved all the current game setup code from the main method of the program to this new class. It worked like a charm and Valgrind reported no leaks.

However a few hours later I noticed that the games memory would increase slightly every time I triggered one of these reloads. Naturally this would be because of some data container that loaded, held and disposed of data in a nice way at exit but wasn’t cleared on every reload thus stacking the same data repeatedly on every reset.

It took some searching to find it. Turned out it was the ResourceContainer doing what it was created to do but not in an efficient way.

Whilst looking for it I learned of this command to track memory allocation during runtime of a program.

valgrind --tool=massif <executable>

I never got super much use out of it. But it’s definitely going in the pile of good things to know when debugging C/C++ programs.

Compiling for windows

The next big thing was re-testing the windows compile. I’ve gotten this working previously but the executable would never start properly on windows and I had no clue why. Turns out running the .exe in wine gave me a lot more information and the solution was to copy some more .dll files into the distro folder.

I haven’t tested it on actual windows yet. But I’m hoping that getting something to run under wine should be a good indicator that it will also play nice on windows (knowing my luck this will turn out to be completely wrong once I test it).

The only issue that remains with the windows .exe that I’ve noticed now is that random doesn’t seem to work the same way on windows as it does on linux.

The following code seems to be missbehaving. Once I confirm it on windows and solve it I will make a post on what I changed.

#include <random>

int getRandomBetween(int a, int b)
{
	std::random_device rd;
	std::mt19937 gen(rd());
	std::uniform_int_distribution<int> dis(a, b);
	return dis(gen);
}

If I’m really lucky it’s just wine messing it up and not actual windows. According to the MSDN page it should work as expected on windows as well. But when does that ever happen?

The next step

I’ve started working on some map sketches in my notepad (I heard this was a good way to start). I’ll try to get the 3-6 first maps created and after that I’ll try to force some friends to beta-test the game at their leisure. I’m thinking of having a sort of learning focus on these first maps. Challenge the player with basic mechanics forcing him to learn what to do and what not to do as he plays along. Examples are, ghost mode, falling death, spikes, double-jump and the boost powerup.

Travis.ci

Is still broken for my project with no new information to ad.

Travis CI

Mon, 26 Oct 2015 00:15:00 +0000

So, travisci’s new update for building just ruined my night. Code is fine, Travis just doesn’t know it yet.

I’m tired and going to bed. Travis is great but it’s hell getting it configured. Especially since the PPA’s for SDL2 aren’t whitelisted and neither is the libsdl2-mixer-dev package. The ppa was already issued so I added my ‘+1’ of power among the comments. The package I created an issue for. Until both of these get through I guess my inbox will be spammed by travis stuff.

Goodnight…

Let's get ready to rumble!

Sun, 25 Oct 2015 21:20:43 +0000

Ok, here we go. I created this blog for my game mostly so I’d have someone to tell about what I just did and what my plans are. Not that anyone is reading it right now but still. If someone does it will look pretty serious. I also think it will help a lot with development if I write down my ideas and plans. That way I get some free project notes and documentation that I can look back on.

Current status

I’m pretty happy with the flatlib. It’s requiring very little updates or code commits lately and my main focus has been able to stay on the actual game code. So far it looks like the game will be similar to Super Mario and Super Meatboy. Just google those if you don’t know what they are. Although, if you don’t know what Super Mario is, very little in this blog should be interesting to you.

The game at least runs pretty smoothly now. I made some optimizations to the input handling so that all objects are no longer checked on input events. Not sure if it helps much. Although it should, it might be a good idea for me to put some time into debugging of the game. Creating good outputs so that I can monitor what’s going on in different places. Benchmarking functions should probably be the first step.

Tip of the day

This project is awesome and Casey is a brilliant coder and teacher handmadehero.org