Posts Tagged ‘spring up’

Video : Dynamic level demo and background effect update

Tuesday, February 23rd, 2010

The development of Spring Up XNA has been going pretty well last week.

Here is a new video, please note that it is still not the final art, just placeholders for now :

You can see the following:

  • New ways of using the physics engine in the levels (joints, gravity…)
  • Small improvements on the background : slight halo around targets, bloom reacting to matches, especially when hitting sparkling balls (the sparkling balls are part of a modification of gameplay from Spring Up PC/Mac. I will talk about it later. This is also the reason I cropped the borders of the video ;) ).
  • New particle effects (code in place, art also not final)

These days, I also implemented the sound effects (I just recoded the wavs available in the original version), improved the level editor, added many types of objects (bumpers, shrinkable balls, motors, splines…), added player score with statistics…

Globally, it’s going well, but I am having difficulties in level design. I find it very hard to innovate in each level but I still have a few interesting level prototypes in place.

Hope you like it!

Video : Level Editor

Tuesday, January 26th, 2010

I am mostly working on the level editor. I was not sure when I started this project that I would need a specific level editor. But Spring Up! X360 needs some serious changes in the level design to improve the quality and to adapt to the X360 platform, therefore I need this new level editor. Working on tools with C# is great : it’s really powerful and efficient! Technically speaking, the level editor is just a Game Component (DrawableGameComponent XNA class) of the Game. When the “Editor” component is created, all the new mouse and keyboard shortcuts are available.

As you can see in the video, here are some features implemented: create, move, rotate and delete items and targets. You can set up objects as static, dynamic or with a motor. There is also a snap feature. And as the game is running at the same time, you can play directly in the editor.

You can also see some of the new shapes that will be available in Spring Up! XNA : a triangle and pentagon.

That’s it for today, I hope you liked it!

Spring Up! XNA : first try at background effects

Wednesday, January 20th, 2010

I spend some time trying to create an interesting visual effect in the background of Spring Up! XNA. The backgrounds of the PC/Mac versions are not really nice. I tried to do something more abstract and animated depending on the flow of the game. Geometry Wars 1 and 2 did a very good job at that. While trying to develop an effect, I came up with many different results. I uploaded a video of one of this effect (you can see it in full res here).

Of course, feedback is very much welcomed (negative, positive, ideas…).
I personally have some concerns about a few things:

  • Black background, is it too simple?
  • When background is colorful, I think the player might not see the “real game” because it attracts the eye.
  • Colors are a bit too much “programmer art”. I made also some black and white tries that were nice too.

I have many variables available to tune this effect and each one of them really changes the final result. Basically, the algorithm here is a grid of particles that are animated and lit depending on the velocity and position of the moving elements around them.

I will also probably add thin trails behind objects. For boxes, I will try to attach multiple trails to  every corner.

I also have a bloom effect I did for fun before starting this project, I might try to add it in Spring Up!, probably on the trails, maybe on the background too.

Win/Mac and X360 differences (3) : XNA Content Pipeline

Wednesday, January 13th, 2010

In this post, I’ll talk about the XNA Content Pipeline. When I first tried to load a resource in the XNA game, I was trying to do as usual : opening a file and reading it using standard file reading functions. However, on XNA you have to use the Content Pipeline provided and to be honest, they have made a very good work with that. This pipeline can load some known file formats (jpg textures or wav sounds for instance) but you can extend the pipeline for your own custom formats.

I used many different types of file format for Spring Up!, for instance:

  • TGA for 32b images (I used TGA because it’s a very simple file format)
  • SWF for menus, level description and physics definition (ShockWave Flash, using the gameswf library)
  • WAV for sounds
  • OGG for music
  • Custom text files for translated texts and particle definition (called RSC and PRT)
  • Custom binary files for various data (DAT files).

The XNA Content Pipeline is really integrated into your XNA game project. You just add the resource to your project and when you compile it, the data is imported and converted in a XNB (XNA Binary File) using a Content Importer. This XNB file is generated for the right platform. It means you do not have to bother about little/big endian of the platform (Windows or X360). Once the resource is in your project, you create game objects with only one line of code. For instance, you can add a texture file to your project, and then load it using the following code:

Texture2D my_texture = Content.Load<Texture2D>("texture");

There are many file formats handled by XNA but when using specific data, you have to develop your own custom Content Importer. As told in a previous article, I will not port gameswf for many reasons so all the data I have in SWF files has to be included in another way into the X360 game. I started to include one of the most important data : the definitions of the levels. To do this on X360, I developed a quick XML exporter in the PC version of Spring Up! Then, I read the XML with my custom Content Importer. The XNA Game Studio then generates the XNB. The following diagram shows the flow of the data:

Data flow for levels data in Spring Up!
Levels data flow in Spring Up!

Now that my importer is in place, I can read a level definition using the following code:

LevelDef level = Content.Load<LevelDef>("level01");

And that’s it!

I have three importers already in place in the current version:

  • Sprite : binary format containing position and size of a sprite in a texture page. It was my first importer using XNA. It could (should?) have been XML. Original PC data was in the SWF, it is exported in binary from the PC game.
  • Level : position and type of items of the levels of the game. Original PC data was in the SWF, it is exported in xml from the PC game.
  • Physics : the definition of the physics properties of the items (size, shape, mass). This one is not completed yet, I still have pivots and joints to include. Original PC data was in the SWF (in actionscript code), it is exported in XML from the PC game, too.

If I knew from the beginning that the game would be developed on XNA, I would have done differently. The fact that I’m porting an existing product made me choose this solution of creating the exporters on PC and reimporting the data in XNA Game Studio. Ideally; I would have createed a level editor (with a Windows XNA project probably) saving data in XML. Then I’d use the content importer to put the resource in the XNA game and read directly the XML for a PC/Mac game (see diagram below).

Possibility for a multiplatform project
Possibility for a multi-platform PC/Mac/X360 project

As I plan to improve greatly the game, it is still possible that I will develop a specific level editor to be able to create new types of objects and physics items.

That’s it for my basic introduction to the XNA Content Pipeline. If you have any questions about the use of the pipeline, about importers or anything else, feel free to ask in the comments section below!

Win/Mac and X360 differences (2) : Screen resolution and aspect ratio

Monday, January 4th, 2010

The second “Win/Mac and X360 differences” post is about the aspect ratio and resolutions of the screen. This may not apply to all games as more and more casual games nowadays can be played on multiple resolutions included the X360 ones. However, I decided to write a post about it because that’s a problem I am facing at the moment.

Most PC/Mac casual games are only developed for a 4:3 resolution (640×480, 800×600 or 1024×768 generally). However, on X360, resolutions are mostly 16:9. In fact, the 1280×720 resolution is recommended by the XNA developers to ensure the game works on every video adapters. Spring Up’s resolution on computers is 800×600, and it will be 1280×720 on XNA, as shown on the first screenshot revealed last month.

Of course, there is a difference in the number of pixels, but the biggest problem is the aspect ratio (from 4:3 to 16:9). The following picture illustrates the problem.

aspectratio
aspect ratio differences

The blue sections represent the X360 screens and the green sections represent the PC screens. The first illustration shows how the 800×600 screen fits in the 1280×720 screen without any change of resolution. That’s the easiest way to do and what I did for the first screenshot of the game. Basically, you don’t change anything, you just render your game in the center of the X360 screen.

On the second illustration, the PC screen is enlarged so that it fits with the height of the X360 one. This is a 1.2 scale that transforms the PC screen in 960×720. You can see there are blue portions on the sides. That’s what Peggle did (see XBLA screenshot). They just added some (useless?) stuff on the sides to fill the gaps.

There is a third solution that scales the PC screen so that the left/right borders match with the 1280 width of X360. This is a 1.6 scale. In this case, some pixels are lost on the top and bottom if you keep the 4:3 aspect ratio.

I do not want to scale the objects of the game (balls, fans, launcher…) because I prefer pixel perfect sprites (one pixel of the texture is exactly one pixel on the screen). Consequently, in Spring Up!, I will probably move the items that compose the levels so that I take up more space on the screen. A good point to this solution is that it will contribute to correct one problem of the game stated earlier: objects will less likely be stuck due to extra spacing between targets.
I will also tweak the level design to “fill the blanks”, mostly on the left and right sides.
As the background is made up of tiles of 100×100 pixels, I just have to draw more tiles so that’s not a problem.
The walls will of course need to be moved to the sides of the screen.

Another detail that sometimes bother people that don’t think about it right from the beginning is the “title safe frame”. On X360, it is required that every important instruction on screen is displayed in the inner 80% of the screen. In 1280×720, that is 1024×576. On Win/Mac, I have many important information on the borders of the screen (bonus bar, score, level). I will need to change game design here to pass this requirement. I keep that in a corner of my head for the moment and will decide how to do it when working on the UI.

That’s it for resolution and aspect ratio, feel free to comment!

And happy new year! ;)

Win/Mac and X360 differences (1) : C++ and C#

Monday, December 28th, 2009

I will write a series of posts about the differences in developing for Windows (or Mac) and working for X360 with XNA Game Studio.

The first post of these series is about the most obvious difference : the programming language.

code

All my PC and Mac games were developed in C++ because that’s the language I’m most efficient with. I developed in C++ for years. Retail X360 games are mainly developed in C++ too, but to work with XNA Game Studio, you have to use C# and the XNA Framework. C# was new to me, but it’s easy to learn when you know other objects-oriented languages.

XNA Framework is also offering a lot of interesting libraries to help develop games. For instance, here are a few libraries I used on PC and Mac that are provided by the XNA Framework:

  • 2D rendering : I used Popcap framework (Win) and SDL (Mac). XNA provides easy ways to draw sprites using the SpriteBatch class.
  • Audio : I tried Audiere in my first Windows games and now I use SDL_Mixer (Win and Mac). XNA uses SoundEffect and Song classes.
  • Game management : I used in-house code, XNA provides various helping classes (Game and GameComponent for instance).
  • Math : I developed my own functions in C++, XNA has all you need (2D/3D Vectors, Matrices…).
  • Input : I used specific Win32 and Mac functions in C++. Once again, XNA provides easy classes to deal with input (Keyboard, Mouse and GamePad classes). Of course, inputs are different on computers and X360 console. More on this later ;)

But there is still many code to rewrite when porting the game. For Spring Up! there is obviously all the game code, and the physics engine. I am also using gameswf (a flash library) to draw all the UI of the game in Win/Mac. I won’t try to port it to X360 for two reasons : 1) it’s a lot of work, and 2) the UI I made with gameswf must be used with keyboard/mouse. I will probably have to write specific UI code for X360.

C++ code that is not platform specific (like game code or even the physics engine) is quite easy to port. Here are the few adaptations I have to make:

  • No pointer in C# (well, except unsafe mode but I don’t use that). Basically, it just means removing *’s ;)
  • No delete. You have to trust the garbage collector. For now, it’s working smoothly but I’ve read some people are having troubles with that.
  • No include files : that’s awesome! One file only per class is handy.
  • No STL (even though I don’t use them much) : C# lists are very handy, better than STL and the syntax is also easier to read.

When I have big functions to port, I basically copy and paste the code from C++ to the C# editor, and modify what needs to be modified. Quick and easy. So far, it went pretty smoothly.

Feel free to comment!

First Screenshot of Spring Up! on XNA

Tuesday, December 22nd, 2009

Here is the first screenshot of Spring Up! XNA. It was made using a windows build of the XNA project.

First Spring Up! screenshot
Click to Enlarge

This screenshot was taken two days ago, just before starting to work on the game and physics code. Here, the rendering components and textures are properly imported to XNA. Background generation is using RenderToTexture (it was a software generation of a texture in Win/Mac). Game items are properly displayed, with the launcher and receiver in place. It is clear that I will have to make choices to handle the difference of resolution (from 800×600 to 1280×720).

So this was quite fast, and I don’t think I will have much trouble with the game specific code. However, I am already having difficulties with the physics part. And with Christmas coming very soon, I will probably not spend a lot of time working.

If you have any questions/remarks, feel free to comment!

Using (bad) reviews to improve your game

Friday, December 18th, 2009

I’ll port Spring Up!, but it won’t be an exact copy of the game. I will spend time to fix some problems people have seen. I could not afford many tests when releasing Spring Up! for Mac and PC. I only saw a few people playing the game before the release. Now that I’m making this game once again, I look back at those reviews carefully.

I could find 7 interesting reviews. Four of these reviews comes with a grade, here are they, in decreasing order:

There are also 3 reviews without grade, at macupdate.com (small user review), softpedia.com and meryl.net.

Of course I read them all carefully, and some problems where recurrent among reviewers, here is a small list, with the most important problems on the top:

  • no way to lose / lack of challenge
  • no reward for difficult shots
  • ugly/utilitarian graphics
  • multiplier too easy to increase
  • levels are too long, boring near the end of the levels
  • not enough different power-ups
  • repetitive music
  • some bad sound effects
  • adventure mode not really useful, need story, garden is useless
  • objects can be stuck and don’t always fall at the bottom of the screen.

Well, it’s already a huge list of problems. I won’t fix all of them, but I’ll certainly take these reviews into account when doing the XNA port of Spring Up! I may not be able to invest much more money to improve graphics and music, but level design, game design and the physics engine will probably be improved.

There is often a debate whether a bad review is better or worse than no review. I think a bad review is better. Not to sell the game, but to improve it.