Sponsored By

In-Depth: Denki Talks Creating Games For 'No-Power' Systems

Ever tried to make a game for hardware that doesn't easily allow you to create and move sprites? Scottish development studio Denki (Go! Go! Beckham) tells Gamasutra how they used creative thinking to make fun set-top box games.

February 6, 2009

17 Min Read
Game Developer logo in a gray background | Game Developer

Author: by Richard Carr

[Scottish development studio Denki has concentrated on casual games for a variety of platforms. In this Gamasutra-exclusive article, design specialist Richard "Brek" Carr details the tribulations of converting a game for an unusual platform -- a satellite TV set-top box -- from an underpowered system to a criminally underpowered one, and the creative thinking required to arrive at the solution.] Denki has flown under the radar for the last few years, despite being one of the most prolific developers in what's now being called the 'casual' gaming market. Having worked almost exclusively within the digital interactive television market for the last eight years, after earlier handheld games such as Denki Blocks and Go! Go! Beckham, the company is now expanding into all of the new platforms and channels appearing on the market, with Quarrel due out on XBLA soon. For most of that time, Sky TV in the UK has been Denki's main partner, but in 2007 the US broadcaster DirecTV launched its own games service. Denki provided a number of games to DirecTV, both original and based upon some of the company's existing titles. One such project undertaken for DirecTV was a conversion of our Kingpin Bowling game, originally created for Sky. The DirecTV platform -- the set-top box -- was in many respects far more limited than the Sky platform. So rather than simply porting the existing game and trimming features, a number of fundamental aspects of the game had to be changed, creating what was essentially a whole new project. A ten-pin bowling game is defined by smooth movement and complex physics, so the prospect of converting an existing game, which both we and Sky were very happy with, to a platform with such tight technical limitations, was a daunting one. Yet after the dust had settled, we had created a game that was actually a lot more fun than the original -- despite the constraints. Why?

Above, Sky's Kingpin Bowling. Below, the DirecTV version. Initially, the most significant limitation was the movement of sprites, or rather the lack of it. The DirecTV platform did not appear to allow moving sprites at all. It took the programming team a great deal of technical thought to devise an ingenious method which would allow us to achieve sprite movement.

The off-screen buffer. Click for large version. The solution was to create a tileset by loading the relevant images to a set of VRAM tile buffers. These were then written into an off-screen buffer. The section we wanted to have the sprites moving on was written into this off-screen buffer. Then the images were assembled and written onto the allocated area in the off-screen buffer. Finally, the section of the off-screen buffer -- complete with assembled sprites -- was written to the screen. Lather, rinse and repeat for every frame. Simple! As is the way of these things, though, there were drawbacks to this process. The off-screen area is the same size as the display, which has to fit all the game sprites PLUS the area you want to allow the sprites to move around in. To compound this, the sprites must be arranged in a left to right formation, with the vertical sizes being equal on the same line. You can put smaller sprites in the line, but this wastes quite a bit of space. Both platforms -- the original Sky box and the DirecTV box -- are very limited in terms of their audio capabilities. The boxes can only play a single sound effect at any time. If a second sound effect is triggered while the first effect is still playing, the second sound either has to wait until the first is finished, or -- as is usually the case -- it simply doesn’t play, which meant that using audio only for critical feedback was not possible. The common perception is that the platform -- the set-top box -- is a standard platform. If only this were really true. Developing for digital TV is somewhat like developing for mobile, with multiple models, manufacturers and permutations of each device. For Sky, there are around 47 different box models and six manufacturers, ranging from 10 year old technology (the original boxes are still widespread), through to the brand new High Definition (HD) boxes. Each model varies hugely and has its own particular capabilities -- and weaknesses. Our games have to work on each and every one of them. However, budgets and timescales mean that making a separate version for each and every box is simply not commercially viable. This means we can’t take advantage of the specific strengths of the individual models, but instead have to focus on creating games which avoid each box's weaknesses. Thankfully, DirecTV have far fewer box models. However, their platform requires games to be programmed in a hybrid JavaScript/C language. As it is essentially a scripting language, this seriously limits the performance of the devices. To give you some idea of the context for digital interactive TV games, the size limitation for both platforms is approximately 500 to 600Kb per game. Average load time for a game on the Sky boxes must be within 30 seconds. Time varies due to the carousel delivery system, where modules are delivered on a constantly looping system. It's similar to the old Teletext system in terms of delivery. DirecTV commissioned Denki to make a version of the original Sky bowling game. The budget allowed for a strict six-week development cycle -- for a platform which at that point we were still exploring. It was obvious from the outset that the platforms were so different that we couldn’t repurpose the original game. However, the original Sky bowling game could be used as the goal for the project, despite knowing that we could not visually or technically recreate what was on the Sky box. The DirecTV platform has very limited memory available for graphical resources. This meant that there were severe restrictions on any type of "ceremony" (cutscenes, animations, scripted pieces, etc.) within the game. Instead of simply cutting these aspects, which would have left the entire game stripped bare, we decided to focus on the core action and 'feeling' of bowling within the game. This allowed us to ensure that achieving a strike within the game would still be a satisfying and exciting experience, which would look dramatic and dynamic even if the accompanying ceremonies were not present. The lack of available graphics memory and tight time constraints meant far less space and time available for structure and game modes. The original title offered a tutorial -- often critical for the mainstream audience playing digital TV games. However, time and graphical memory limitations simply wouldn’t allow any sort of meaningful tutorial. We therefore took the decision to use the far less glamorous -- but much smaller -- help page. This was kept as simple and straightforward -- with as few words -- as possible. This provided enough room to create the tournament structure. Time and space was still incredibly tight, however. We worked through every element of the design, removing non-essential polish, such as extra shirt colors: the player looked sufficiently different from their opponent to make this redundant. Everything else that was deemed non-essential was culled. Name entry was removed. Scrolling between the scoring and the play screen was removed. Pin positions were reduced from 16 to eight. The player animations were reduced from 31 to nine. On the original Sky platform, the player was palette animated, to allow a variety of shirt variations. This meant we could reuse the 31 frames of animation for every artificial player. On the DirecTV version this wasn’t possible, so we had to create a different set of animations for the opponent. This meant we ended up with two sets of nine-frame animations. Bowling animation frames were reduced to a smaller dimension size. This size had to stay the same, as anything unused was wasting valuable space. This meant the dramatic leg-out arm-upraised post-bowling pose was entirely out of the question. We had to compact these motions to remain within the maximum sprite size and still get across the dramatic action. The lavish ceremonies which were used to indicate strikes and fouls were stripped back. The number of trophies was reduced from five to one: three different sprites could be added to the trophy to make it look different, which saved a great deal of space in comparison. This allowed us to add animated sparkles to the trophy, adding life and splendor to an otherwise static screen. There was no space for another MPEG screen showing the scoreboard and frankly the load time for something that happens so often would very quickly become annoying for players. Coupled with this, there is only a single font on the DTV boxes -- and the font size isn’t consistent across all models. We had to make sure the differing font sizes of the different boxes would all fit within the scoreboard. It would have made more sense to create a dedicated font, but we simply didn’t have the graphics space for an entire bitmap font. So we chose a few key words for feedback in a bowling game -- e.g. Strike, Spare, Turkey -- and created nice graphics for those. By carefully removing the non-vital aspects of the game, it became apparent that we could create a bowling game using the given memory and within the limitations of the scripting language. So focusing on the core game we were sure we could pull something together... However, the control system on the DirecTV platform offered a significant number of challenges. The original version of the game used two factors to determine and simulate the ball behavior -- power and spin -- but the limitations of the DirecTV system meant that any complex physics were just impossible. The DirecTV game had to contend with the specification that there should be no after touch on the ball whatsoever. Digital TV games use the standard TV remote control for playing games. DirecTV remotes don’t natively support key-up detection. While it is possible to run a detection loop to check if the key is still being depressed, this introduces an extremely variable delay. So in practical terms, the game could not tell when the button had been released. This, combined with the specification of no after touch of course meant that a whole new control mechanism had to be designed.

A comparison of the controls on both sytems. Click for a larger version. The Sky version of the game allowed pixel positioning in placing the bowler. However, the DirecTV suffered both from the lack of native key-up detection as well as significant lag within the controller itself. These combined to make placing the bowler a hugely annoying experience. In order to avoid player's getting so frustrated they'd shoot their TV sets, we reduced the movement down to 11 fixed positions with the extremes at either side resulting in gutter balls. Part of the initial design process highlighted the importance of allowing the player to throw gutter balls, or play to fail -- as restricting them from doing so would destroy the consistency of the game to such a degree that it would feel 'wrong' for people. The original game's method of holding down a button to increase power was not possible thanks to the lack of key-up detection. Rather than try to create a compromise which would not truly reflect the player's reaction we decided to create a stepped continuous power meter. In this, the power of the throw increased and decreased using a sweeping pointer. This turned the power selection into a timing challenge for the player, while keeping within the technical limitations of the hardware. In the original Sky game, after touch was used to give the ball spin. In the DirecTV version, a spin bar was created. This provided the player with another timing challenge, which was consistent with the power controls. Although the selector here moved smoothly, the lag and poor response time of the controller meant that using a fine-grained set of values would have been very difficult. Testing proved that it was incredibly difficult for players to hit the required value with any sort of consistency. The underlying spin values on the meter were therefore created in five coarse bands; far left, left, straight, right and far right, although the selector moved smoothly. By implementing the five directional system, the delay in the controller response was negated and the player had a greater chance to select the desired spin.

The foul line. The original version of the game also included a foul line. This acted as another timing challenge for the player. The trajectory of the ball became straighter, the closer the player was to the foul line when the ball was released. Of course, if the player stepped over the line, then the throw was disqualified. In the new DirecTV game, further testing showed that thanks to the controller delay, the foul line became more of a frustration than a challenge. The decision was therefore made to remove this element entirely. The new control system was designed to ensure the player is not forced into a "respond now or fail" situation. Both the power bar and spin meter cycle up and down, until the player hits the button. The player can progress through the control segments at their own pace. They can wait, assess the situation, judge appropriate response and then play once they are sure of themselves. This lack of time constraint removes a great deal of stress from the player, is a lot more forgiving and has far more appeal to a casual market. The processing power and graphical limitations of the hardware also meant that the behaviour of the ball and pins -- the core of the game in other words -- had to be radically altered to ensure a (somewhat) realistic, consistent and satisfying experience for the player. As even vaguely experienced bowlers know, many of the more impressive moments in bowling are linked to spin. It increases the chance of getting a strike and is essential for picking up spares and splits. The design team faced a balancing act. The game had to allow extremes of spin and speed in order to maximise the fun of being able to bowl large, curving trajectories and straight, fast balls. From the initial design documents, it was obvious that the spin values had to be set so a player could bowl from the alleyway edge and spin the ball into the gutter on the other side before reaching the first pin. This set the upper limit on the amount of spin needed within the game. Combined with the power setting, this allowed players to achieve strikes and hit the various combinations of pins which can be left in the lane from a previous throw. Once the ball actually hits the pins, their behavior then becomes the focus of the game. With the limited resources available on the DirecTV set-top box and the timescale of the project, modeling real world behavior was simply not possible. While the platform would allow an approximation of realistic behavior, it would have required a great deal more time and experimentation to create appropriate techniques. However, by focusing on the creation of an enjoyable and consistent experience for the player, we created a means of approximating a strike in a way which gives the player feedback on their throw, while staying within the hardware limitations.

Pin angles. Click for large version. A coarse system was used to approximate the complex pin interactions. The pins were limited to eight possible directions. These directions were chosen by detecting the side of the pin where the collision occurred. This immediately allowed the majority of the directions to be discarded. A random selection was made from the remaining possible directions to determine the path the pin would take. This provided a random element so that the game was not totally mechanical and predictable. This in turn provided more long-term satisfaction for the player and ensured each ball could perform slightly differently -- just as it would in the real world. In this system, pin placement is vital. The pins have to be placed in such a way that they represent the correct ten pin setup. They also had to be positioned to ensure a strike could be achieved if the player hit the "pocket" (the sweet spot most likely to give a strike) despite being limited to eight directions. After ensuring it was possible to hit the pocket from multiple start positions and with various combinations of speed and spin, the next task was to make it possible to get strikes, spares, splits and more importantly, make it all dramatic, entertaining and FUN. In an attempt to recreate some of the more spectacular moments in bowling, the pin speed and deceleration were reduced. This created a slow motion explosion effect which helped to accentuate the pins sliding when hit. After much play testing the power required to make a pin slide into its neighbors was reduced. Modifying this set of variables allowed players to pick up spares and splits a little more easily and ensured even novice players could start picking up strikes, spares and splits fairly quickly. In the original Sky version of the game these moments were often lost or unseen, as the collisions, scattering and pin interactions were either over too quickly or were not pronounced enough to be appreciated by the player despite being more accurate to real world physics. After some careful redesign, we were able to create an enjoyable pin behavior that was realistic enough for players to accept, with a bias towards performance -- allowing players to achieve better scores than they might in real life. Careful play testing ensured that the variables were carefully balanced to allow players to use different run-up positions, as well as left and right spinners, straight bowlers and low, medium and severe spinners. This created sweet spots for each bowling position, balancing speed and spin, and with enough consistency they allowed a player to achieve many strikes in a row depending on basic ability with the control methods. The result of this redesign was a much simpler and more tightly focused game, in which the core mechanic was the most important part. The control mechanism was totally overhauled to create a new system which worked within the constraints of the hardware and still provided the player with a consistent and enjoyable experience, allowing for multiple approaches to bowling. Feedback from the customer and from consumers has been universally positive. Even among ourselves, the feeling is that the redesign had a positive impact on the game and the new version provides a more satisfying and fun experience than the original -- despite the greater limitations of the hardware. The technical limitations of the platform were a serious issue while designing and developing this title, but ultimately didn’t hamper the creation of a well designed and enjoyable game. The ongoing evolution of PC, console and even mobile phone hardware often means that hardware constraints are rarely an issue for developers. However, the discipline of designing a game for a limited platform forces a developer to give serious thought to the critical components of a game and how to implement them in ways to provide the player with the maximum amount of enjoyment. A great deal of the effort in the current generation of game development goes into aspects of the title which are window dressing or 'bells and whistles', rather than the actual player experience. Designing a game for a limited platform is not only a great exercise for a development team, but can often give real insights into how to take an existing product into a whole new area -- often with great improvements to controls and the whole user interface and experience. This approach could be summed up fairly easily: simplify and exaggerate!

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like