Home » 2013 » May

One thing at one time.

I decided to do more often, but shorter sessions. It suits these short free time gaps I have lately.
These last sessions were another Refactoring ones with aim of extracting functions, so one could do only one thing, instead of all purpose procedures like DeleteSpritesAndFonts(), or two purpose DrawScene().

Soo little changes list:

-> Cutted PrepareSpritesAndFonts() and DeleteSpritesAndFonts() to four functions:
PrepareSprites, PrepareFonts, DeleteSprites, DeleteFonts.
Now all that’s inside PrepareSpritesAndFonts is:

bool Game::PrepareSpritesAndFonts()

	if( PrepareSprites())
		bool ret = PrepareFonts();
		return ret;
		return false;

I think it looks better this way. Now it’s easy to tell what’s really inside, and extracting DeleteSprites() helped to delete redundant cleaning after failing with preparing fonts.

-> Also I properly named arguments in headers, so that intelisense can help what’s the meaning of what variable passed to methods (yeah, the fact I haven’t done it at the begining sucks).

-> Bid farewell to victory, running and pause variables, and welcome our new datatype GameState enum! Now with all new Defeat state.
Although it was a little confusing to replace them at first, because of

   // Loop with redrawing and listening to keyboard events

loop, that created a little confusion. If I’d replace ‘running’ with a condition like (gameState != Victory && gameState != Defeat) it’d be confusing. Why game should run in paused state, but should not in Victory, nor Defeat?
After putting some thoughts I decided to make while a simple infinite loop with breaks after goint into Victory or Defeat. I bet it’s still far from perfection but I like it. For now.

-> Extracted “DrawPause()” from DrawScene – it was unnecessary to check all the time whether game is running and then if it’s paused.

-> Probably it’s a bit obvious, but al_flip_display() can be called only once. It’s unnecessary to do something like that:

	if (gameState == GameState::Running)
	else if (gameState == GameState::Pause) 

with ending all procedures with al_flip_display. It’s enough to call it at the end of Draw calling function.

-> Slight renaming. Variable Hp is now known as Lives, and pong is now a pongSprite.

As always you can find changes in repository.


Someone might think that three day week is a thing easily done, but sometimes everything just happens at the same time. One university project after another and carring out duties. I’m really glad it’s over for now, but I fear that I won’t have time in may to perform a long coding sessions.

For now I simply standarized language used in naming classes and variables. Until today it was (as you could see) little messed up with english names (classes, most of function names and variables), with polish (mainly translation of english names).

And so changes for today’s short session:
-> A Game class object name changed from gra (polish for ‘game’) to App.
-> List of brick objects name changed from kafelki (polish for ’tiles’) to Bricks.

Also I reviewed most of code, and got a basic idea what should I change to improve quality of the code.

Hope to code it soon (:
Also those (rather slightly) changes are in repository.

Make it mantra.

Fellow programmist on polish gamedev site Warsztat once writed an advice for beginners about three steps in programming:

Make it -> Make it work -> Make it work well.

The first step Make it is simply about making it work. It’ll can (and probably have) bugs, there’ll be errors, but it shows how you approach a problem. You make drafts and prototypes at this stage.
Second is to Make it work, it’s all about fixing problems, and taking care of boundary conditions. At this stage we want to create something that works perfectly with given assumptions.
Last but not least is to Make it work well, and that step is all about optimalization, fixing and tunning app for proper customers. This step finally results with a stable relase.

I still don’t know exactly where refactoring should be made when taking these steps (so I assumed that it should be done all time), but Pongoid I showed yesterday was clearly still in first step.

For those who didn’t check the commit, there are several bugs with phisics listed down:
-> From time to time ball goes inside a paddle and oscillate over the entire length,
-> It looks like bricks dissapear on they own if ball hit it’s two neighbours (maybe from fear, but it should not happen…)
-> I’m not sure if ball bounces in correct way all the time.

And code is organized inside 3 classes:
– Game that manages all input events, logic and so on.
– Item, who controlles both paddle, and ball.
– Brick derived from item to controll many bricks in field.

Goal for another few code sessions is to finish second step of game mechanics.
Fix physics problems, and clean up code.

A new begining.

Soo… hello.

The sole reason for creating this developement blog was to widen audience, whom can read my thoughts and ideas. For the time being ideas for One game a month challenge, maybe from time to time about past projects done for graduation. Time will tell what exactly you’ll find on this devblog in future (:

For the moment:
Here is a link to repository with a Pongoid, simple (done in a ~1 hour) arcanoid clone done with cpp and allegro library.

It’s still more a draft than finished project, so I didn’t uploaded it to ogam yet, but… maybe in a few weeks after exams (: