Showing posts with label game development. Show all posts
Showing posts with label game development. Show all posts

Sunday, March 14, 2010

InstaPyGame progress report

I spent the last three days working on a prototype "space shooter" module for my InstaPyGame framework. I had hoped to have a prototype ready today, but the framework isn't usable yet. You can see my progress so far at my Google Code repository, but be warned; the code is messy and inconsistent, and nothing is set in stone.

However, I have created an API with which I'm satisfied. Making the sample below work properly is my goal for this prototype.


from insta.spaceshooter import *

def startDemo():

    game = Game(640, 480)
    
    player = Player()
    player.setSprite('resources/ship.gif')
    
    player.when(player.moving, 'left').setSprite('resources/bankingleft.gif')
    player.when(player.moving, 'right').setSprite('resources/bankingright.gif')
    
    shot = Shot()
    shot.setSprite('resources/shot.gif')
    
    player.setAmmo(shot)
    
    enemy = Enemy()
    enemy.setSprite('resources/alien.gif')
    
    boss = Enemy()
    boss.setSprite('resources/angryalien.gif')
    
    mapGen = LevelMapGenerator({'0' : None, '1' : player, '2' : enemy, '3' : boss})
    
    level = Level(mapGen.generate('data/levelmap1.txt'))
    level.setBGSprite('resources/space.gif')
    level.setBGMusic('resources/spacemusic.ogg')
    
    game.setLevels([level])
    game.start()

if __name__ == '__main__':

    startDemo()

Right now, I'm working on the event system and the controls, but the event system appears far more challenging. I'm planning to encapsulate the data for the "Player" and "Enemy" objects within another object, protecting the data behind its member functions. This should allow me to create a special data object that will apply its changes only when a condition is fulfilled.

Although the framework is far from complete, I'm excited about the possibilities. I have plenty of work ahead of me, but I think my goal is worth the effort.

Sunday, March 7, 2010

GSoC project idea: Insta-PyGame

I'm still trying to choose new GSoC organizations to join, but I know one of the organizations to which I'll apply: PyGame, the SDL-based Python multimedia library. I plan to write a micro-framework on top of PyGame to dramatically simplify the creation of conventional games.

The Problem

PyGame is a wrapper for the C SDL library. Some of the library hides the complexity of the underlying SDL library, but in most areas, PyGame is simply a Python binding for SDL. For that reason, you often need to write several lines of code to accomplish a simple task, such as checking whether the user has pressed a button. In addition, many pieces of the API are based on C coding idioms that are unfamiliar to most Python programmers.

The Plan

I propose the development of a new framework on to of PyGame that operates at a much higher level of abstraction. Through this new framework, people would create games by declaring the sprites the characters use, the arrangement and graphics of the levels, and the interactions between the player and the contents of the levels.

The framework would be divided into modules with each module representing a genre. The "platformer" module would contain everything necessary to create a platformer game, including a physics engine, a tile map engine, and enemies that die when you jump on them. In contrast, the "scrolling shooter" module would contain tools for controlling the behavior of projectiles and enemy ships.

Here's an example of the type of code games using the framework could look like. I haven't put much thought into the API, but I would like game code to be written at this level of abstraction.


from insta.menu import *

from insta.platformer import *



def startMenu():

    titleScreen = Screen(600, 400)
    titleScreen.setTheme(themes.MEDIEVAL)
    titleScreen.setTitle("Porcupine's Tiny Adventure")
    titleScreen.setOptions(["Play", "Controls", "Credits"])
    titleScreen.getOption("Play").setAction(startGame)
    # More code for other menu options

def startGame():

    game = Game()

    hero = Player()
    hero.setSprite("standing.gif")
    hero.setRunningSprites(["running1.gif", "running2.gif", "running3.gif"])
    hero.setJumpSprite("jumping.gif")
    hero.setDeathSprite("gravestone.gif")

    hero.setMovementTriggers(constants.ARROW_KEYS)
    hero.setJumpTrigger(constants.SPACE_BAR)

    goal = Item()
    goal.setSprite("bigring.gif")
    goal.setBehavior(constants.FLOATING)
    goal.setAction(game.nextLevel)

    itemGenerator = ItemGenerator([None, goal, hero])

    '''
    Tile generator translates level maps (text files full of numbers) into tile
    maps in a context-sensitive manner
    '''
    tileGenerator = TileGenerator()
    tileGenerator.setFloorSprite("levelground.gif")
    tileGenerator.setUndergroundSprite("underground.gif")
    tileGenerator.setPlatformSprite("platform.gif")
    # Edge and corner sprites could also be set

    mushroom = Enemy()
    mushroom.setRunningSprites(["step1.gif", "step2.gif"])
    mushroom.setDeathSprite("explosion.gif")
    # Some simple behaviors would be pre-defined
    mushroom.setBehavior(constants.WALKING)

    bird = Enemy()
    bird.setFlightSprites(["flap1.gif", "flap2.gif"])
    bird.setDeathSprite("feathers.gif")
    bird.setBehavior(constants.FLYING)

    # List associates enemy types with numbers in the text file
    enemyGenerator = EnemyGenerator([None, mushroom, bird])

    level = Level()
    level.setTileMap(tileGenerator.generateTileMap("levelmap1.txt"))
    level.setEnemyMap(enemyGenerator.generateEnemyMap("enemymap1.txt"))
    level.setItemMap(itemGenerator.generateItemMap("itemmap1.txt"))

    level.setBackground("background.gif")
    level.setBackgroundOptions([constants.TILED, constants.PARALLAX])

    game.setLevels([level])
    game.start()

if (__name__ == "__main__"):

    startMenu()

The Goal

I want to free PyGame developers from thinking about the hows of game development, allowing them to focus on the whats of their ideas. By freeing game creators from thinking about the implementation of their games, I hope to allow them to explore new ideas in video game design, such as dynamically-generated levels, media mashups, user-created content, and AI.

This is just a rough outline of the framework I'd like to build and the effects I hope to see. I plan to start work on a prototype soon if the PyGame community appears receptive to my idea.

Sunday, September 20, 2009

Scribblenauts: Accomplishment and potential

Although Scribblenauts is a terrifically fun and shockingly innovative game, its concept is even more compelling than its gameplay. Scribblenauts is a new game for the Nintendo DS in which you solve puzzles by summoning and using items. If your goal is encased in a block of ice, you could break the ice with a hammer, melt it with a flamethrower, or detonate it with a grenade. The game's hook is that you can summon almost any item imaginable.

Hidden machinery

Of course, the game is phenomenal, but the technology behind it is even more impressive. 5th Cell, the developers of Scribblenauts, managed to cram tens of thousands of interactive, animated characters and items on a tiny DS cartridge. On top of the actual pictures, they programmed in complex interactions between the items. For example, a toaster will turn bread into toast; monsters scare and attack people; cops shoot criminals and chase donuts; and beavers gnaw down trees. This game's backend is completely unprecedented.

Unlimited Possibilities

Imagine if the contents of the Scribblenauts asset database were accessible to all game developers. Designing a traditional game would be a breeze: lay out a level, populate it with items and characters, and show the player an objective. However, giving developers (and players) instantaneous access to a massive library of items would create entirely new gaming possibilities. An RPG could allow players to equip their teams with typical household items with different strengths and weaknesses. A point-and-click adventure could use the sprites and interactions to let the player pick up literally any item in a room and use it in the game. A platformer could use the vast selection of items and characters to make each level a unique experience. A universal resource database could fundamentally change process of creating and playing games.

Making the concept a reality

Thinking about the possibilities if the Scribblenauts database was open is entertaining but unproductive. In order to give developers and users the power of instant item creation, steps must be taken.

  1. A lightweight format for interactively animated sprites must be established. Whether it's a particular arrangement of sprites on a sheet or an XML dialect for defining how a character's parts fit together and interact, there must be a standard for people to follow.
  2. A central database must be created to systematically store and retrieve the standardized sprites. It must be easy for people to contribute, but impossible for someone to damage or corrupt. The sprites and their interactions must be version-controlled.
  3. Developers must have access to the database from their games. Web-based technologies could access the database directly, but pc-based games should be able to use a copy of the database. It could be optimized and compressed, or developers could simply "check out" the portion of the database they intend to use. Perhaps, when a game using the entire database is started, it could check to see if any new items have been added to the database.

Conclusion

The game Scribblenauts is an enormous accomplishment, but it could be so much more. The technology behind Scribblenauts could revolutionize the resource management of game development, tearing down barriers for both designers and developers to create experiences. Nevertheless, in order for that to happen, 5th Cell must release the Scribblenauts' resource database for non-commercial use, or the independent developer community must unite to create their own asset database.

If you'd like to support the developers of Scribblenauts (and me), you can buy Scribblenauts for yourself.

Thursday, August 20, 2009

Pygame2 example game finished

Early this summer, when my Google Summer of Code proposal to the Pygame project was rejected, I told the coordinator that I would nonetheless contribute to the project over the summer. I planned on writing examples and tutorials for the Pygame2 multimedia library. Unfortunately, events conspired to prevent me from writing the examples. I had tremendous difficulty installing Pygame2 properly and no time to find the problems: I finally overcame my installation problems only two weeks ago.

Composite screenshot of all four skins Four graphical skins for your gaming pleasure!

However, I spent a great deal of time over the last week writing my first example for Pygame2. It's based on the oldalien.py demo distributed with the original Pygame, but I greatly expanded its scope. I tried to demonstrate as much of the library as I could, but I ended up using only a sliver of the library's functionality. The finished example demonstrates Surface handling, vector drawing with pygame2.sdlext.draw, text rendering with pygame2.sdlttf, image loading with pygame2.sdlimage, and sound effects with pygame2.sdlmixer. It's not an exhaustive demonstration of those concepts, but I think it's a good starting point for exploration of the library.

In addition to showing off the Pygame2 library, I tried to demonstrate best practices. I encapsulated the object instantiation and sprite drawing in external factories, allowing users with incomplete installations of Pygame2 to still see parts of the example. I only have to switch factories to drastically change the look of the game. Most importantly, I expunged the global variables from all the classes. The game still uses a couple long-life variables, but I eliminated the unnecessary ones.

If you'd like to see my uber-example in action, you can get it from its SVN repository or download it as a .tar.gz archive. If you have any trouble with the game, let me know.

Friday, August 14, 2009

Need app developers? Give them respect.

According to Engadget, both Microsoft and Sony are attempting to lure iPhone developers away from the platform to develop apps for the Zune HD and the PSPgo, respectively. Allegedly, Sony is just asking developers to convert, but Microsoft is offering cash to defecting developers.

However, I don't anticipate that either of these strategies will attract many high-quality developers. Switching platforms is a major change that requires a great deal of time and effort. More importantly, the developer has to believe that there's a future for the platform.

Nonetheless, I believe that both companies could foster development environments as fertile as the Apple's by dropping development barriers and treating developers with respect.

Break down development barriers

Many great app developers have never written an app. Some don't have the cash to buy Macs and pay $99 to get their developer certificates from Apple. Some don't consider the investment worth the money. Some don't know how to develop an app. Whatever the reason, there is a large pool of potential developers who have never made it over Apple's speed bumps.

Sony and Microsoft need to make it free and easy to develop an app for their platforms. The SDK should be free, open-source, and cross-platform. It should be completely self-contained, but it should also be compatible with a major IDE. It should contain a thorough tutorial that takes the new developer from project creation to final compilation.

When it comes time to publish an app, the developer should pay less than fifty dollars to make the app available for purchase and absolutely nothing from that point on. Developers should be able to set their own prices and the platform should charge < 30%. If an app is free, the developer should not be charged when it is downloaded.

Respect developers

Both Sony and Microsoft should capitalize on the current uproar about Apple's opaque and draconian app screening process by making their app screening as transparent and inclusive as possible. The application rules should be straightforward, comprehensive, and accessible to developers. Before the developer even downloads the SDK, he should be shown a summary of the rules.

Every developer whose app is rejected should receive a thorough and specific explanation. The app reviewer should say which rule the app broke, which part of the app broke the rule, and what can be done to fix the app. If the app store doesn't have the time to write these explanations, it's obviously rejecting too many apps.

Apple's iPhone development environment has its weaknesses, but to focus on luring away its developers with cash would be short-sighted. Sony and Microsoft must build their developer base with App Store cast-offs and new developers before they can offer the massive install base of the App Store. They need more than a just few money-motivated iPhone developers to launch their platforms.

Wednesday, December 17, 2008

Leave the physics to me!

I'm finally "done" with my AS3 game engine now. It doesn't play music, support sound effects, or use character animation at all (okay, maybe a little), but it doesn't try to. I'll give you an example of how it would work.

First, you'd have to download the file. Then, you alter the levels.xml file with to point to the levels' background images and ground profiles. You add the enemies with the <enemy /> tag, the player controlled character with the <fighter /> tag, and the goal with the <goal /> tag. You can alter the position of the fighter, the goal, and the enemies and change the background image and layout of the level without even recompiling the code.

To add a character, you do have to start up flash, but you don't have to do any real coding. Simply make a class for your character in the com.flashgames.bunnyhopper file, set the max speed, jump height, and acceleration through simple variables, and associate the class with a library object. Now, you can add your character to the level by simply altering the levels.xml file.

It's not the most sophisticated game engine, or the most open-ended, but anybody (with flash) can easily reshape the game with a little HTML understanding and little-to-no programming knowledge. Let's see you do that with APE or Box2D!

Play a quick demo or download the source.