next »

[Lynx]

Well, I'd intended to wait until I had more to show, but I wanted to document that I've been working on a Breakout-Shmup mashup since before Alex Weldon mentioned the idea.   So this is what it looks like so far.



Right now I have two classes of enemy ships, frigates and destroyers.  The enemy on the right is a destroyer.  There'll be more - lots more - as I work on it.  I may allow the paddle-ship to gain special abilities that will drain its energy bar, and I probably will add power-ups that you can pick up to recharge energy (left blue bar) and life (right bar).  Energy regenerates slowly.  The enemy shoots at you though, so you can't just sit in one place and recharge.

'Make Breakout' everyone said, in order to practiceyour initial game developmentskills.  They were right!  I've learned a lot doing this so far.

It'll be a story-based shmup, so I've got to work on the characters, story, cutscenes, level editor, lots more stuff - but it will be a great way to master the art of game development.

[moi]

awesome, reminds me of

[Lynx]

I did give some thought to having the bricks rotate around the enemy ships.   

This Unity 2.5 business is tempting, but I think I'd better finish this project before I start investigating another technology.  Currently I'm using pyglet for the basic OpenGL/Python library, rabbyt for faster sprites, and Lepton for particle effects.

Pondering special abilities...  So far I figure that you should be able to put up a shield, because when there are multiple enemy ships on the screen all firing at you, it can be pretty harrowing to try to avoid all the bullets while diving to catch the ball.  Shots impacting the shield would drain your energy, and when you're out of energy, the shield drops.  But you also need the energy to fire a new ball, if you lose the previous one.

[Lynx]

Nothing to show as yet.  Milestones achieved so far:

* As seen above, I have a working prototype.

* Wrote up the game script.  It'll have 14 missions, with intervening cutscenes.

* Primitive GUI for use in making the level editor.  Besides the scrollable menu and file browser I already had, I added text entry boxes and clickable buttons.

Currently working on "Squish".  This is intended to be a utility which will allow me to build starships in Google Sketchup and turn them into sprite bitmaps, plus normal maps so that I can add lighting to them.  The difficulty comes in that there seems to be no standard 3D object library for pyglet, and no standard Collada file importer, so this will be interesting.

If I didn't care about reusable code, I could just hack the levels out by hand, but the experience building an editor will be good for me.

[Lynx]

Bump-mapped sprite technology...  Research 95% complete!



Disclaimer: not my model, I downloaded a model from Google Warehouse, "squished" it into a sprite, and just now got it to accept positional lighting.  You can see the ship lit from above, directly overhead, and below.

This is not a polygonal model being lit!  This is a simple sprite, plus a normals texture map.

This will come in handy because I don't want to just use 'lit from directly overhead' bitmaps everywhere to avoid issues with how the lighting appears on bitmaps; by adding normals, I can have the light appear to come from any direction I like, and the sprites will be shaded.  For instance, I could have a 'megabeam' light the whole scene up from its center, making it appear extraordinarily bright.

[george]

Cool Lynx, do you have some pointers or sites for learning about using normal maps with sprites?

[Lynx]

This is the main article I used for this exercise.

http://www.paulsprojects.net/tutorials/simplebump/simplebump.html

I used http://code.google.com/p/pycollada/ to import the Sketchup model for a model viewer.

I modified some Pyglet sample code out there, see:
http://groups.google.com/group/pyglet-users/browse_thread/thread/727092fed912ea90?pli=1

For reference.

I then changed the model viewer to switch back and forth between display the normal texture, and displaying the normals as the color of the surfaces, i.e. each vertex had the normal at that point defined as its color, and OpenGL interpolated in between those normals to generate the color of each pixel.

I screenshotted the basic texture-mapped object and the normal-colored object to generate the texture and normals texture, and then applied Paul's bump mapping tutorial.

I'll put code up somewhere once I have things fixed up - the last 5% always takes another 100%, y'know.

[Griff]

Pretty cool idea!  It will be interesting to see it in action.  Can you move the "paddle" ship off of the left side of the screen?  Or is it fixed there?

[Lynx]

At this time, it's fixed on the left side.  I may consider allowing some limited rightward movement, but I don't want to make the controls too complicated.

[jute]

Wouldn't "Space Out" be a better title?

[Xion]

Wouldn't "Space Out" be a better title?

I think space out would be better for a more mellow or abstract game due to its current existing meaning. Breaker Space is cool because it gives a more accurate idea of what the game is about. And also, break is a cool word.

[Fuzz]

This idea is great. We need more mashup games!

Mashup compo?

[Lynx]

Well said, Xion.  I'm aiming for a space opera kind of feel.  I appreciate the interest, all, and hope that I can bring this to a reasonably complete state.

Not too much progress to report.  Untextured model of the player ship:



Not that the ship is going to go zooming around in 3D much in the actual game, but having a model will let me take snapshots of it in different perspectives, so for instance in cutscenes, I could use a textured version of this to swoosh 'out of the screen'.

'Squish', the model/image utility, is moving slowly toward being a releasable utility in its own right.

[Lynx]

Realization: pressing a button to shield yourself from enemy bullets for a short time period does not make for fun gameplay.

I looked at the recently linked 'doujin shmups' and I had to admit, they looked pretty exciting.  Then I looked at what I have so far on gameplay and concluded that just combining Breakout and a straightforward shoot-em-up wasn't enough by itself.  I need to figure out how to make the gameplay more exciting without losing the core concept - you've got a ball and paddle-ship and you're breaking up an enemy fleet with the two.

So - the shield goes.  Instead, I'll have your ship's engineer repair the hull over time.

In its place, I'm pondering a new gameplay mechanic - the Gravimetric Whip.  Basically allows you to tractor the ball if it's reasonably close, letting you capture it to launch more precisely or whip it around your ship like a mace.  I haven't worked out the details of what this does for you, but the viscerality of the idea is promising.  Maybe I need to tie a really high velocity to extra damage, so a high-speed ball goes *kapow* through a bunch of bricks, but loses velocity as it goes.

This will necessitate some ability to move the ship around the screen, otherwise you won't have room to orbit the ball or it would be off screen some of the time.

I also think I need to get more bricks and general stuff in the game that you can break.

[Inanimate]

Maybe you could add power-ups, explosive bricks, the like?

[nihilocrat]

Interesting idea, and very promising results. I would have never thought of bump-mapping a sprite, it's a cool idea and I'm sure in action it looks awesome.

You have a very industrious attitude and I notice you learned pyglet in a short amount of time. I'm sure anything you make is going to turn out great.

[Lynx]

I wish I were actually that industrious!  The bump-mapped sprite does look good, but I've been at a loss how to optimize it so that I can have a bunch of them in the scene at a time.  OpenGL is black magic to me - repeat the ritual, wave the chicken, maybe it will work.

I've noticed some annoying bugs in the PyCollada importer I'm using, which I'm not sure whether they're the importer's fault.  If you define a component in SketchUp, then copy it several times at different rotations, they appear at incorrect rotations in the program.

I may revert to using simple sprites for a while and work on other issues for a while in the name of prototyping gameplay faster.

Other issues include the ever-present struggle to create a useful and programmer-friendly GUI system.  I've got a rudimentary dialog system, but it doesn't match up well with the simple game menus and file select menus I've been using.  This may wind up in 'yet another rebuild of the game engine from scratch', but that's not really a bad thing since the engine is still small.

So, I appreciate the kind thoughts, they help me stay motivated.

[DantronLesotho]

I hope you're still working on this game, I think the idea is fantastic.

[Wander]

Ya - the bump mapped sprite thing is something that  a friend and I have been meaning to try but haven't had time yet.

I'd love to see a vid of this in action.  Are you going to add a ton of lighting effects to capitalize on it?

[Lynx]

It's been in hiatus for a while, I've been trying to finish up work on a reusable GUI library for pyglet!  http://code.google.com/p/kytten/

After that, as far as bump-mapped sprites go, I would want to make that into a reusable library as well.  What I'm most wary of is winding up with something that's painfully slow.  The more graphic rendering code that's in Python, as opposed to being fed into OpenGL, the slower the engine will be, so groups of flat-rendered sprites are relatively quick to draw, but drawing many individual sprites with lighting passes on each one could be potentially very slow.