From sjudd at ffd2.com Mon Dec 5 19:03:47 2005 From: sjudd at ffd2.com (Steve Judd) Date: Mon, 5 Dec 2005 18:03:47 -0700 (MST) Subject: [Slackers] Slang-GDK Game Development Kit Message-ID: Greetings, slackers: This is sort-of a mini announcement I suppose. I could also use some help with this, if anyone is so inclined. Finally, if someone would reply to this message I'd appreciate it, both from the standpoint of not being ignored, and also to make sure the list is working correctly. I have begun work on a system/set of tools for developing games with Slang. As I see it, the trick is to provide control/flexibility while helping to implement and organize ideas. That is, the classic problem is that a game tool (SEUCK, AMOS, etc.) makes life easy but doesn't give much flexibility, locking you into doing things a certain way, while asm gives total control but at huge effort. The Slang GDK attempts to solve this problem by outputting source code which is then included in Slang programs and compiled. The goal is to stay in line with the Slang idea of making things easier but letting you take control when needed. For example, the sprite editor lets you create sprites and such and writes a source code file when done, containing array definitions with all the sprite data, multi-sprite objects, and so on. This file is then PUT into a source file, along with another file containing display and manipulation routines. As a programmer you can now use the canned routines, or modify them for your own needs, or use your own routines as needed -- so you've got the power to do lots of stuff, but the flexibility to modify stuff as needed. There are three levels to the GDK. At the first level, I have in mind GDK tools for creating sprites, tiled backgrounds (both smooth and coarse-scrolled; can also be used for 2D and 3D dungeons, etc.), and sound effects. Adding more tools as needed should be a snap. Each tool outputs code that can be used in a Slang program. At the second level is a set of routines for manipulating the tool outputs -- routines for moving and animating multi-sprite objects, routines for displaying/scrolling the tilemap backgrounds, etc. These will also be Slang routines, which means they may be ignored or modified as needed. At the highest level, I have designed a framework for making games. The idea is to let the game programmer register a set of callbacks and main loop routines with the GDK, and let it do a lot of the work. By callbacks I mean that you can supply routines to be called when one of the joysticks is moved, or when a sprite-sprite collision is detected, etc. By main loop routines I mean routines to be called as part of the main game loop, for updating the screen, or say updating some timer, etc. For game programmers this will help to organize the game and think in terms of individual routines -- the joystick routine, the collision routine, etc. -- and the game mechanics, instead of getting wound up in the code structure and details. So, in practice, for say a Xevious-style game you'd: - Use the sprite editor to create the ships, generate code - Use the tilemap editor to create the background - Use the sound editor to create sounds then work on the code: - PUT all the relevant code into the game source - Call the GDK routines to set up the sprites, background, sounds - Register a routine to be called when the joystick is moved: move the ship, fire a shot, etc. - Register a routine to be called when sprites collide: check for shot collision, ship collision, etc. - Register a main loop routine to handle bad guys: check a timer or map position, move bad guy around, fire as needed - Register a main loop routine to move shots, etc. - Register a main loop routine to scroll screen and so forth. The status of the project is: I have a simple sprite editor working, and nothing else concrete (all else worked out on paper/in my head). If anyone cares I will post updates here as things are completed. My plan is to develop pretty simple tools. For example, my interest is in developing the GDK, and not a super-fancy full-on sprite graphics editor. Because all tools are being developed in Slang anyone can update or expand the tools, and that's the first place that I could use some help. The second place I could use some help is, of course, to have someone actually use the tools to develop a game. Given that so few people have been interested in giving Slang a try, let alone writing a program, I'm not holding my breath, but if someone has an interest here it is pretty important and would be much appreciated (like, personally... like, it would warm my heart to know that somebody, somewhere gives a ****!). Anyways, there you have it, thought I'd keep this on the mailing list for now, see where it goes. Thanks! -S From macbeth at psw.ca Tue Dec 6 10:50:11 2005 From: macbeth at psw.ca (macbeth@psw.ca) Date: Tue, 06 Dec 2005 09:50:11 -0700 Subject: [Slackers] Slang-GDK Game Development Kit Message-ID: <20051206095011.cf98e327dd5a377a61e92fa4b5b0ff18.a259ea1423.wbe@email.email.secureserver.net> Hi Steve, this sounds really cool. I'd like to hear about any updates, and give the GDK a whirl. Robin. From sjudd at ffd2.com Tue Dec 6 18:56:36 2005 From: sjudd at ffd2.com (Steve Judd) Date: Tue, 6 Dec 2005 17:56:36 -0700 (MST) Subject: [Slackers] Slang-GDK Game Development Kit In-Reply-To: <20051206095011.cf98e327dd5a377a61e92fa4b5b0ff18.a259ea1423.wbe@email.email.secureserver.net> References: <20051206095011.cf98e327dd5a377a61e92fa4b5b0ff18.a259ea1423.wbe@email.email.secureserver.net> Message-ID: Rness, Cool, the list works then -- thanks! One of the motivators for this was the idea of making an autoduel or rally-x type of game. That is, as a minimum, I would like it to have that kind of capability. (What would be really cool is a 3D capability for things like Battlezone. Maybe at some future date Mark can be convinced to re-do ObjectEd. But that's far-off, if ever.) One thing I may not have emphasized is that initially I plan on keeping things relatively simple, with the idea that experience using it will suggest further improvements and features. For example, with the sprite stuff I'd like to do sprites, multi-sprite objects, and animation, with accompanying routines (e.g. to move/animate an entire object). What I probably won't add now, but is worth thinking about, is adding velocity and acceleration. Like, you'd "instantiate" a sprite object with a velocity, acceleration, max velocity, etc. and let the engine handle it from there. Things like "lifetime" could also be added. (Where it gets complicated is differentiating between screen coordinates and world coordinates, in certain games.) Anyways, my thinking is that, with a little experience, it will be much clearer whether stuff like this would be useful. Anyways, we'll see. Thanks again, -S On Tue, 6 Dec 2005 macbeth at psw.ca wrote: > Hi Steve, this sounds really cool. I'd like to hear about any updates, > and > give the GDK a whirl. > > Robin. > > _______________________________________________ > Slackers mailing list > Slackers at starbase.globalpc.net > http://starbase.globalpc.net/mailman/listinfo/slackers > From macbeth at psw.ca Tue Dec 6 19:36:03 2005 From: macbeth at psw.ca (macbeth@psw.ca) Date: Tue, 06 Dec 2005 18:36:03 -0700 Subject: [Slackers] Slang-GDK Game Development Kit Message-ID: <20051206183603.cf98e327dd5a377a61e92fa4b5b0ff18.929c2ac792.wbe@email.email.secureserver.net> Hey again, > From: Steve Judd > One of the motivators for this was the idea of making an autoduel or > rally-x type of game. That is, as a minimum, I would like it to have that > kind of capability. I'd also like it to have that capability :) > One thing I may not have emphasized is that initially I plan on keeping > things relatively simple, with the idea that experience using it will > suggest further improvements and features. For example, with the sprite > stuff I'd like to do sprites, multi-sprite objects, and animation, with > accompanying routines (e.g. to move/animate an entire object). What I > probably won't add now, but is worth thinking about, is adding velocity > and acceleration. Like, you'd "instantiate" a sprite object with a > velocity, acceleration, max velocity, etc. and let the engine handle it > from there. Things like "lifetime" could also be added. (Where it gets > complicated is differentiating between screen coordinates and world > coordinates, in certain games.) Anyways, my thinking is that, with a > little experience, it will be much clearer whether stuff like this would > be useful. I think going for world coordinates right away is the best idea, to go right along with the scrolling tile maps. Lasse has written quite a bit about the "Game World" in a couple of his rants: http://cadaver.homeftp.net/rants.htm Having spent some time in his MW4 and BOFH source code last week, he really knows what he's talking about :) His games have amazing internal design. Each player/enemy/bullet/etc. is an "actor" that exists at a fairly high level, with a bunch of routines to make the actor do different things. Each actor type has it's own jump table of routines depending on what status it has at the moment - e.g. on a ladder, jumping, crouching, etc. Each actor type also takes care of telling the sprite multiplexer how many sprites it needs, etc. There's loads of depth in there. It might be worth reading/discussing for a few days together to see if there are any fundamental ideas in there that should be incorporated right from the beginning. It wouldn't necessarily mean much code from the beginning, perhaps just deciding on the right data structures that would be flexible enough to handle many game types. Robin. From sjudd at ffd2.com Thu Dec 8 11:43:13 2005 From: sjudd at ffd2.com (Steve Judd) Date: Thu, 8 Dec 2005 10:43:13 -0700 (MST) Subject: [Slackers] Slang-GDK Game Development Kit In-Reply-To: <20051206183603.cf98e327dd5a377a61e92fa4b5b0ff18.929c2ac792.wbe@email.email.secureserver.net> References: <20051206183603.cf98e327dd5a377a61e92fa4b5b0ff18.929c2ac792.wbe@email.email.secureserver.net> Message-ID: Rness, Yeah, there will definitely be room for expansion, via dummy bytes in the object structures. In RAD, what I did was "instantiate" objects such as missiles, with attributes such as position, velocity, lifetime, etc. The code would find an empty slot/sprite, assign it, and update all active objects. This was motivating my thinking here. (The 3D object library sort-of does a similar instantiation/queing type of system, I think.) RAD scrolled the screen, but not the colormap. I think I have a reasonable way of doing both, but I haven't implemented or tested it. This raises all sorts of issues as to how much complexity to include (scrolling colormap? assume a multiplexer?) but right now I'm not too worried about all the details. (Or I'm trying not to be!) I have a number of game styles targeted, and I'm not too worried about modifying/enhancing stuff in the future. Again, the whole trick here is that the system is flexible, meaning easy to modify and customize as needed. If the version 1 sprite handler is missing something, we write a v2 and use that instead. Include and recompile. No big whoop, because it's not using fixed structures in memory (in general). But the issues you bring up are all definitely issues that will need to be thought through and addressed. What would be great is to think about some of the technical features you'll need for a specific game -- moving charmap (plus moving colormap?), game object interactions, etc. -- and once there's a simple GDK system in place we can start fleshing it out. Also, yeah, reading some of Lasse's articles and discussing them sounds like a good idea too. cu, -S From jaymz at artificial-stupidity.net Sat Dec 10 18:51:53 2005 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Sun, 11 Dec 2005 11:51:53 +1100 Subject: [Slackers] Slang-GDK Game Development Kit In-Reply-To: <20051206183603.cf98e327dd5a377a61e92fa4b5b0ff18.929c2ac792.wbe@email.email.secureserver.net>; from macbeth@psw.ca on Tue, Dec 06, 2005 at 06:36:03PM -0700 References: <20051206183603.cf98e327dd5a377a61e92fa4b5b0ff18.929c2ac792.wbe@email.email.secureserver.net> Message-ID: <20051211115153.Q80854@artificial-stupidity.net> Just butting in half way into a conversation :) On Tue, Dec 06, 2005 at 06:36:03PM -0700, macbeth at psw.ca wrote: > > One thing I may not have emphasized is that initially I plan on keeping > > things relatively simple, with the idea that experience using it will > > suggest further improvements and features. For example, with the sprite > > stuff I'd like to do sprites, multi-sprite objects, and animation, with > > accompanying routines (e.g. to move/animate an entire object). What I > > probably won't add now, but is worth thinking about, is adding velocity > > and acceleration. Like, you'd "instantiate" a sprite object with a > > velocity, acceleration, max velocity, etc. and let the engine handle it > > from there. Things like "lifetime" could also be added. (Where it gets > > complicated is differentiating between screen coordinates and world > > coordinates, in certain games.) Anyways, my thinking is that, with a > > little experience, it will be much clearer whether stuff like this would > > be useful. > > I think going for world coordinates right away is the best idea, to go > right along with the scrolling tile maps. The only possible issue with this, is that it does make clipping your AI routines to only objects "near" the screen area harder - of course, it does still make more sense conceptually. Additionally, consider status bar sprite objects and such things... to be fair, there is an argument that moving that stuff to fit the world is easier than moving the sprites, however it is also more conceptually difficult to get ones head around. Since the sprites need to be converted anyhow, perhaps a flag would be easy to implement though (but would add 5 cycles/sprite of overhead, of course, le sigh) > Lasse has written quite a bit about the "Game World" in a couple of his > rants: > http://cadaver.homeftp.net/rants.htm Oh, absolutely, those are totally required reading (guess who I stole my current sprite sorter from? :-p) > There's loads of depth in there. It might be worth reading/discussing > for a few days together to see if there are any fundamental ideas in > there that should be incorporated right from the beginning. It > wouldn't necessarily mean much code from the beginning, perhaps just > deciding on the right data structures that would be flexible enough to > handle many game types. a day spent designing is worth a week spent coding, as they say :) --jj -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From sjudd at ffd2.com Mon Dec 12 10:16:02 2005 From: sjudd at ffd2.com (Steve Judd) Date: Mon, 12 Dec 2005 09:16:02 -0700 (MST) Subject: [Slackers] Slang-GDK Game Development Kit In-Reply-To: <20051211115153.Q80854@artificial-stupidity.net> References: <20051206183603.cf98e327dd5a377a61e92fa4b5b0ff18.929c2ac792.wbe@email.email.secureserver.net> <20051211115153.Q80854@artificial-stupidity.net> Message-ID: Hey Jaymz, > > The only possible issue with this, is that it does make clipping your AI > routines to only objects "near" the screen area harder - of course, it > does still make more sense conceptually. Additionally, consider status > bar sprite objects and such things... to be fair, there is an argument that > moving that stuff to fit the world is easier than moving the sprites, however > it is also more conceptually difficult to get ones head around. With Slang, part of the idea was always that it doesn't lock you in to a way of doing things -- you can always drop into asm, or even update the compiler. Similarly, with the GDK, one goal is to not lock you in to one particular mode of operation -- to give options. The way I think of it is as a series of layers: the sprite editor will output sprite definition code, followed by object definition code which uses the sprite definition code. This code is then used by display routines and such. Those routines are then used by "game world" routines. As the programmer, you can pick and choose which layer to stop at. So to display a status bar on the screen, you can just use the display routines. Or you can use the sprite definitions and display them manually. Or you can manually define the sprite yourself in Slang the way you'd do right now. Or you could write an asm routine. Or you could go into the Slang layer routines and modify them to suit your needs. In short, you should have the flexibility to do pretty much whatever you want, and the idea of the GDK is simply to add to what you can do right now -- as opposed to providing a fixed, confined system that defines what you can and can't do. > a day spent designing is worth a week spent coding, as they say :) Totally agree, and that's pretty much my mode of operation, but let us never forget the caveats of: 1) unless you never get around to coding! and 2) sometimes it helps to get some coding under the belt and _then_ go back to the pencil and paper! cu, -S P.S. No GDK updates -- didn't work on it at all this weekend. From sjudd at ffd2.com Sun Dec 18 09:52:08 2005 From: sjudd at ffd2.com (Steve Judd) Date: Sun, 18 Dec 2005 08:52:08 -0700 (MST) Subject: [Slackers] GDK update Message-ID: Hola dewdz, I (finally) had a little more time to work on this, so... an update. The sprite editor now can edit a sprite reasonably well, both hires and multicolor. I'll be building up the sprite object capabilities next. Slang has been working out very well so far -- very easy to get things going quickly. I find that I usually still "think in asm", and am learning to "think in Slang". I've encountered more bugs, but nothing very big and all easy to work around. I've talked about how the GDK is layered and since I've finalized the sprite layers maybe it will help make things clearer. The first layer is the "spritedat" layer. This is a bunch of 63-byte chunks of sprite definition data. The Slang code is an Nx64 array of bytes. The second layer is the "spritedef". This is a little structure containing sprite parameters such as multicolor, x/y-expand, priority, color, and a data pointer -- an index into the spritedat layer. You also give them a name ("shipsprite1" "bullet" etc.). The third layer is the "spriteobj". A sprite object is simply a list of spritedefs at position offsets. That is, you can place several sprites together to make a larger object, or overlay the sprites to make a many-colored sprite, etc. These too are named. The fourth layer is the "spriteanimobj", which is simply a list of spriteobjs along with a framing rate. That is, this guy displays a succession of sprite objects at some rate. Again these are named; the names become the variable names in a Slang program. So you can see that you always have access at the lowest levels, but can use the high-level stuff for most situations. As you might expext, these layers are then used by the game engine (the highest layer). That is, you have a game "object" with various traits position in game world velocity state, health, etc. render info (pointer) In an action game you'd probably render it as a sprite, so you'd pass the "spriteobj" or "spriteanimobj" info to it. In a 3D game you'd use a 3D structure instead; in an Ultima-style game the object might be a 4x4 charset. The object stays the same/similar; the interaction with the map stays the same/similar; the rendering method can change totally. This is the point of the GDK. It's not so much a set of specific routines as a methodology, for organizing and implementing games. The design is what makes the same stuff usable for an action game, an RPG, a 3D game, etc. The beauty of all this, incidentally, is that Slang handles the details. That is, from the above it sounds like it might be very cumbersome to implement. In asm it would be. In Slang the compiler fixes everything up and all the overhead happens at compile time, not at runtime. OK, back to work :) cu, -S From jaymz at artificial-stupidity.net Mon Dec 19 06:03:43 2005 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Mon, 19 Dec 2005 23:03:43 +1100 Subject: [Slackers] GDK update In-Reply-To: ; from sjudd@ffd2.com on Sun, Dec 18, 2005 at 08:52:08AM -0700 References: Message-ID: <20051219230343.J48451@artificial-stupidity.net> Hi steve... good to see the work you're putting into this. I actually have a couple of more or less relevant questions. The first is obviously the "is this code on the net somewhere, or only on steve's hard drive"? You know about curiosity and cats... though I'm still only really getting started with slang still, so I'm perhaps not useful I am still curious on a functionality level. One question I have about slang that is pertinent - and I might be completly out of the field on this one, can the compiler be set to generate relocatable code? I don't actually have a superCPU or a ram expansion, so I have to use xlang for compiling of course - and my 64k of ram to include perhaps both the sprite editor and the game environment. But it'd be nice if I could swap code in/out of ram onto a big disk (which I do have) or an REU (which I don't, but vice deos) for a c64 dev environment like this. This is obviously mostly naval gazing though, in a way, since I guess to really run a useful dev environment like tht you need the slang compiler anyhow - although since my big disk is a PC (the final replay's network drive :-p), it'd be pretty easy to farm out the compiling to xlang in that case (a solution that would work with vice as well). I guess for people not in my networked world, it doens't work out so well :-p. (hey, maybe it's time to make slang self hosting, and rewrite it in slang. That would really need memory management, though :-p :-p :-p) > The sprite editor now can edit a sprite reasonably well, both hires and > multicolor. I'll be building up the sprite object capabilities next. > Slang has been working out very well so far -- very easy to get things > going quickly. I find that I usually still "think in asm", and am > learning to "think in Slang". I've encountered more bugs, but nothing > very big and all easy to work around. I'm glad to hear that it's working out well for tools, though - my initial interest was actually for this reason > The beauty of all this, incidentally, is that Slang handles the details. > That is, from the above it sounds like it might be very cumbersome to > implement. In asm it would be. In Slang the compiler fixes everything up > and all the overhead happens at compile time, not at runtime. Right, which is a nice situation to be in :) == jj -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From sjudd at ffd2.com Mon Dec 19 19:28:30 2005 From: sjudd at ffd2.com (Steve Judd) Date: Mon, 19 Dec 2005 18:28:30 -0700 (MST) Subject: [Slackers] GDK update In-Reply-To: <20051219230343.J48451@artificial-stupidity.net> References: <20051219230343.J48451@artificial-stupidity.net> Message-ID: Hey Jaymz, I'm going to take a stab at this but let me know if I've totally misunderstood the question! The game development kit isn't a SEUCK-like thing. What it will be is a set of tools. Like, right now to do a demo or whatever you run one tool to edit a charset, then you load up a different tool to edit sprites, and so on, and that's how this will work. The difference is that instead of (or really, in addition to) writing just a binary data file, the programs will write a text file containing Slang code. Like, let's say you edit three sprites. The sprite editor will save a text file that looks like: spritedat(3,64) = [[ ...data...] [...data...] [..data...]] deftype spritedef ubyte .spritenum ubyte .multicolor ubyte .xexpand ubyte .yexpand ubyte .priority ubyte .color enddef spritedef shipsprite,enemy1,bullet shipsprite.spritenum = 0 shipsprite.multicolor = 1 ... and so on, with definitions of the sprite objects and such. This is just Slang source code. Meanwhile, there will be another file, containing more Slang routines that make use of these definitions -- like, there might be a routine like "ActivateSpriteObject(0,#shipsprite)" which takes as parameters a sprite structure and the sprite to activate it at. So now to write a game you'd write a Slang program like PUT "gamessprites.s" ;the file saved by the sprite editor [game code goes here: set up the game engine, set up callback routines for joystick movement, sprite collisions, etc.] PUT "gdkengine.s" ;the GDK game engine routines So the trick is that the whole system is just Slang code. It's all code you could write by hand; it's just that the sprite editor etc. will do it for you, and the game engine works in a kind-of nifty way, and it all works together as a system. It's also why I say you can do a 3D game instead of a shooter, by including a different engine. Same game code, but different graphics data and engine routines. What I wanted to get away from is SEUCK-like things, where you're completely locked into a narrow game type, and AMOS-like things, where you're locked in to the particular commands and capabilities the language comes with. I think it will be as easy to use as an AMOS-like thing, but much more flexible. (We'll see though.) It definitely won't be a Garry Kitchen's Gamemaker kind of thing, where the editors and code writing environment are all integrated in a single piece of code -- it'll be separate tools, used as needed. Given all that: you always need Slang to use the kit. You still have to write the game code in Slang; there's just a whole lot of help from the kit to make it happen. You will always have stuff saved in files, to be loaded in at compile time. I don't think there's ever a memory issue; xlang uses what it needs, and Slang requires SuperRAM. It turns out that Slang does generate relocatable code though, for the linker. With the linker you compile routines into relocatable code modules, and the linker sticks them all together at link-time to generate an executable. I expect to have a linker version of the GDK as well (compile times get rather large, and programs get rather obnoxious, once the files get large). Incidentally, games have always been one of the major targets of Slang. The idea was always that you would use asm for the optimized parts of the game, but use Slang to write the game logic and stuff that would be a real pain otherwise. Finally, the source code: Slang itself is kinda backed up; the GDK is right now just a single 30 block file (sprite editor) on the hard drive. Still got a long ways to go. Hmmm... sorry this message has run so long. cu, -Steve