Nightfall as played by others

Playing your own game is totally different of seeing actual people playing your game. Fact.

The guys from TechValleyGameSpace have played Nightfall, and gave valuable comments about it. Remember, this is the jam version, we are working on the post-jam version yet.

Thanks Omiya Games for reviewing the game. Also, you can play Nightfall right here.

Nightfall: game developed for Ludum Dare 32

We managed to write a post-mortem about Nightfall, our Ludum Dare 32 jam entry. The theme was An Unconventional Weapon, so this is a simple game using the darkness as weapon, loosely based on Isaac Asimov’s Nightfall short story. See a fragment of the post-mortem:

What is the game about

You control Doctor Sheerin, a brilliant researcher who finds a new and amazing thing: The Darkness. But his new discover didn’t got the attention of the population the way he desire: they want to destroy it. People are afraid of The Darkness, since the planet they live is surrounded by light all the time at each single point of its surface. So Doc. Sheerin must protect the reactor, a huge machine that generate and nurture a practical gun that fire shots of darkness at things, reacting extremely weird at living beings.

You can continue reading the article on this link, and play the game on this one. We now will implement missing things and fix the so many bugs everywhere 😉

Nightfall
Game screenshot, as submitted for the jam

As a side note, we are now moving the code from Gitlab to our GitHub account. For the exactly code used for the submission, you can checkout the ld32 tag, but this does not contain the platform specific changes for the build (Linux, OS X and Windows).

bacon2d first release!

bacon2d first release!

Today is the day of the very first release of bacon2d. We are now preparing for a stable 1.0 very soon. As of 0.90.1 we have declared the 1.0 API as stable.

enter image description here

bacon2d is a Open-Source Qt5 framework to ease 2D game development, providing ready-to-use QML elements representing basic game entities needed by most of games.

You can contribute (and/or file issues) on the project GitHub page

Starting a SDL2 Game – Build system and main loop

Who we are

We are a team of three people (two developers and one designer) and we are working together for more than a year. We are not experts of the game dev world, we are just starting off and realized that developing games behind closed doors is not the way to learn and make progress. We want to receive feedback from the community, learn, and share our achievements and some useful resources.

The project

We decided to create a survival game using SDL and we’ll post small chunks of progress as the development advances. Each post should provide a gist that could be used to quickstart a simple SDL game. This first post only provides the basic structure to create a window and a gameloop. On the next posts we will begin to structure the game itself.

I’ll assume you know some C or C++ and you are new to game development.

Why SDL?

SDL is a powerful library, it provides access to all resources needed to create a game (input, graphics, audio among other things). It is cross-platform, runs in all platforms we want our game to run (Linux, Windows, MacOS, Android, iOS). It is simple, provides good documentation and there’s a good amount of successful games made in SDL. Just google it.

We could be using some game engine like cocos2d-x or Unity3D, but that would take part of the fun away. Also, we want to control as much as we can: Network, database, rendering, etc. It’ll take longer to finish but will generate subproducts we will use in other projects.

The gists provided in each post don’t represent the current status of the game – the posts are far behind our main code, but written in a way anyone could use them to start something.

We are working on a lot of stuff and we decided to open our development process to anyone that want to comment or use something shared by us, but most of it is incomplete, so we’ll keep the game source private until we think it’s good enough to be open-sourced.

We’ll post more details about the mechanics of this game in the game design section of our blog, right now we will focus in the code.

Get the code

You can view the gist at github.

To get and build it, run:

git clone https://gist.github.com/9259207.git somedir
mkdir -p somedir/build
cd somedir/build
cmake ..
make
./sdlsurvival

You should see a black window and the delta time being displayed in the console.

Build System

The build system is pretty small and straightforward:

It only set’s cmake version, main.cpp as our source and uses pkg-config to find SDL2 include and link directories to build our source.

Here’s our main:

Our game loop is a very simple one that only try to keep 16 milliseconds between frames.

Since our objective is to provide a gist to quickstart a simple project, I won’t talk about game loops, but here are three kick-ass resources on the subject:

Game Programming Patterns – Game Loop

deWiTTERS Game Loop

GafferonGame – Fix your timestep

First Steps Using SDL

The first thing we should do before using any SDL function is initializing it. In our code, we do this in line 12, calling the SDL_Init function. You should pass some flags to this function, telling what you want to use. We are just doing some rendering, so we’re passing just the SDL_INIT_VIDEO flag.

Next we want to create a window and a renderer. This is done in the lines 14 and 20, respectively. Line 14 creates our window and in 20 we create a rendering context we’ll use to draw our stuff.

Our game loop resides in the lines 32 to 59. There’s nothing complicated there:

In 35-47 we just poll for events checking if the user pressed <ESC> to exit the game.

We use SDL_GetTicks in 49-51 to get the time in milliseconds since SDL initialization to calculate the delta time, that is the time between the last frame and the current frame. We are just printing it, but later it’ll be used to update our game entities.

The lines 53 and 55 are used to clear the renderer (fill it with a color and start rendering into it again) and SDL_RenderPresent to show what we’ve drawn. In the current state, it’ll show nothing, but we’ll put all our rendering code between this two calls.

In lines 57-58 we check if there’s enough time between the frames. If not, SDL_Delay will wait until this is true.

The rest is just cleanup code and you can easily find out what each function does in the libsdl wiki.

Check this blog if you want to follow our progress