About this blog
The gun is good, the pants are evil!
Entries in this blog
Particle Systems in Damut Dan
The Unreal Engine
The particle systems in Damut Dan are largely inspired by the particle systems in the Unreal Engine. Mine have a lot less features, but the two systems do have a few things in common.
Like Emitters in the Unreal Engine, my particle systems use the idea of 'steps' or 'scales'. These are essentially lists of values that act as animations for particle properties over time.
There might be a list of color steps, for instance, that describe the color of each particle over the course of its lifetime.
When to use Steps
Particle steps are effing awesome, but they're expensive. 'Animating' particle properties for thousands of particles every frame can really drag the frame rate down. That being the case, I had to be very selective about which particle properties could use steps, while allowing myself to convert properties to or from steps in the future, if need be.
Properties that are Difficult to Animate
Another potential problem with particle steps is that some properties are hard to animate. Take velocity for example. Now animating velocity by itself is not so hard, but applying acceleration (such as gravity), and external forces (wind, explosions), makes calculating the end result of a particle's animated velocity at a given time pretty complex, at least for a person with my math skills.
Effects and Systems
At a level higher than particle systems are 'particle effects'. A particle effect in Damut Dan is simply a collection of particle systems and data describing when and where to spawn and update those systems.
So an explosion effect might consist of an initial fiery explosion system, a spark-throwing system, and, later, a smoke billowing system.
This is really just provided as a convenience to the artist. We're going to want complex particle system combinations anyway, so we may as well make it a part of the creation process.
The idea of having the effect class was inspired largely by TGB's particle systems, although I think the Unreal Engine has a similar concept (along with probably a million other games and engines).
Another concept borrowed from the Unreal Engine was that of emitting shapes or volumes. These are basically just geometries that describe the area in which particles are emitted.
Currently, I support disks and rectangles. Disks are specified with an inner and outer radius, as well as a minimum and maximum angle. Rectangles are just specified with a width and height, although I may add an inner width/height or an angle if the need arises.
There are also 2 kinds of particle velocities - radial and linear. Linear velocity is described using normal vectors with a direction and a magnitude. Radial velocity, on the other hand, only specifies a magnitude. The direction of each particle's radial velocity is calculated by subtracting its starting position from the center of the emitting area. (I'm sorry if this doesn't actually have anything to do with the term 'radial'. It just sounded so cool.)
Radial velocity is typically used in tandem with disk emitting shapes - to allow particles to be thrown outward from the disk, or inward toward its center (using a negative magnitude), although there is no restriction on their usage.
Everything is not an Object?
I mentioned in my previous post, that I'm trying to represent everything on the screen as dynamic objects.
I thought of representing particles themselves as dynamic objects, but decided not to for performance reasons. It would be really awesome to have a level rain real cats and dogs using a particle system, but I don't know how often anyone would really use a crazy feature like that.
Dynamic objects are pretty large, and they do lots of things every frame. Spawning thousands of them every frame, just to represent smoke or sparks would be pretty asinine.
I might later add another parameter to the particle system template class that describes whether the system spawns normal particles or dynamic objects, thus allowing 90% of our particle systems to inherit the performance benefits you get when dealing with small particles, and at the same time give us the power to spawn fluttering butterflies as blood spurts. But that's on the wish list for now. (Did I mention I have overly high ambitions?)
And so on
I could probably say a lot more about the particle systems in Damut Dan, but... well, lets just say I'm doing you a favor.
In short, I've tried to create particle systems that allow as many features as possible at the lowest possible cost, and I've done so borrowing the creative knowledge of many other game developers.
I need my particle systems at a low cost because I want particle systems everywhere in Damut Dan. I want particle system-y explosions sending bloody gibs soaring across the screen, on fire, emitting smoke, splattering when they hit the walls. [inlove]
So I figured I might post something that's maybe worth posting.
XML Driven Design in Damut Dan
Templates and Objects
In Damut Dan there are objects on the screen, that run around, blow things up, and eat babies, and then there are 'templates', that specify common data & parameters for the different types of these on-screen objects.
Templates are loaded from XML files during load time, and the on-screen objects are 'spawned' during game play.
Every object is instantiated with a template, that it accesses when referencing common data. There might be a 'skeleton warrior' template, which specifies that every skeleton warrior object will draw skeletionWarriorLoinCloth.png, and be given a bone-gun as a weapon.
This was done to cut down on the amount of memory used at run-time. Really nothing out of the ordinary here.
Everything is an Object
All objects in Damut Dan can are one of two things - static background objects (trees in the distance, etc.), or dynamic objects (everything else). Dynamic objects are really the meat of the game. They contain all of the game logic, and the game logic really only refers to them (not to static objects). Any object 'spawned' during game play will be a dynamic object. Also, any type referenced in an XML file will be a dynamic object.
Treating everything as a dynamic object gives us a lot of power.
For instance, the information for dynamic objects relating to 'gibbing' specify objects to spawn like so:
Template ObjectTemplateFile="skaterGib01" Count="10" XRangeMin="-32" XRangeMax="32" YRangeMin="-32" YRangeMax="0"/>
Template ObjectTemplateFile="skaterGib02" Count="10" XRangeMin="-32" XRangeMax="32" YRangeMin="0" YRangeMax="32"/>
Here you see several 'gib piece templates'. Each ObjectTemplateFile property value is the name of another dynamic object xml file. So, using this system, you could theoretically have an object gib into more instances of the same object, or puppies, or enemies, or chainsaw rockets, or... you get the idea.
The Magic of Reflection
I decided to take advantage of .Net's reflection system, and allow us to create instances of classes specified at runtime.
In this template data file, we see two reflection-y parameters: TypeName and GameObjectTypeName. TypeName specifies what C# class the template itself is, and GameObjectTypeName specifies what C# class to instantiate when spawning objects that reference this template.
In this particular example, we see that the user simply specifies the default classes for both the template and the dynamic objects that use it, but we could specify any sub-classes of those classes.
I started work with a friend on an action-packed, side-scrolling, mother-punching XBOX 360 game. Naturally I started with the most important element of the game - gibs:
Honestly, I think our ambitions for this game are too high. It will probably die like all the rest unless we make it brain-dead simple.
I've considered contacting Ravuya in hopes of becoming his lover programming lackey. His projects are ridiculously realistic, and I like the style of his games.
I can't wait to see what becomes of Microsoft's new XNA Community Distribution mabob. Hopefully by the time it goes live, I'll have a game to put up there.
2007-05-30, 5:15am (GMT)
I added a trick to my skateboard game - a kickflip. I was able to draw the animation and get it working in code in only 45 minutes. Not bad.
I haven't fully familiarized myself with TGB yet. I haven't even touched audio. I think tomorrow I'll drag my skateboard out to a near-by parking lot and record some sound effects.
I also need to re-familiarze myself with making and scripting UIs in TGB. Maybe I'll put together a simple title screen for my demo.
Physics in TGB
One thing I meant to discuss in greater detail in my last post was TGB's physics engine. TGB has built-in support for basic rigid-body physics for game objects, using convex polygonal bounding areas. Unfortunately, the collision detection and response behavior is sometimes unreliable. Objects often teleport through other objects, get stuck, or fall through supporting surfaces.
There are a couple of collision response methods you can use in TGB - 'clamp' and 'bounce'. 'clamp' just moves colliding objects by their intersection offset. 'bounce' applies impulses to colliding objects and attempts to make them behave in a physically correct way.
I only use 'bounce' collision response for unimportant, non-player-controlled entities, such as the gibs in my skateboard game; I've found the 'bounce' option too unreliable for important game objects.
I've tried letting player objects use the 'bounce' response method, but these objects always end up stuck in the ground for no obvious reason, or colliding with a buried edge of a tile in a tilemap.
I'll keep this in mind for my contest entry - "no fancy physics!"
I've added a post to my MAGIC contest entry page. I'll be updating that page this week and during the week of the contest.
I've pasted the entry I wrote here, but I may not do so for future entries - converting the wiki-style formatting tags to html tags is a pain.
2007 - 05 - 29, 2:56pm (GMT)
Working with TGB
This weekend I started work on a small game using Torque Game Builder. The game is a simple 2-D side-scrolling skateboard game. You control a skateboarder and do tricks over gaps, down stairs, etc. Below are the observations I made while making this game.
Getting Started - Documentation
The first thing I had to do is re-familiarize myself with TGB and Torque Script. I started by logging on to the Torque Developer Network (TDN). The TDN is a wiki-based documentation system for all of the Garage Games game development products. There they have various tutorials on completing common tasks for common game types.
I started out by following a tutorial for getting a platformer game avatar running around on a tile map. The tutorial was easy to follow, but it included some seemingly strange code to get around some of the quirky aspects of TGB.
For instance, the collision code was a little strange. Instead of using an 'onCollision' type of callback to respond to collisions with the environment, they instead manually tested for projected collisions every frame over a small time interval.
This was apparently because the physics/intersection code in TGB often results in objects teleporting to the wrong side of a collided object. This problem is probably magnified when you have very large objects relative to the tiles in your tile map.
After completing that and a few other tutorials, I moved on to some actual coding. This involved using a documentation manual that comes with TGB. The documentation here was decent, but the page (it is basically a giant HTML page) wouldn't load correctly in Firefox or Opera, leading me to use Internet Explorer 7, which was kind of a pain in the neck (remembering to open with a browser other than my default).
Looking for documentation on more uncommon tasks in TGB wasn't all that easy. Granted, I eventually found answers to all of my questions, but it was time consuming. Searching for help with Torque Script often brings up a lot of unrelated junk, or stuff specific to the Torque Game Engine, and not TGB.
Working with the TGB Application
TGB comes with an application that acts like a 2-D game maker. In this application you can edit sprites, particle systems, static images, etc. You basically drag and drop these object templates you've created onto the game field. Here they can be scaled, rotated, and otherwise manipulated. Overall, the application is pretty nice, but it can be a pain to work with.
Selecting objects is a chore sometimes. You're bound to have lots of overlapping objects on a 2-D game field, and selecting overlapping objects in TGB isn't always easy. Selection generally works such that when you repeatedly click on a spot, it will cycle through all of the objects that overlap that point. This would be fine if it always worked, but it doesn't. This results in having to move objects out of the way so you can get to the one you want, which I imagine wouldn't always be a very easy thing to do.
Another strange thing, and one that I think is common to a lot of game making programs, is having to always work with instances of objects. In order to edit an object's collision polygon, size, or rotation, you have to create an instance of of the object and work on that instance. In other words, it doesn't let you easily define all that stuff for all instances of the object type (I realize my use of the word 'object' here is confusing). This results in strange design workarounds when you are trying to define an object that you will create many instances of during the game (and not in the editor).
In my skateboard game, for instance, I had to create the skater's ragdoll and gibs (yes, he explodes) in the editor, somewhere off of the playing field. Then, in the game, when the skater falls, I have to clone these objects and place them where they should go, or just move the off-screen objects over to the player's position.
Another gripe I have with the editor is its lack of script support. In the editor, you can edit an object's class type, its name, and add dynamic variables to its class, but that's it. You can not edit your script files in the editor. This is especially annoying because TGB does not come with its own Torque Script editor. You have to use a text editor or find a Torque Script editor some where else. All of the free ones I've tried have been less than desirable, and even the ones with a price tag aren't so great. Right now I'm still using a trial of Torsion, the editor I've found to be the best for my usage.
Building your game for deployment is very easy. The TGB application has a built in 'build' tool that compiles a version of your game that can be distributed by itself. You don't seem to get much control over your final directory structure or packaging, but that doesn't bother me.
Working With Vista
The most painful part of TGB was its non-compliance with Vista. It requires that you save your game projects under its installation directory, and as we all know, saving files under Program Files in Vista is a no-no. Also, TGB was unable to find the 'compatibility files' that Vista creates when you save files somewhere under Program Files. Thus, none of my artwork was ever visible to TGB.
In the end I had to install TGB in my Users/blah/Documents to get a reasonable work environment.
Also, I was unable to run my deployed game unless I ran it as an administrator. This does not boast well for TGB in terms of giving your game to end users running Vista.
What I Accomplished
In the three days I worked on the project, I accomplished the following:
The skateboarder can skate around on a level.
The skateboarder can ollie
Gravity and physics work the way I wanted them to (for the most part)
The game can detect (not very accurately) when the skateboarder should fall
The skateboarder can fall and explode into gibs when he hits the concrete
The background is layered and scrolls at different speeds while the skater is moving
After the skateboarder dies, the level automatically restarts.
What I Did Not Accomplish
The following are things I tried to do but could not finish:
There are ramps in the game, but I was unable to get the character to properly align himself on the ramp. Currently, he just stays horizontal as his front wheel slides up the ramp.
I couldn't clean up all of the art like I wanted to.
I couldn't get another trick in (I didn't even have time to try).
Conclusions - The Proof is in the Pudding
I totally nailed my target in terms of features and game play. In three days I got the basics for a game layed out, in play-able form. I am very pleased with my level of production and I'm confident that I'll be able to get something up and running for the contest. I think I got a lot more done than I would have if I were using my XNA or C++ code base. So far I think I can recommend TGB for this use.
Screenshots of my Game
(sorry for the cursor hovering over the scene. I should have disabled that.)
Long time no posty.
I've been working with a couple people on an entry for Microsoft's Dream Build Play contest. First off, here are some screens:
Putting weapons on the ships:
Blowing eachother up:
At this point you may be asking yourself some questions. Like, "What the hell am I looking at?", "Why are these 'ships' made out of stupid looking cubes?", "Is that really supposed to be a weapon?", "What are those white domes?".
The best answer I can give you is: I can't get our god damned artist to make anything.
I've confronted him a few times, saying something along the lines of, "I need to know if you're actually going to complete the assets for this game on time. We have X months. I don't want to spend all my spare time on this thing and convince our teammates to do the same, if the game isn't going to be completed because our artist couldn't finish his work."
He replies with his usual, "I just couldn't find the time last [blah] to work on it. I had to go do [blah], [blah], and [blah]." And so on. Then I ask him whether or not, given his current circumstances, he can really finish the game, and he assures me that he'll have everything done.
Meanwhile, the other team members (really now only consisting of 1 other person) seem to be growing less motivated to work on the game.
Unless our artist suddenly starts pumping out models and textures tomorrow, I'm pretty sure this project will die. Two months is not a lot of time to finish up an asset-less game.
I just wanted to post some screens to announce that, whether or not this project dies, we had a project, and I actually made some progress on it [lol].
I'd also like to say, "Down with the artists! Procedural content ftw!". [lol]
The past few days I haven't gotten much programming done, because I've been restoring an old fish tank that my friend let me take off his hands. The stand was orginally spray painted black, with no finish ([rolleyes]), and was kind of chipped up, so I sanded it, stained it, and finished it. Here are the results:
The whole fish tank:
My four fish running away from the camera [headshake]:
That's all for now. I may have the lounge lizards help me name my new fish, if they are willing.
[EDIT] - src, not href! [lol]
I'd really like to use C# for VGUL instead of C++. Developing in C# using Visual Studio 2005 is a rather enjoyable experience. With the better auto-completion features, simpler syntax, and in-language support for high-level tools and paradigms, I feel like I can code at least twice as fast in C#, and that the code I develop is less error-prone than the C++ counterpart. The built-in documentation viewing is also great, especially since I've put so much effort into documenting every function, class, and variable in the library.
Having VGUL developed in C# would also make it stand out a little better. Right now it's definitely a very small voice in a very large crowd, considering the thousands of other C++ game development libraries that are available.
Unfortunately, I feel that speed and compatibility are of the utmost importance to VGUL's success, and C# simply does not satisfy those requirements sufficiently. If somebody wants to make a game for the Wii, or some other strange platform, I don't want my library to be completely useless, especially since I would like to do some console development myself. I also don't want people to have to worry about my library being too slow for their game, or even worse, find out that it's too slow after having invested the time in incorporating it.
The library is also probably too large for a total C# conversion anyway. I'd have to rewrite a huge amount of code, even if I left the low-level math stuff like 3d/2d vectors in C++.
Maybe, if I have the time, I'll write a C# wrapper for the library, because I certainly don't want to alienate the growing mass of C# programmers.
Oh well. [crying]
This morning I finally got my sprite editor kind-of-working, although the texture font I generated is terribly ugly, so... no screenshots for you!
Why did it take me so long to get it working?
I thought my Visual Studio project file was corrupt. All of the folders were re-arranged and my organization was eradicated. It seemed that Visual Studio had noticed a messed-up project file and freaked out, and in an attempt to recover things, organized all my files they same way they are organized on disk. I tried restoring an older project file, but that didn't fix anything. I mucked around in the menus and project settings for a while, looking for something that may have caused it, but that didn't fix anything either. Then I cried. I avoided 'fixing' it for a day or two. When I came back to it, I started looking around the solution explorer and noticed a little toggle button whose context help read 'Show All Files'. I un-toggled it (?), and what do you know, my project was back to normal. Hooray for being dumb.
Back to texture fonts: I don't know whether to love or hate texture fonts. They're so damn ugly, but they're so much more flexible than bitmap fonts.
Bah, I'm tired. I need to go to bed. I hope what I wrote makes sense. [dead]
I'm supposed to go jogging with my friend early tomorrow morning, at around 5:30am. I really shouldn't have said 'yes' when he asked me to go. I really don't like running. Whoever invented running was a jerk.
I was hoping to post some screenshots of my sprite editor today, but I couldn't quite get it working. I thought I was on the verge of having it up and running again until I realized that the texture font wasn't loading properly, presumably because I changed the image and texture font formats since I last built the editor.
So I had to go and fix my texture font generator, which involved shoving some of the code from the executable into the TextureFont class itself (as it should have been in the first place).
On the bright side, my new-and-improved resource manager seems to be working quite nicely. Converting the old apps is fairly easy and it has generally made them cleaner and safer.
Time to go shower and sleep. I love sleep. [inlove]
I worked on cleaning up some of my recent additions to VGUL and adding/refining its documentation.
Next I will update my sprite editor to use the new resource management system, which also means updating the Sprite and SpriteData classes to use the new resource reference and resource dependency objects.
Which reminds me:
A while back I made a post on the game programming forum about how I was having difficulties coming up with a good system for resources referencing other resources (like a particle system referencing a texture for its particles). Most notably, I didn't want to give resources the ability to load themselves (although now I realize it probably didn't matter. At the time I was on a 'proper OOP' rampage [rolleyes]).
I finally came up with a pretty good solution. Each resource can have a list of 'dependencies' - names of resources it relies upon. Before loading each resource, the resource manager attempts to load all of these dependencies first. The dependencies are saved as a separate data block, preceding the actual data for the resource. A resource class can also explicitly state that it will never have dependencies, and thus can avoid the extra data being read/written.
This creates a sort of dependency tree, which is pretty cool. Unfortunately, it brings the possibility of infinite recursion, which I do not yet protect against.
Anwyay, that's all for now. Off to bed with me.
I wanted to update my journal the past two or three days, but my girlfriend kept kidnapping me.
I've finally got VGUL building again. [totally]
After reworking the resource manager, I had to spend several hours yesterday fixing all of the new errors that popped up. I didn't realize how big VGUL had gotten, and how many things relied on the resource manager. There are sprites, particle systems, a GUI system, an OpenGL renderer, image classes, an 'engine' framework that loads in 'application' DLLs to run inside the engine (as well as a framework for writing applications that link to the VGUL library instead), and more.
So now I've got to get to work on all of these classes, features, and systems and make sure they work. I'm pretty sure I stopped on almost all of them at around 90% completion.
After starting, I can estimate a release date for version 0.2.0 of VGUL, and thereafter keep the updates a little more professional and regularly scheduled (the two aren't mutually exclusive are they? [lol]).
I do think this library will have something to offer game developers, at least hobbyist programmers like the ones that frequent this site. I'm going to great lengths now to make sure that every 'system' is robust, reports useful errors, is simple to use, and is well documented. Documentation is generated in doxygen, which I strive to make useful and explanatory, but I also plan on building sample applications and documents to help with a broader understanding of the library.
If I can get two of my friends to help me, I plan on also releasing an open-source game that exemplifies usage of the library and (hopefully) all of its subsystems. What better documentation and reason to work on the library than that?
I think this development journal has really helped me become a more productive programmer. I've also gotten a great deal of inspiration and motivation from other users' journals, such as Ravuya's, EDI's, ApochPiQ's, and Sir Sapo's, just to name a few.
Okay, that's all for now. I'm going to go play Ravuya's Glow and give him some feedback.
I took a break from programming today and finished up a song I'd been working on a while ago with good ol' Fruity Loops [cool]. Here it is, for your listening pleasure:
Shift (~3MB - 128Kbit mp3 in zip file)
Unfortunately I had to zip it up, because GDNet won't let me upload mp3 files. I'd like to fiddle around with it a little more before I call it 'finished', but more than likely I'll never touch it again [lol].
As far as my programming endeavors go, I've actually been working a lot on VGUL. The ResourceManager is finally nearing completion, despite my having to re-evaluate its threading capabilities [headshake].
Salsa, eat your heart out!
Well, after the lack of responses to my programming game, I've decided to drop the idea, at least for now [smile].
I talked to my friend yesterday, and he says he wants to start up a project with me. He's really good with music, so we may put together a demo, using a lil' audio visualization and whatnot.
I've got a few ideas so far, but no general theme yet.
I tried researching the various audio libraries (DirectX's DirectAudio, OpenAL, SDL_Mixer, etc.), but I don't feel like any of them really meet my needs. OpenAL appears to be the best library of the ones I looked at, but I don't want users to have to install OpenAL to play the demo, especially since I can't redistribute OpenAL with my app. I'll probably go the DirectX route, even though all the layers of abstraction hurt my brain.
I also started working on VGUL again (yeah, yeah...). I've been working primarily on the resource management system. I think it's getting to be pretty solid.
I decided to strip out the built-in multi-threading support for resource loading and just make it thread safe. Later, when I develop my kernel system, a user will be able to launch a loading process in a separate thread. This should keep things unified and allow better error handling. I want to stay away from callbacks for error reporting when loading resources in a background thread; I'll let the user decide how he wants to handle the error reports based on his/her thread organization.
Keeping things thread safe is a real pain. The newest problem that has popped up is making collection files (files containing collections of resources) thread-safe. I may go the file-locking route, or I may try keeping track of open resource files somehow, and use normal mutexes.
Well I suppose that's all for now. Time to do some more research.
Man, I need to update this thing more often.
I've been designing a programming game, inspired by robocode.
In this game, you buy, trade, sell, program, and battle robots on-line. You start by choosing one of X base models, which you can then upgrade after you win some money in battles. Of course, for your robot to win any battles, you're going to have to program its AI.
On the technical side, I was planning on using C# and its compiler access:
Basically, all information is stored on one (or more) central servers. When a logged-in player whishes to edit a robot's AI code, a DLL interface for the robot is generated by the server based on the robot's type and statistics (more on this later), and is downloaded by the player, along with any AI the player has already programmed.
When the player is done editing the code, the new C# file is submitted to the server, and the server makes sure it compiles and doesn't do anything nasty (probably no file i/o etc.), and stores it back in the database.
When a battle is initiated, the server compiles the robots' AI files (again generating its interface) and starts processing the robot AIs. Information on the game state is sent to each spectating player, on a state-change basis (change in velocities, animations, etc.). Each robot AI would probably be processed in a separate thread, not so much to take advantage of multi-core CPUs, but to keep any nasty side-effects isolated.
Game-play-wise, as mentioned earlier, players can win money in battles, with which they can buy and sell robots and upgrades. Many robot upgrades actually expose new functionality in the robot's interface DLL. A rocket booster item, for instance, might add a 'Jump' command to the interface.
Players can also choose to bet on battles being fought by other players (they would have to be spectators in the battle) in order to win money.
My main concerns are in making sure that the C# code submitted by the players does not do anything that could break the server or 'cheat'. Most typical forms of cheating are blocked against, as everything is run on the server, but I'm bound to run into some naughty programmers. [evil]
I'm also not sure about editing the C# files. I think I plan on having the game run in windowed mode, so that a player can easily open up his/her favorite IDE or text editor to edit the files. I really don't want to try and come up with some crappy editor that's going to frustrate people, but at the same time, I want the transition of code->game to be as smooth as possible (not clunky). Any ideas?
Lastly, my original plan was to make the game 2D, most importantly to keep AI writing and math a little less complicated, but I'm pretty open at this point. What would you guys prefer? I was thinking either complete 2D or 3D models on a primarily 2D battlefield (restricted by dimensions, not art).
This might just be a pipedream, but it's fun to design things like this. If I went for it, I'd at least need some help developing it. Maybe, if I get this all laid out, I'll seek out some developers here on gamedev.
I have a lot more details on the implementation, game flow, requirements, and code structure written down in various files, along with a visio document or two, but nothing to glue it all together yet.
Would any of you be interested in playing or working on such a game?
I've taken a break from VGUL for a while. I think I plan on starting up again once I get the new logo from Salsa, assuming he has time to make it (I think he may have gotten more replies than he initially bargained for).
Alright, that's enough for one post. Maybe if I updated this thing more often, my posts wouldn't be so long [lol].
If you live in the U.S., or you happen to care, happy Fourth of July!
So yeah, I haven't updated my journal in a (long) while.
I've been playing around with the Torque Game Builder, getting familiar with C# (I love it!), and working on VGUL. I haven't decided if I want to continue doing any one of them [lol].
Over the past week or two, I've been working on a Resource Management library in C#. The library includes a resource manager class, abstract resource class, compressed resource collection files, threaded resource loading, and a resource factory class. It's all more-or-less working, but I still have to do a little cleaning up here and there.
I haven't quite given up on VGUL, although I've put it on hold for a while. Regardless, it's grown a lot since my last post. Here is an abbreviated list of what I added to it:
Image class with a configurable format - each image can have a variable number of red, green, blue, and alpha bits, or a set of palette bits, a flag for RLE encoding, and a designated 'transparency color', if the image is in a 3 channel format.
Tightened up the resource manager
Added some simple GUI utilities, including windows, edit boxes, static text, and buttons.
Tightened up the Log
Made a simple sprite editor (well, more of a sprite animation editor).
Made an abstract File System class for performing various common tasks regarding files and folders, along with a WIN32 implementation.
Put together an abstract input system, as well as SDL and Direct Input implementations.
Created a base Engine module that acts as the glue to tie all of the subsystems together. Applications using this module can be implemented via a DLL, with the main engine being an executable that dynamically links to it
Coded up a flexible, expandable, but untested, particle system class
Created a window class to deal with OpenGL window initialization
Added a Font and TextureFont class to the Graphics module
Added a Timer class
And probably more...
I stopped working on it, primarily because I'm not sure how helpful the library really is. I think there may be too many alternatives out there already. In any case, it's been a good experience.
That's all for now. Time to go eat. [pig]
I was sitting next to a co-worker the other day, whom was showing me something on his computer.
I noticed that once in a while he had trouble grabbing scroll bars or navigating menus without clicking on an unintended button. His cursor was off by just a few pixels now and again.
I got to thinking about how often this happens to me. I spend several hours a day on a computer, and I still have trouble fiddling with buttons and menus once in a while.
I also got to thinking about how much of the screen is taken up by buttons and widgets that exist for the sole purpose of navigation. In some environments/applications, there are so many that they begin to clutter the screen. It seemed to me like an annoyance and a waste space.
The only time I make no mistakes in a menu is when I have it spatially memorized. My hand just puts the cursor right where it needs to be, straight from muscle memory.
So anyway, I tried thinking of some ways to eliminate as many common buttons and navigation interfaces, and make navigating GUIS a little less tedious. Here are a few things I thought of:
- More extensive use of right-click-style menus
I think right click menus are very intuitive, useful, and space saving. It's like asking, "I want to do something with this item. What are my options?" Or often even more simply, "What are my basic options?"
- No more scroll bars
The worst of all GUI controls is, in my opinion, the scroll bar. It is tedious and lends itself to near misses or overshoots, and it doesn't really look all that great either. Getting rid of the scroll bar isn't easy though. I thought of a user holding a specified mouse button and dragging across a window to pan it - much like the hand tool in photoshop. But this creates the potential for a user to get 'lost', especially if the window scrolls both horizontally and vertically. I'll have to think about this issue a little more.
- More extensive use of history
I haven't thought out the specifics for this option, but I think somehow using history as an organization criterion more commonly would make navigating GUIs much easier. If there were some space on the screen dedicated to recent options, a user wouldn't have to think about where a previously pressed button was. Maybe there could be another sort of right-click menu known a "recent command menu" that would have a list of commands organized by history, either in a top-down list or in a radial style, with the most commonly used items closest to the cursor.
That's all I feel like coming up with right now - I need to get some sleep soon [lol]
Everyone and their mother wants to make a better GUI, and I know there is no perfect answer, but it's definitely an interesting topic to muse on.
What do you guys think? Do you have any ideas on how you'd make common GUIs easier to use?
I added a global Log printer to VGUL along with a project exemplifying its intended common usage.
I thought I would use my first journal post (yay for my new GDNet+ account!) to announce a new project I've started -
VGUL - the Video Game Utility Library.
VGUL is targeted at the casual game developer whom wants a small,reliable, and robust code base containing classes and systems commonly required in game development, such as 3D/2D vectors, images, and colors.
VGUL isn't meant to compete with professionally built engines and libraries. It is meant to provide stable base code for a developer whom wants to start coding his/her game immediately, without having to write non-specific code that exists in nearly every game.
Currently the library is quite small, but development has been fast, so expect it to grow quickly.
You can download the MS VC .Net 2003 project here:
The library is written in C++, and is currently platform specific to Windows (32). The code was written with portability in mind, so I expect to release some Mac and Linux versions in the future.
The library makes use of namespaces where it can, and each file in the library has a name consisting of the contained class/system preceeded by the namespace it resides in. For example, a class called "Foo" in the "VGUL" namespace would be in a file named VGUL_Foo.h. A class called "Yo" in the "VGUL::Graphics" namespace would be in a file named VGUL_Graphics_Yo.h, and so on.
One main focus of mine for this project was documentation. I've documented every class as extensively as possible. All documentation is created with Doxygen.
Doxygen documentation is included in the zip - take a look at all the classes and namespaces in VGUL thus far.
I also suggest looking at the Example_ResourceManager project in the solution for a well commented example on how to use VGUL's resource manager.
If you have any constructive criticism to share, comments about the structure of classes/namespaces, corrections to documentation, or bugs to report, I'd be happy to hear them [smile].