GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - GEL and Foundation (Engine Tools) Page Previous  1, 2, 3, 4  Next
View previous topic :: View next topic  
Author Message
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Sat Jul 03, 2010 4:59 pm    Post subject: Reply with quote

That's a nice bit of progress for a single day!
View user's profile Send private message Visit poster's website
n29
Developer

Joined: 13 Sep 2005
Posts: 879

PostPosted: Sat Jul 03, 2010 6:39 pm    Post subject: Reply with quote

Any plans for doing view frustum culling of the terrain, or LOD? Do the Gems books have anything to say about these two subjects (terrain culling and terrain LOD)?
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sat Jul 03, 2010 6:52 pm    Post subject: Reply with quote

I actually don't need very large terrain, which is why I went straight to Triangle Strips from the get go (to brute force it as optimally as I can). What I'm making it for is to use as a simple cave-like room maker.

Instead of having to model rooms like this, and import them.




To be able to quickly build a room in-game, and add a new one as we go along.

Switch to a top-down view or such, then use a simple mouse controlled paintbrush to rough out a room shape. Apply a standard generated texture according to some rules (tops fade to black/neutral). Walk/Fly around and drop interesting details as you explore the game world (editor mode).

Ultimately, the goal is to make something vaguely like this mockup.



I say vaguely, 'cause I want it to look awesomer than that. :)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Jul 04, 2010 3:49 am    Post subject: Reply with quote

July 4th - 7:49 AM
Happy 4th. Very rough 3D model loading (my old native text format, verts and faces only).

_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4998
Location: Silicon Valley!
PostPosted: Sun Jul 04, 2010 11:36 am    Post subject: Reply with quote

Is that a monkey?
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Jul 04, 2010 1:25 pm    Post subject: Reply with quote

Yes, that's the Blender Monkey Head. Other 3D software uses a Teapot, Blender uses that.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Aug 29, 2010 10:19 pm    Post subject: Reply with quote

August 30th - 2:25 AM
Okay, I've been intensely thinking and reading the docs for how one would actually use a language like Pawn for specialization. Here's me thinking out loud.

As for what Pawn can do, it can do simple integer arithmetic, some string stuff (you wouldn't want to use it for manipulation, but hardcoding filenames or identifier strings is OK), and includes language features for passing references (pointers) and arrays around (I'd probably go with pointers to vectors or matrices myself). VM instances are extremely light weight, using only a few hundred bytes, some more for tables of named references to all global and native functions as well as global variables, and (by default) a 16kb stack+heap. So it theory, you could instance lots and lots of these. It also supports VM cloning, which will make multiple VM instances use the same code (making each instance use like 200 bytes of internal data+16k stackheap).

The problem is the VM seems to only support 1 loaded program (plus libraries), though maybe that isn't much of a problem noting the actual memory usage. Each script used in a game would then be 1 VM per, or 1 VM per file and several clones (especially if a script is used multiple times); But if a script is used multiple times, then it may as well be 1 instance, and you pass a different argument (object) to modify. Any function can be called from a VM instance, and after the first time it's run, will run faster (as function symbols resolve+remember).

So okay, maybe "how to use it" isn't so much a problem after all.

Where to use it is a different story.

- Particle Generator
- Menus
- Entity Specialization (by default an entity is dumb, but has stats and perhaps sensors/features for detecting things around it)
--- Characters (hook controls up)
--- Enemies (tell them to hunt players, follow paths, etc)
- Weapon/Item building (play back animations?)
- Adding map features like keys and events

Particle generators: given a position and maybe some other data, spawn particles. Or given a character, a position (or distance/direction from the character), and a spline curve, orient the curve in some direction and step along the curve generating particles. I dunno, maybe. Those almost sound like 2 options that could be implementation hardcoded, and just swap out the curve and chosen particle. To make scripting meaningful, the effect would have to use multiple particle types, cues, and whatnot. I'm not sure what's best here yet, and what sort of tools are needed to make better effects.

Menus, all my flow/state/control stuff is handled in a big long hardcoded tree of switch statements. My layouts are external files (currently embedded in the executable), but they only describe what a screen looks at and where (UV) to pull art from a texture. I think ideally all menu flow, screen to screen, should be moved to some scripted layer. Then either the game is always running (just idle), or a game instance is chosen to be run (if multiple games launched from a scripted menu). I'll probably go with "game always running"; That way, messages can be passed to the game about creation, things that need to be cached, etc. Certain menu states are flagged as "Game Inactive", no loaded map or something; This is different than pause menu. I dunno, just thinking out loud.

Entity Specialization, I think the right way to do this is to do all the game controls in a script. Have/collect enough information that a player instance can interpret it as a high level responder (double clicking on an object, know what object that was, etc). Enemies handle the same way. Look to prebuilt curves that you can follow to traverse the level/find the nearest route somewhere, and/or a zone to stay within. There will probably be entity files that say what script to associate 'my' actions with (possibly with arguments for re-use), what art set to use, how big a default one is, what color scheme. Then in the map editor, allow overloading/scaling of values for special purposes. Hmm.

Weapon/Item building. Item use is easy. If it's a potion, give "drink" option, and restore health of the target if it was a healing potion. Knowledge of entities and such. Fun time. Weapons, I'm not sure yet. Playing back animations, or rather, knowing which one to play back when maybe (if a sword and more skilled, play back a fast 2nd strike), and effects to give victims of the strike (poison). I imagine weapons like swords would be generic and use arguments to say if it gives a poisonous effect, or how strong/fast to make it.

Finally, Map Specialization. Treasure chests and other things you can search probably needs hooks. Trigger a trap (or nearest trap), unlock a door, etc. I'm sure there's a nice way to do this, coming up with unique Id's and (somehow) passing them as arguments. Or inform all trigger-able things of Id "blah" to activate. I dunno how I want to handle stuff like this yet, but it should definitely not be hardcoded.


Also I've been wondering when to reload/check for changes to script files, and realized dumb simple answer: after the game window regains focus. I don't plan to integrate a text editor, so script editing will happen in another window in an external editor. Normal workflow would then be to put the game up on a 2nd monitor, make some changes, save/recompile scripts (only downside of Pawn is it requries compiling, but that can be automated), click over to game window and see changes.

Anyways, I think I've done all I can (or rather, should) for now. I've been thinking about trying Pawn for a while (too long), so I'm glad to have finally buckled down and tried it. My other option is Squirrel, which I do like, but have been wondering if I even need something as sophisticated. Pawn's actual source code is easy to follow (1 main file for the C implementation of the VM), so I feel a bit more confident that I could fix it if needed.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Mon Aug 30, 2010 5:33 am    Post subject: Reply with quote

Quote:

Menus, all my flow/state/control stuff is handled in a big long hardcoded tree of switch statements.


Eh... I have this going on as well. It's easy enough to drop in a new set of code to handle a menu, but after finishing Inimicus I'm starting to wonder if there isn't a slightly better way to approach that. However, I suspect I'm close to a tipping point where anything I add to make my life easier may end up costing me more time to implement and maintain than the potential savings I'll reap from the addition.

I was thinking of some sort of natural language script for menu creation, say...
"Window 1 is 48x72 at coord 100,200,0 with 12 options starting at index 40".

Then I could append details to it with an "and". It wouldn't save me that much time, but my code can get cluttered quickly when I have a menu with a bunch of individual windows (which I'm very fond of for some unknown reason). There are a lot of window attributes that need to be set, and it can be a pain to do a standard create_window() call, then modify a dozen attribs.

Perhaps I'm on to something? Perhaps not.
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Mon Aug 30, 2010 6:16 am    Post subject: Reply with quote

Well the one timesink I remember about menu building is I had to rebuild the game every time I made a change. In theory, moving the actual menu coding to scripts means I could alt+tab, make a change, alt+tab back, and go back+forward to see my changes right away. But you're right, it's possible to overdesign something so that it's even worse to work with. I also have the problem of localization that, last I tried it (I added an Italian port late last year for a contest), really added a lot of fat to the code. So there's more work to be done anyways.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Mon Aug 30, 2010 6:26 am    Post subject: Reply with quote

Quote:

Well the one timesink I remember about menu building is I had to rebuild the game every time I made a change.


Oh yeah... how could I have forgotten about that?! Very true; having an external script could save some time in that respect.
View user's profile Send private message Visit poster's website
sonrisu
Moderator

Joined: 31 Aug 2005
Posts: 4998
Location: Silicon Valley!
PostPosted: Mon Aug 30, 2010 7:43 am    Post subject: Reply with quote

I guess compile time for something like that is a hassle... but really? Is compile time really that bad for you guys that making a change to one file really takes too much time to recompile/rerun?

I mean, I can't argue that alt-tabbing out, modifying a file, and alt-tabbing back in is slower. It's not, and it likely never will be. But, is it that much slower that you want to script your entire menu system just for that small time-savings?

Use moar beefy development machines!
_________________
loomsoft :]
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Mon Aug 30, 2010 8:22 am    Post subject: Reply with quote

Quote:

I guess compile time for something like that is a hassle... but really? Is compile time really that bad for you guys that making a change to one file really takes too much time to recompile/rerun?


Compile time isn't the issue for me, but usually I lose time getting back to a part where I can test the routine in question. There are times when I modify the flow of the program to bypass the main menus and dump me into a running session as soon as I execute, but that's dodgy and I'd rather not have to resort to that at all.

Little things add up quickly.
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Mon Aug 30, 2010 8:41 am    Post subject: Reply with quote

Yes, the little things add up.

My compile time is okay, but linking is slow (can't multithread that). Also, C++, so most code is in header files. But it's mainly as Sirocco said, having to exit out of the game, restart the game, then go back to what's being worked on. A subtle couple pixel nudge takes so long to do, recompile to test, then find out it's wrong and repeat. Menu building is tedious enough as is.

The real benefit though is in-game stuff. Being able right away try the game thing you're working on, instead of having compile the game, run the game, browse through the menu to the level skip screen, pick the right one (or not, then have to waste time running to the right room/redoing the sequence), then reproducing the event. Incredibly inefficient.

Lets put it this way. Look how long Neverfall has taken you. I bet a vast majority of that lost time is in content creation: Making content and testing it. A piece of content is often created and tested several times before it's considered final, so more and more time between creation/editing and testing adds up. If the process of creation and testing was faster, you could get more done in less time. Not to mention, the more time spent waiting, the more of your "groove" for that day/evening is lost.

I don't trust scripting enough to do a whole game in it. I'd still build an engine and the game features in C++, but by generalizing, the engine code can stay cleaner and easier to maintain.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Mon Aug 30, 2010 11:17 am    Post subject: Reply with quote

Has anyone tried the HTML rendering APIs for menus? We had a thread about it a while back. Library that could render a webpage on a quad through either the Chrome or the Firefox renderer.
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
xearthianx
Developer

Joined: 28 Sep 2006
Posts: 771
Location: USA! USA!
PostPosted: Mon Aug 30, 2010 5:51 pm    Post subject: Reply with quote

Another possibility: a super lightweight menu editor that outputs the necessary Pawn (or whatever) code. You could then design it visually, and preview how it looks in general even before you bother to load it up in the game.
_________________
Ionoclast Laboratories - Scientia et Dominatia!
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Mon Aug 30, 2010 5:59 pm    Post subject: Reply with quote

Yes, I need a visual editor for my UI/Screenmaker.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
xearthianx
Developer

Joined: 28 Sep 2006
Posts: 771
Location: USA! USA!
PostPosted: Mon Aug 30, 2010 6:29 pm    Post subject: Reply with quote

It could almost be a specialization of your typical map editor functionality. I mean really, at one level they are doing the same thing: defining how things look, and how the user can interact with them.
_________________
Ionoclast Laboratories - Scientia et Dominatia!
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Mon Aug 30, 2010 8:12 pm    Post subject: Reply with quote

What I'd like to do is build some general purpose editing... um... thingies. I don't actually know what that means, but some sort of general editor code I can spontaneously decide to use as an editor for an arbitrary data structure (a 2D array, an array of a type, etc). My UI code is fine, but if I could smash a hotkey to bring up the editor for the currently active "screen" (TitleScreen.sc), that would rock. I'll have to do some work on generalizing my file formats and loaders, but it would be worth it.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
n29
Developer

Joined: 13 Sep 2005
Posts: 879

PostPosted: Tue Aug 31, 2010 5:32 am    Post subject: Reply with quote

I've worked an f*ton with gui's over the years. The past year I've been dealing with Java Swing gui's at jorb. There are a lot of options to programmatically specifying gui's. There are numerous projects in Java and .net to specify gui's in xml files for example. Swing and Win forms both have various layout managers that automatically position components so you don't have to do pixel by pixel positioning.

So adopting this approach, why not specify a gui in an xml (or yaml) file, set a key to reload/parse the files in game, and test that way?

Other wise, so far as using scripting for menus (gui's in general) it seems like the challenge is defining how the game engine will handle gui's relative to the rest of the game engine. Then figuring out how to handle he gui separate from the other running parts of the game engine. Thinking about this quickly becomes quiet heavy.
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Tue Aug 31, 2010 8:18 am    Post subject: Reply with quote

n29 wrote:
So adopting this approach, why not specify a gui in an xml (or yaml) file, set a key to reload/parse the files in game, and test that way?

That is probably what I'll do at first. Right now it's an arduous process of editing my my layout script, processing the script from text to a chunked binary format and converting it to a .c file (to embed it in the executable), then recompiling the game with the updated files. So before any of this can happen, I need to isolate this workflow and open it up to working externally instead of only internally. That's also why I'm looking at scripting, to drive the flow of the menus outside of the game code.

Though probably the most time consuming part right now is dealing with texture co-ordinates. I need to build a thing (or list of things) by specifying what texture file to use. A texture is dumb and square though, so if you want a button in the corner of it, those co-ordinates need to be entered. Right now graphic elements that use a piece of a texture and dummy elements are the only things supported. Dummies I use for a position and hardcode a text draw relative that position. I still need to add proper text placement support (that was pending a proper localization system), compound/macro shape drawing (boxes/borders), and 3D models (backgrounds bigger than the screen).

Quote:
Other wise, so far as using scripting for menus (gui's in general) it seems like the challenge is defining how the game engine will handle gui's relative to the rest of the game engine. Then figuring out how to handle he gui separate from the other running parts of the game engine. Thinking about this quickly becomes quiet heavy.

Right, that why I'm not planning on abandoning my layout files, but perhaps adding scriptability to them (either embedded or external references to a script file). What I want to do is remove the hardcoded flow and state changes from the game's code. For the most part, I imagine menu scripts will be dumb and straightforward (if "OptionsButton" clicked, state = "OptionsScreen). What I should probably do is give them the ability to read information from the game's core, and write to layout files. Such as player statistics or names; Grep these, and fill out a layout template based on the data available (10 HP, weak to fire).
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
xearthianx
Developer

Joined: 28 Sep 2006
Posts: 771
Location: USA! USA!
PostPosted: Tue Aug 31, 2010 11:54 am    Post subject: Reply with quote

n29 wrote:
Other wise, so far as using scripting for menus (gui's in general) it seems like the challenge is defining how the game engine will handle gui's relative to the rest of the game engine. Then figuring out how to handle he gui separate from the other running parts of the game engine. Thinking about this quickly becomes quiet heavy.

I dont see why this has to be a big deal. Why is a GUI element fundamentally different from an enemy or a moving platform, or a wall for that matter? It's just another thing that needs to be drawn to the screen according to its current state, and have some sort of interactive logic.
_________________
Ionoclast Laboratories - Scientia et Dominatia!
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Dec 19, 2010 11:17 am    Post subject: Reply with quote

Picking up where I left off. Trying to get something basic going this weekend for Ludum Dare.

The code rotted a bit (since it hadn't been touched since July), but it's now back in working order.


_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Dec 19, 2010 3:25 pm    Post subject: Reply with quote

Put these in just 'cause. Not actually functional yet, just artwork.


_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Mon Jan 31, 2011 3:46 pm    Post subject: Reply with quote

Braindump!

I have begun what should be the final (haha) directory tree overhaul. The Smiles repository contains over 2000 commits, and while the repository works fine, I think I'm going to finally retire it as my upcoming changes are rather fundamental. Also, I've been working out of a tagged folder "SmilesPSP" instead of the trunk since I finished iPhone... eeee!

My current working style has me using a shared repository for my active game projects. There's a rather significant problem with my current layout, as I don't have a good place to store non-smiles content. Also, I have multiple export paths (source->RGBA4444, source->DXT5, source->PVRTC, etc), and some aren't too useful to certain platforms (PVR's don't work on PC video cards). And that's just texture formats. I expect to eventually add paths for storing geometry, lightmaps, global illumination info, as well as final merged data in platform friendly formats. To be honest, I don't even know what I need or want, but one thing is for sure: I need space to grow, specialize, and figure out what the heck I'm doing. ;D

So starting with a standard trunk, branches, tags layout, I'm adding 2 subcategories to the trunk.

svn://server/repos/trunk/code/
svn://server/repos/trunk/content/

"code" is repository root that should be checked out by any client. "content" will contain several content repositories, one for each project (Smiles, Legends, Experiments).

A checkout of "code" will look similar to the following.

/Content/ (SVN::Ignore *)
/src/ ...
/Targets/ ...
/Tools/ ...
/content.sh
/makefile
/todo.txt

There will be more, but this is where it's at right now.

After a fresh checkout, the first thing you'll need to do is generate some files about the target you want to build. If you don't do anything, running "make" will read the makefile and grab some default settings, dumping files like ".repos" and ".project" in the root folder.

With that done, you're able to compile a native binary of the game by running "make" again.

However, you wont have any content for the game to use. What's notable is that even though this is the code folder, it has a "Content" folder. This is actually an empty dummy folder, but will exist for every project.


With Smiles I maintain an Art folder, which would be processed generating one of many Content folders (Content/4444, Content/DXT5, etc).

In my new layout, I'll be using a shell script (content.sh) to set-up and check-out assets for the current project. The shell script will take a description and grab those files, and use an SVN like vocabulary.

"./content.sh checkout all" will pull down all files, including source content and tools.

/Content/Art/ ...
/Content/Sound/ ...
/Content/Music/ ...
/Content/Tools/ ...

Otherwise, you can explicitly say what content you want with "./content.sh checkout Art/src Art/4444 Art/DXT5 Sound/WAV Music/OGG64 Tools", which will get you quite a selection of files, 64kbps version of the music, as well as the tools. At a later time you can explicitly checkout new content sources, such as "./content.sh checkout Music/WAV" for the unconverted music.

Tools is a shared repository of content conversion tools alongside the different project content folders (since my tools will be the same).


I'm still working on my structure and scripting. I wont start working out of here until it's finished. So far all I have done is general shell script maketool.sh for compiling my dependency-less command-line tools (TreeTool, Bin2C, UITool, ...). Whee.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Apr 03, 2011 2:42 am    Post subject: Reply with quote

Upgrading my MinGW (my existing one is from 2008).

The official MinGW+MSYS now uses the same bash shell as Cygwin (green on black instead of the wild blue on yellow uglyfest). There's also a proper installer, where all you have to do is run it and it'll do all the work.

New with MinGW, you need to specify "-static" on the command line to statically link the libraries, as the default option is to dynamically link (and there any many .dll dependencies).

Built SDL on it just fine, built my game code on it, however I'm now having problems getting my text stdout and stderr output. Dummy app works, but not SDL app. Hmm.

EDIT: Okay, so I was right that upgrading would fix my problem. Compiling with "-mwindows" now kills the log output (as it should have, when combined with SDL... this wasn't true with my 2008 version of MinGW).

Great! Everything less buggy now! Huzzah!

* * *

MinGW-64 in an easy to use installer can be found here:

http://tdm-gcc.tdragon.net/

Still haven't tried this out yet, but it seems easy now (compared to the official distribution of MinGW64).

EDIT: TDM GCC works slightly different than MinGW above. No "-static" is required, and the 64bit version supports "-m32" or "-m64" to pick the architecture you want to build for. Also the resulting executables are smaller.

* * *

Before I started on this though, I got Squirrel scripting working in my code (again). I found a glitch, but I'm thinking it's related to my ancient MinGW version.

EDIT: Yes, it was the MinGW version.

* * *

Have been looking at Bullet, the physics engine too. Seems really well designed (and is available optimized for PS3). Am hoping to do a test with it later today.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - GEL and Foundation (Engine Tools) Page Previous  1, 2, 3, 4  Next
Game Developer's Refuge
is proudly hosted by,

HostGator

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.