Stuff Tagged With "TWTPB"

I just got an email from Sony Computer Entertainment Europe saying they have checked out T.W.T.P.B. and they think it's "a strong candidate for development on PlayStation®." and that it "showed particular merit for evolving what is one of the industries oldest genres into something contemporary through its striking visuals and varied colour palette whilst also introducing an upgrade system that keeps the combat continuously interesting."

Actually quite flattering that they seem to at least have tried it out and that they like it

So what do you guys think? Would it be a good game for the PlayStation® Minis platform (i.e. PSP et. al.)?

I'm thinking of releasing the source code for my pc shoot em up game - T.W.T.P.B. under some kind of "free for personal and educational use". Do you think that that would be a good idea?

There will be some restrictions, since I don't want all of the code out there (copy protection, highscore stuff etc) but the bulk part of the actual game code would be released.

I've been asked some questions about game programming in general and about T.W.T.P.B. in particular, so maybe this could be a good contribution to aspiring game programmers.

Would a source release do any good? I actually think so, since the game is small enough for an "inexperienced" game programmer to dive into and possibly understand. Also we could do a forum section where I could answer questions and comments...

Anyway, what do you think? Should I release the source?

I just want to send a special hello to all Polish gamers playing our hard shoot em up game t.w.t.p.b.

A license to a special full version Polish translation was included in a recent issue of KomputerSWIAT, a leading polish pc magazine.

I think there have been some shifing in the twtpb highscores due to this. I'm glad you don't find the game too hard

Feel free to try our other games and join the community any comments are appreciated.

Game On!

Just some stuff I removed from the T.W.T.P.B. product page that could come in handy

8h game challenge

The first version of this retro shmup game was an experimental challenge to make a shoot em up game in eight hours. The version on hUb is still under development, but you can download the original 8h version and read about the challenge by following the links at the bottom of the page.

Old T.W.T.P.B. Screenshots

So it's already time to take a look back at the development of T.W.T.P.B. our frantic shoot em up game. I just can't believe that it's been more than 1.5 years ago since my create a game in 8h challenge and that the game is now finally finished. If you can say such a thing about a game. Going on 29 public iteration releases every 14 days. Feels a bit sad not to make a release this Friday...

These are my own thoughts and feelings about the development, what went right and what went wrong.

What should be repeated

Finish the game. I'm mighty proud that T.W.T.P.B. is finished. I believed in and saw my ideas through, did my best with them and delivered a final product. Finishing a project is hard, most of game development is transpiration, and a very little part is inspiration. If you start a project you should realize this... especially if you're an indie developer.

During the whole development I had a strong vision about what the game was about and the "lore" of the game world. This helped immensely in prioritizing, cutting features and simply making decisions about how stuff would work or look. Features that would have been "nice to have" could be cut since they simply did not fit the lore and my vision of the game. Even if much of this lore is not actually visible in the final product it helped keeping the product focused and "The game has a great, cohesive feel to it" as Michael Scarpelli at GameTunnel put it.

For once we have made a good looking game! Keeping the graphics simple, stylized and clean have been a success. I had the idea that I, as a programmer, should be able to produce all the graphics. Now I had great help from spjelk doing some very important things, like the ship model, but much of the game is actually "programmers art" and this can be pulled off simply because of the abstract style and focus on effects and a procedural look.

Some of the boss and level design is really good. I like how experience in playing the game matters a great deal and that knowing what to do and when to do it is paramount to success. It's not just "wave the wii-mote and watch that score go", this game is actually quite hard, and requires skill and practice. As it seems one of my strengths as a game designer is to be able to create that sense of flow. It is definitely present in both Time Breaker and in T.W.T.P.B.

On the technical side using a model-view-controller architecture alongside immediate mode gui and integrated game editors worked like a charm. One thing I tried out a bit was "immediate mode particle systems", that is particle systems that are reconstructed from scratch every frame and not a bunch of "active" particle objects that you see in common particle systems. This all worked our great!

This was also my first real project that used shaders to a greater extent. This was also a good thing, allowing for more per pixel control of how stuff gets rendered. By the way the shaders are free to use and abuse. I think the shader api is nice and mature enough to get used. One thing that irritates me is how textures are filtered and that you have no control on how the texture look up works. This makes it hard to use textures as lookup tables in some cases.

What should be avoided

Balancing the game and the abilities proved to be very hard. It's very easy to fall into the dominant strategy trap rendering all other abilites virtually useless. However, much is also up to how the player wants to play the game as such it's not a bad thing. Also since I lived with the game for such a long time some of the levels that I consider to be on the easy side are viewed as very hard. It's not easy to look at your game with fresh eyes. The community helped, but since there was mostly a few people involved that made their voices heard they also lived with the game for a long time.

My experiences of shoot em ups are mostly from the Amiga days, playing Xenon II, Sidewinder, Battle Squadron and the likes. I love shoot em ups, but I have not kept up with recent development in the genre. During development I tried to catch up playing more recent classics such as the excellent Ikaruga. But some decisions where made that could be considered bad design that has lived on to the final product. I should have taken more of a pause and studied the genre thoroughly before making decisions. This would certainly have helped with both marketing and getting the core shoot em up crowd on my side of things. You should simply play the games that stand out in your genre and know what is considered to be state of the art.

The keyboard and game-pad input took a lot of time and also are not that essential to the game as mouse is the premium way of controlling things. This time could probably have been put to better use.

Feel free to comment!

I just managed to create a new trailer and a bunch of new screenshots for our shoot em up game - T.W.T.P.B.

The trailer is a bit longer than the old trailers. Hope you like it and feel free to spread the word

In the latest download of our shoot em up pc game TWTPB, iteration 23, I implemented basic game pad support. There are a number of issues with this implementation maybe the most prominent one being that it does not handle plugging in and out the game pad during play. I think that it is probably a common scenario to plug in a game pad after the game has started.

This is a short tutorial on how to get your game to react when an usb device, such as a game pad, is plugged in or removed from the computer. This is handy when using the DirectInput api. XInput handles this in a transparent way which is nice, but alas there are many game controls that are not XInput compatible so when developing a pc game you probably need support for both plain DirectInput devices and XInput devices. This tutorial is Windows specific and in the C++ language.

It is not that hard to get a message when a device is added or removed, but it involves some rarely used win32 code that I spent a good few hour trying to get to work.

To start things off Windows sends you the handy WM_DEVICECHANGE windows message message when a device is plugged in or removed from the pc. So in your window message handling function you should have something like this:


WndProc(HWND a_hWnd, UINT a_msg, WPARAM a_wparam, LPARAM a_lparam) {
   switch (a_msg) {
       ...
       case WM_DEVICECHANGE:
           if (a_wparam == DBT_DEVICEARRIVAL) {
               // Device plugged in code goes here
           } else if (a_wparam == DBT_DEVICEREMOVECOMPLETE) {
              // Device removed
           }
       break;
       ...
   }
   ...
}


The there are also a number of other messages sent in the wparam parameter. So the tricky part here is that you won't get the DBT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE as a default. You will only get a number of DBT_DEVNODES_CHANGED messages whether a device is plugged in or removed and this is obviously not what we want in our game code.

You will have to tell Windows that you want additional information when a device is added. You can do this with the RegisterDeviceNotification function. This function is quite complicated and takes a number of strange parameters. I for one love when a function has a void pointer as a parameter, it's great, you can just send anything down there

Anyway the thing we want is to listen to in our game is the device broadcast messages. The following code sets that up. I added this to my window creation function since you need a window handle to the main window, declared as m_hWnd in the code below. The setup is actually much easier than you think by looking at the docs.


DEV_BROADCAST_DEVICEINTERFACE notificationFilter;
ZeroMemory(&notificationFilter, sizeof(notificationFilter));
 
notificationFilter.dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;
notificationFilter.dbcc_size = sizeof(notificationFilter);
 
HDEVNOTIFY hDevNotify;
hDevNotify = RegisterDeviceNotification(m_hWnd, &notificationFilter,
   DEVICE_NOTIFY_WINDOW_HANDLE |
   DEVICE_NOTIFY_ALL_INTERFACE_CLASSES);
 
if(hDevNotify == NULL) {
   // do some error handling
}


By using the handy DEVICE_NOTIFY_ALL_INTERFACE_CLASSES flag we can skip most parameters in the notificationFilter parameter except type and size.

Also for this code to even compile you also need to have WINVER defined >= 0x0500 like


#define WINVER 0x0500


Now Windows will send you all messages when a game pad is attached or removed from the pc and you can take the appropriate action in your game code.

Hope you'll find this short article/tutorial handy! Feel free to comment or suggest improvements.