Sign in to follow this  
Derakon

Making a "sprite game framework" instead of an actual game

Recommended Posts

I'm slowly working on designing a game that I'll start programming sometime in the next few weeks (once my real-life workload drops off). I'm planning on making a 2D platforming game in the style of Metroid or Castlevania. However, as I think about the design, I'm beginning to think that what I really want to make is a versatile game-making framework, into which I could then plug my own content. This idea is based off of a few principles: 1) I don't want to have any compiled code that is specific to the game itself. That is, I don't want to have to specify each sprite as its own class. I don't even want to specify the player as a unique class, because in my game design, the player will be able to shift between a variety of forms at will, and thus needs to be flexible. 2) I'm already planning on scripting the enemy behaviour. And as long as I'm doing that, I could simply let a given sprite just take keyboard input and parse it (thus, the player's different forms would all have scripted keyboard listeners). I could also hand the camera to one of the sprites, as well as put in cutscenes as special scriptings. At least, I think I can; I haven't researched this area very heavily yet. 3) Ultimately I want the game I'm making to be heavily modular. I'd like to make a completely new world and enemy set without recompiling the code. And if I'm going to go that far, why should the program be limited to platforming games (let alone platforming games in the style of Metroid or Castlevania). With this in mind, the compiled code would pretty much handle: 1) Sprite display and collision detection (results being returned to sprites to handle as they see fit) 2) Handing input (keyboard, mouse, etc) to relevant scripts 3) Reading data files and initializing everything 4) Playing sound effects and music 5) Running scripts for sprites (I should really come up with a better name than "sprite" since they're more than that) I'm not even certain that the main program would contain state information for each game object. Does this sound feasible? I'm sure it's possible, but could it be efficient? Does it even sound like a good idea? If it works out, I'd have an extremely powerful tool on my hands that I could make available so that less programming-inclined people could make their own games. The problem, of course, is making it work out. I should mention that I'm doing this as a project in college. I'm a senior Computer Science major (undergraduate) who will have lots of spare time next semester for working on this. Ultimately I need to be able to give a presentation in May on everything I've done, so some level of progress is important. However, the game does not need to be finished.

Share this post


Link to post
Share on other sites
If you're referring to using scripting to drive the vast majority of the game, I'm planning on researching it, don't worry. :) I have an entire month of "dead time" coming up thanks to winter break; I won't be able to code as I'll be away from my computers (which, unfortunately, must be turned off to save power). I plan to use that month to solidify my background knowledge and start doing content creation (sprites, sound effects, music, world design).

Share this post


Link to post
Share on other sites
I recommend downloading and printing the Lua and Python reference manuals (or buying O'Reilley versions), as your scripting choice will probably come down to one of those two languages.

I also recommend a portable electric generator ;-)

Share this post


Link to post
Share on other sites
granted i don't know much about scripting but...
wouldn't you want to have number 3 controlled by your script as well.
that would make it more flexible would it not?
the script will read the data files (tiles placement, stats, etc) and the code will display or "make it run" (for lack of a better term".

yes, no.... maybe i don't know what i'm talking about ??

Share this post


Link to post
Share on other sites
I need something to actually run the scripts as appropriate. That something will have to be the compiled code, since that's what gets run by the user. It'll have to start everything up. Really, I get the feeling that what I'm looking at here is writing an OS of sorts; it does some work at boot-up, and then spends the rest of its time passing signals around.

How do Lua and Python compare in terms of speed? One of my goals is to make something that can run even on comparatively slow machines (in other words, I'd like to play the game myself without upgrading my five-year-old 466MHz G4). Given what I've heard of Python, I think I'd be comfortable using it; I've little experience with it but even less with Lua. Of course, if Lua is better suited then I'm more than capable of learning a new language.

Portable generators, alas, won't help as my computers will be far away from me. Even if I did leave them running on generated power, I think that the maintenance crew would get suspicious from the noise. :)

Share this post


Link to post
Share on other sites
I have a project like this that is stuck at around 6k lines of code just because I don't have the time right now.

I chose Lua because its very small and tight. No extra stuff I don't need. Python to me seemed very robust but in the end it was much more than I needed.

Lua being an embedded language is also rediculously easy to bind to you application.

Share this post


Link to post
Share on other sites
I think what you are better of doing is designing the "modules" themselves. For instance, design the sound module, the level builder, physics, movement, etc. Those sorts of things can be reused to a great degree in other projects. It may not be called a "framework" but no one would care even if it was A+ work (sorry, reality strikes again).

I'm working on a similar project. Metroid was my inspiration, but i'm building it flexable enough to add and change content later on. However, from what i've done so far (around 6 months worth), i would say that just building a boring framework won't do much. You eventually will want to narrow your focus to something and work on that. I mean, you can have a program that soooo generic it can make any game, but that's nuts. It's also impossible. I know that building a generic flexable framework is often highly praised, but for games you eventually have to get dirty and get something that works, even if it's a hack. If you later on find a non-hackish way to do the job, well, that's how you learn :-)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
My advice is make a platform via extreme programming first; ie just bang it out. Then you'll have a REALLY good idea what can and should be modularized and what shouldn't

Me personally, I've never gotten around to actually taking that step past the first quicky. It seems that there are 4 main components; scripting, physics, sprites and tile maps. ymmv.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this