Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    37
  • comments
    68
  • views
    46931

About this blog

The development journal of a very strange, mentally unsound Canadian.

Entries in this blog

 

Procedural generation, why do you mock me so?

This isn't supposed to be a bunch of drunk mesas. What I've been trying to get (and failing consistently) is a single huge pit, with the occasional ledge, split path, or floating island as one continues down. I think I'll have to get someone else to handle the world gen stuff for this little project, and just focus on the actual game play instead.

coldacid

coldacid

 

Project reports

I'm thinking about using this space for weekly updates on my projects, and perhaps also other things that I'm doing that aren't really game dev related, but still have to deal with accomplishing anything. My professional personal site isn't really the place I want to put such status updates, and given the content of my Tumblr account, it doesn't seem like a good fit either. Therefore, I'll use here.

I'd post once a week, probably Friday or Saturday, detailing what I've accomplished, what I'm working on, and what I've completed since the last report. I guess I could even start now, although I'd probably cover stuff for the last two weeks since this week was pretty much blown (I screwed up big on Sunday, and it wasn't until Thursday morning that I was able to recover).

Symbol guide:
[x] Complete [-] In progress [ ] To do[size="3"]
UFO Panic!
Completed / In progress:
[-] Started moving from a simple App Hub inspired framework to Nuclex. It provides a number of services that I had to implement myself, so I'm currently excising the now-superfluous code to bring everything over. Dependency injection is an issue, though -- it's not a concept I'm really comfortable with, although I know the benefits it brings. Another issue is Nuclex's GameStateManager doesn't provide access to the GameServicesContainer it holds onto, but doing things the DI way means I either have to haul a bunch of services I may or may not need along in every state, or have a singleton object that gives me access to my Game class' Services property. Neither of those seems very clean at all. [-] Reading Rollings and Adams on Game Design for ideas on improving the design of UFO Panic as well as how to better express the design.To do:
[ ] Provide an IEntity interface for entity types. Possibly also provide other related interfaces for entities with special needs or abilities. Update EntityManager to rely on IEntity rather than the object pool supporting Entity abstract class. [ ] Extract Sprite from the entity hierarchy; entities that need to be drawn should have a Sprite, not be one. [ ] Work on writing out the actual game design and sticking it in the project Trac site.
[size="3"]Painter Story
Almost no visible progress for a month now. Working through one scene, but haven't been able to get any writing on it done for weeks. Haven't seen any progress from the other writers in at least as long.

Completed/In progress:
[-] Writing opening scene of prologue. (No progress for weeks, though.)To do:
[ ] Write final prologue scene. [ ] Beat outlines for Monday scenes.

coldacid

coldacid

 

Project announcements

All the old projects formerly discussed here? Dead. So what am I currently working on, you ask?

[subheading]Painter Story[/subheading]
Painter Story is a visual novel telling the story of a transfer student and artist who encounters the subject of one of his paintings. After years of moving around every few months, our protagonist finally has the opportunity to settle in one place and start building lasting friendships. But when one of his paintings comes to life, he must choose to follow his feelings for the girl of his dreams, his classmate, or a friend from the school art club.

I'm the story designer and main writer on Painter Story, as well as project lead. Zahlman is also writing for PS, but his main role is scene direction and programming (as it is). There are a couple other people on the team as well, but as far as I know they're not GDNetters. We're using Ren'Py to power things, and the project's been stop-and-go since it started about a year ago. However, we're getting better at keeping momentum now (I think).

[subheading]UFO Panic![/subheading]
This one started life as an XNA do-over of my entry for the first TOJam back in 2006. But since starting on this project, I've seen a lot of potential for it, and I've been working on expanding it from the simple little one-screen game it originally was, to something worthy of XBLA or Steamworks. The team for this project is currently just Zahlman and myself, but we're looking for people who can do asset development and further game design as well.

coldacid

coldacid

 

Gone fusion...

Just a note: This journal has been combined with my regular journal and now exists at http://coldacid.net/blog/1>.

coldacid

coldacid

 

cIRCulation alpha release soon!

I've got a couple of little stupid bugs to iron out, but soon I'll be able to put out a public alpha for cIRCulation! I guess that means putting up some content for the cIRCulation site too, though.

Perhaps I will also provide some preliminary documentation for plugin authoring.

coldacid

coldacid

 

cIRCulation tested, again!

As we speak, cIRCulation is running on #gamedev, with at least a few of the bugs worked out. I'm planning to put out an alpha version soon for people to download.

coldacid

coldacid

 

Project news

Sorry for such a long time between posts.

So cIRCulation has seen some changes since the last post. I still haven't added interpretation for actions, but I've finally implemented the command parser and added a plugin system on top of that! Some cleanup, and I'll probably release an alpha build out here.

Meanwhile, I've begun work on another project -- Raceway Construction Kit is its working title, and it's more or less a remake of an old EA game, Racecar Destruction Set. I'm currently putting together a prototype on XNA, but I'm exploring other options for the final game, including Torque or OGRE.

coldacid

coldacid

 

cIRCulation's Live Test

Today was the first time my IRC client cIRCulation ever got to see a public server. I brought the project with me to the college today, and ended up running it in #gamedev for a while. No crashes, so it actually works despite having almost no functionality beyond plain old chatting.


Version 0.1

coldacid

coldacid

 

OGRE's resource/archive system, testing, Ruby

The work of splitting Asylum into three modules (platform-specific executable, engine DLL, game DLL) is complete. I did all the work on a branch I created just for this purpose, and gained hands-on experience for branching and tagging with Subversion. Forget about my previous beefs about how it's done -- now that I've actually tried it, I like it!

I've begun experimenting with OGRE's resource/archive system this morning, hoping to do some virtual file system magic with it. So far the experiments have been promising, but OGRE loves to throw whenever it encounters duplicate resource definitions. It'd be nice to be able to tell OGRE to just ignore duplicates rather than stop and refuse to continue along that track.

I need to replace the old test framework in Asylum with a better one. When I started writing Asylum, I simply had a pure virtual class from which I created actual classes containing setup and test code. Unfortunately, the recent changes to Asylum (mainly being that the test framework now runs from the engine DLL) have killed the poor thing dead.

I've used CppUnit in the past and I'm learning to use NUnit now, but those are just unit testing frameworks. I've used the old test framework to do more than just hands-off unit testing -- it's provided a way to drive the console system, for example, and I was trying to use it to explore and enumerate resources in OGRE when it decided to shuffle off its mortal coil. Anyway, I don't think that Asylum actually needs a full fledged unit testing framework yet, as most of the code is too simple to worry about things such as regression. When there's something wrong with the code, it simply doesn't build (or if it does, it goes to the problem and INT03s it right into the debugger).

However, now that I'm defining and exporting interfaces (such as the System object interface from the executable, or entities in the game DLL) I should start unit testing.

On another note, I need to find the Ruby equivalent of Boost.Python. I want Asylum to be Ruby scriptable (I have issues against Lua and Python, the holy war kind), and I want to hook it into the console so every input line is either a cvar, command, or Ruby one-liner. On the upside, it's probably easier than I think to hook in Ruby manually, as pretty much everything reflected into Ruby should stick to certain general interfaces, anyway.

coldacid

coldacid

 

First there was one, then there were two...

And now, there are three.

Three what? Three projects comprising Asylum itself. In the beginning, Asylum was monolithic, a single asylum.exe that held all the game code. Then, I spun the engine out from the game, giving me asylum.exe and asylum.dll. Today, I spun the platform-specific code from the engine, which now rests in asylum.exe, while the engine code is in engine.dll. The file formerly known as asylum.dll is now asylum/game.dll and game resources now share a folder with it.

Why did I do this? Because I needed a way to provide services to the game DLL from the engine, without going through callback hell. So, now asylum.exe calls game_main in engine.dll, passing along a struct of function pointers (well, virtual functions) as well as argc and argv. (For Win32 I've had to chop WinMain's lpCmdLine to make argc and argv. I'd show how, but there's more than enough code out on the internet that already demonstrates it.) The game DLL depends on the engine DLL (implicit dynamic linking) while the engine DLL is only interested in what the game DLL registers with it (game states, entities, etc). The engine DLL depends on the executable (reverse explicit dynamic linking -- that means that the executable calls LoadLibrary or dlopen on the DLL rather than the other way around) and when the engine's entry point, game_main, is called, it gets from the executable what it needs.

So far there's pretty much no platform specific code in engine.dll or game.dll, so to get Asylum building on other platforms all I need is to implement the platform specific side of things (getLibraryHandle, getLibraryFunction, getDirectoryPath, etc) and pass along control to game_main. Easier done than said.

Asylum stats:
[font="Courier New"]Total lines of code: 5536
Source files: 77 (doesn't count pch related files or resource files)

Mean lines/file: 71.89610
Median lines/file: 50
Mode lines/file: 32

Most lines: 343
Least lines: 17[/font]

coldacid

coldacid

 

The dead game has risen...

Asylum's not dead! I've been making progress with the development of the engine/framework itself, and I've begun seperating the game from the engine.

Things I need to do, however, include rethinking the menu UI. Originally the design was very much that of a HFSM, but I'd be better off just supplying a UI system based on a card stack and having all the actual menu stuff in the game DLL. The menu appstate would simply pass messages from OIS to CEGUI (which in turn would pass events to the UI controls on each card) until the appstate changes.

Another thing involves the build system, a most wonderful mutt of MSBuild, gmake, bash scripts and batch files. Despite sounding terribly kludgy, it works like a charm, and it goes from source code to burning the CD. The problem itself involves a lack of ASPI drivers, which makes Cygwin builds of cdrecord quite cranky. Hopefully the ASPI drivers Adaptec makes available should take care of the problem, but it'd also be nice if cdrecord had an image writer mode so I wouldn't have to use media. At least mkisofs doesn't care about all that, so at least I get an iso of the data track to mount and test.

Current research for the framework involves OGRE's resource management system, and making an FmodEx driver for TheoraVideoSystem.

Right now, Asylum sits at 5428 lines of code in 75 different source files (not counting any resource.h or pch source) over 4 projects (engine, asylum, autorun, autorun/ogrehelper). This doesn't count the Inno Setup scripts, resource scripts, or the build system.



In other news, I'm canning Alien Abduction. With all the projects I'm already involved in, this buggy little game is just too much for me to maintain alone. I'll be putting up the source (or perhaps the whole SVN repository) sometime on Saturday, and in the meantime I'll tidy it up. SDLRPG is also on the chopping block, but only temporarily. There's still things I want to do with it.

cIRCulation is coming along nicely. Another all-nighter and I should have channel and chat windows working properly (that is, they'll finally recieve message and join/part events). The big jam here is actually parsing messages as they come in off the server, since I'm used to Perl regexes and not .Net ones. I keep catching threading errors with cIRCulation now, though, something to do with my server message pump being run on a timer and therefore on a different thread than the UI. It's not a serious problem, but it is bloating up my WinForms code, because anything that message handlers touch in the forms needs to use some workaround that re-throws the message. Damned annoying.

coldacid

coldacid

 

Oodles of stuff!

Let's see, where should I start? Since my last update there's been quite a bit of development going on. I've been continuing with my game launcher, the framework I've been writing for Asylum has been spinning its wheels, and I actually got another game to a playable state!



So let's begin with Alien Abduction!, the game I created back in early May for TOjam. In a nutshell, you're controlling a flying saucer (which just happens to be the observation deck of the CN Tower) and abducting aliens. The game is far from complete, with the currently available version being 0.1 (and 0.2 currently under development).

I've stuck to my usual design: the game itself is a finite state machine, with a stack of game states (currently Intro, Play, and Endgame, but more to come). I have an interface that game states must match, which includes certain SdlDotNet events that the game class subscribes to.

I've also got a set of different entities matching a common IEntity class. This is probably going to get a bit of reworking soon, with one of the entities being removed (and its code placed into the Play state, where it more properly belongs). I want to add a Collision event and rework the current collision handling code to be more efficient.

To be honest, the code right now is absolutely horrible. Hacks upon hacks upon hacks, thanks to a 50 hour timespan and certain deficiencies with SdlDotNet. Such as a lack of sprite rotation, WTF? If I had the source with me right here, I'd paste in what godawful hack I did. There's also many entity leaks, by which I mean entities escape from the clutches of the EntityManager and continue living when they shouldn't.

It's not all bug fixes, though. I'm planning to add mapping to the game. I've been working out a simple map format that shouldn't be too hard to load and draw. If you check out the screenshot here, you'll see that the game uses 3/4 view ("iso") tiles. The idea is that tiles will be stored in rows as such:


Row A: 0 2 4 6 8
1 3 5 7 9
Row B: 0 2 4 6 8
1 3 5 7 9

Drawing them will take two passes per row, first drawing the even-numbered tiles in the row and then the odd-numbered tiles. Each tile draw will also take care of drawing any entities on the tile, so that proper occlusion takes place.

Right now, aliens appear whenever you abduct one, and the defenders appear every time you have captured a multiple of five. Once the map system comes in, aliens will arrive from buildings and defenders from factories. The buildings can be destroyed for power-ups, but that will reduce the number of aliens who can be spawned, thus possibly reducing the player's total score for the level. As for the factories, I haven't decided if they'd be immortal (which would be confusing for players) or to make them destructable at a cost.



My game launcher is working better than before. I still don't have any OnMouseOver type events on the buttons on the main dialog, but the settings dialog does OGRE RenderSystem choosing, FMOD output system choosing, and OIS joystick/gamepad choosing. Not all that much to report, other than that I've integrated it into the Asylum framework already, and expect great things of it.



And then there's that. I've been continuing to work on the framework, but I've not been making much progress, at all. My OIS problem (not getting input to pass to game states) was solved by not asking for exclusive access to the mouse and keyboard (and something else I've forgotten) -- in all, two lines commented out and the thing worked like a charm. Next step is getting the video service in and working, this time seperate from the movie playback state. (Either have the movie playback state a singleton and have annoyances trying to play a certain video if someone's already pushed some into its queue, or not have it a singleton and have loads of memory use -- and leaks. Not this time, damnit.)

coldacid

coldacid

 

FeedMonster, website, articles, Launcher

FeedMonster is my Java class project. It's a news feed aggregation website. It sucks, but it works (kinda), and I'm presenting it in class today. I'll be putting up a tarball of it online later this week as an example on how not to do Java coding. By the way, NetBeans furthers the cause of The Great Satan.

FeedMonster is currently missing the ability to slurp Atom, but the architecture makes it pretty simple to add it, or any other newsfeed format for that matter. For RSS feeds it uses Xerces to do SAX processing on the document. The website frontend is a mixture of servlets and JSP that's still pretty rough. There's also two servlets to put out Atom feeds, one for the latest articles that the 'Monster has hoovered, and another for just the latest from user-selected feeds. (It should be noted that the timestamp from those output feeds don't meet the Atom specs, but Sage hasn't complained so I'm cool with it.)



I've updated my website. It's almost complete, content-wise, but I'd like to add some more features. Such as adding a PHP script for downloading files, rather than the direct download method currently used. That way, I can keep track of how many downloads I get on the stuff I put on the site.

There's some other enhancements I could whip up, but I'm not going to bother, for now. I need to take the site out of beta.

Which brings me back to content. I need to break out a pen and start working on my Ruby article again, before someone beats me to it. I'd like to put up some writings on my website and into my career portfolio, but I need to write them first.



I've been working on an MFC application for configuring and starting any OGRE-based game I may start in the future. So far, Launcher is pretty much based on the launcher from FreeSpace 2 (down to the same graphics in the dialog window) but it's pretty lightweight and can be easily manipulated to have any look I'd like.

Right now I'm having a bit of an issue with OGRE, however. Well, with how it lays out its configuration file. If ogre.cfg put everything it actually uses in a section, I'd be able to use the same file for the other configuration info, rather than just graphics. Since that's not the case, though, I've got to work out my own configuration file (thankfully the config file classes in OGRE are really nice to use) and do the configuration by hand. Not that big a deal, but it's time-consuming.

Anyway, the launcher features a Setup dialog (a CPropertySheet with a bunch of CPropertyPages for each logical grouping) and I've got OGRE render systems and FMOD output drivers (for DSound) showing up in comboboxes. I need to set the selected item in the boxes, still, and add further controls for configuration.

If anyone asks nicely, I might share.

coldacid

coldacid

 

Hey! I got something done! (X-Posted to personal j

ISX DSetup DLL is an extension for Inno Setup that makes checking DirectX versions and updating DirectX incredibly easy. The extension comes with sample scripts demonstrating how to use ISXDX (as it is abbreviated) and only requires that the setup author has access to the DirectX SDK to use.

coldacid

coldacid

 

Adventures Through Linux-Land (or, Single Build Sy

As I wait for my Ubuntu CDs to arrive in the mail, I've been piecemealing updates to the old and out-of-date Mandrake 9 distro I have on my computer. Every week I grab packages that I use (or want to use), bring them home, and build and install them.

I'm starting to wonder if I should even bother with Ubuntu when it arrives. I feel that I might be better off going the LFS way right now. The lazy bastard in me says to simply wait.

The thing is, Mandrake 9 can't deal with my computer too well. Apparently my CD-RW is a plain CD-ROM drive, and it refuses to let me use USB devices such as my memstick. For these reasons, Windows is still my primary operating system. (Honestly, though, until I find an IDE as good as Visual Studio's IDE, Windows probably will remain primary, anyway.) But I would like to use Linux more and more.

Right now, the build process for Meldstar's project Asylum is half Visual Studio and half gmake. I'm working on making it all done from make, though, in a way that allows me to use VC++ for compiling on Windows and GCC elsewhere. Until autoconf and automake play nice with native Windows (rather than Cygwin or MinGW) it will involve a bunch of hacks (mainly batch files to call vcvars32.bat and then run msbuild on the project or solution files) that make will rely on.

Single build systems are really the way to go; using the same procedure to build on any platform makes project and build management much easier as there are no conflicting build systems to keep in sync. That allows the project manager to keep to the task at hand - developing the project itself, and not its build procedures.

coldacid

coldacid

 

Further on mark 2

Well, I've integrated OIS into the prototype, but it doesn't seem to be working. I'm going to take out the OIS code (temporarily) and restore OGRE's built-in input system in the meantime, so that I can continue working on the rest of the prototype (which requires some input to move to).

I've not yet stuck in Gangsta Wrapper as there's still no use for physics. In fact, it might not even make it into this prototype.

I don't know when I'll get around to this, since the semester is about to end (read: exams and crap) and I hope to use the winter break to unwind from a lot of stressful issues. Maybe I'll do a bit of coding over the break, and maybe I'll let it wait until January.

coldacid

coldacid

 

More work on Asylum...

After a long time of wanking and coding mere subsystems to tinker with, I'm finally (only 7 months late) starting work on the second architectural prototype for Asylum. Chances are this one might just form the core of the Asylum game engine. (Speaking of work on Asylum, Meldstar Entertainment is still looking for people to fill certain roles, especially in regards to art.)

I started this prototype by gluing together all the new systems (console, multi-platform entry point, etc.) and then adding in the successful parts (read: application FSM) of the first prototype piecemeal. I'm still working on this bit, as some of the app states need to be modified to properly work with the new systems.

Asylum is still using OGRE for graphics, and Crazy Eddie's GUI for user interface. New middleware includes Gangsta Wrapper for physics, and Open Input System for input (neither of which are used in prototype two yet).

Apart from Asylum, I'm already starting to contemplate following up September's GDNet Toronto Mini-Conference. It would probably be again in late summer (either late August or early September) although the location might change as I'll have graduated from GBC by then. The reason I'm thinking about it already this early is because of a convention I attended this weekend that was, unfortunately, an unmitigated disaster on the level of the Hindenburg (at least, as far as anime cons go). After I get to talk to Julian Spillane again (if you're reading this, Julian, e-mail me) perhaps some details might coalesce.

coldacid

coldacid

 

Further work on SDLRPG

I've redesigned the editor. It's now two different projects, the editor itself and a set of classes for game objects in another assembly. Also, I've switched to using user controls for the tile picker and map editor. Not all the functionality of the original editor is in yet, but it's only a matter of time. Right now, though, I'm focusing on getting autotiles into the class library and the tile picker.

Now here comes the tricky part. I want an unmanaged DLL to handle the actual object classes. That means taking the C# code in the class library assembly and flushing it all out (excepting what the editor needs that the game engine itself doesn't). I'm going to have to look up on unsafe code, PInvoke, and such other .Net voodoo. Anyone know of good resources, articles, etc. on this?

coldacid

coldacid

 

SDLRPG, also known as RPG Designer!

Not much has been happening lately on the Meldstar front, on account of nobody taking the time to read Asylum's design doc and sign off on it. (Team buy-in is important.) In the meantime, I've been surviving all-nighters between school and an interesting little project.

I've started work on a project I call SDLRPG. It's meant to be a competitor (I don't think clone is the right word for it) of RPG Maker XP, including such features as same resource formats and Ruby scripting, but cross-platform, with support for plugins (insert combat system here) and the like.

So far, the game engine itself isn't anything to look at (loads FMOD, SDL, and Ruby) but the game editor is another matter. Rob Loach might be happy to hear that the editor makes use of SdlDotNet for the graphics.

Right now, the whole thing is in two projects, the Editor and the Engine. I'm planning to separate some of the classes in the Editor that could be of use in the engine (or other projects looking to take advantage of SDLRPG) and rewrite them in C++. (I'd create a .Net assembly to call on the resulting library, much as SdlDotNet sits upon SDL).

I started writing the engine in C++ and it'll remain that way since I'm used to C++ and SDL, and it's far more portable than C# is. (Mono withstanding, but not everyone has that.) The editor may not be portable as it is, but being written in C# and designed with Visual Studio allows me to do some nice rapid application design (the entire editor, as it is, was only started on Monday night), and while it will be rewritten in the future, possibly the very near future, I'm planning to keep it .Netted.

Beyond SdlDotNet, the editor uses the Scintilla text edit control via the creatively named ScintillaNET wrapper, to provide the script editor. Also, the menu bar and toolbar are done using Lutz Roeder's CommandBar assembly. (If you do lots of .Net programming, and haven't heard of this guy, make your way there now. Useful goodies.)

I won't be doing much coding this weekend, but chances are I'll be redoing the editor much as I described (and this time, take advantage of user controls; damn layout is convoluted as all hell, and inefficient to boot). Then I'll probably do some work on the engine so it can play with whatever data I can get the editor to create.

coldacid

coldacid

 

In case you need to deal with environment variables

EnvironmentVariableMap.h

[source lang="cpp"]
#ifndef EnvironmentVariableMap_h___
#define EnvironmentVariableMap_h___

#include
#include

class EnvironmentVariableMap; // forward declaration

class EnvironmentVariable
{
friend class EnvironmentVariableMap;
std::string m_key;
EnvironmentVariable (const std::string key = "") : m_key(key) { }
public:
EnvironmentVariable& operator= (std::string& value);
operator std::string() const;

};
bool operator== (EnvironmentVariable& lhs, std::string& rhs);
bool operator== (std::string& lhs, EnvironmentVariable& rhs);

class EnvironmentVariableMap
{
private:
EnvironmentVariableMap() { }
static EnvironmentVariableMap* sm_this;
public:
static EnvironmentVariableMap& getSingleton();
static EnvironmentVariableMap* getSingletonPtr() { return sm_this; }
std::string get(const std::string& key);
void set(const std::string& key, const std::string& value);
EnvironmentVariable& operator[] (const std::string& key);
};

#endif // EnvironmentVariableMap_h___
[/source]

EnvironmentVariableMap.cpp

[source lang="cpp"]
#include
#include "EnvironmentVariableMap.h"

#if defined(__WIN32__) || defined(_WIN32)
# define putenv _putenv
#endif

using namespace std;

EnvironmentVariableMap* EnvironmentVariableMap::sm_this = 0;

EnvironmentVariableMap& EnvironmentVariableMap::getSingleton ()
{
if (0 == sm_this)
sm_this = new EnvironmentVariableMap();

return *sm_this;
}

string EnvironmentVariableMap::get(const string &key)
{
return string(getenv(key.c_str()));
}

void EnvironmentVariableMap::set(const string &key, const string &value)
{
string setline(key);
setline += "=";
setline += value;

putenv(setline.c_str());
}

EnvironmentVariable& EnvironmentVariableMap::operator[] (const string& key)
{
EnvironmentVariable* tmp = new EnvironmentVariable(key);
return *tmp;
}

EnvironmentVariable& EnvironmentVariable::operator= (string &value)
{
EnvironmentVariableMap::getSingleton().set(m_key, value);
return *this;
}

EnvironmentVariable::operator string () const
{
return EnvironmentVariableMap::getSingleton().get(this->m_key);
}

bool operator== (EnvironmentVariable &lhs, string &rhs)
{
return string(lhs) == rhs;
}

bool operator== (string &lhs, EnvironmentVariable &rhs)
{
return lhs == string(rhs);
}
[/source]

This code can possibly be improved by adding a cache for environment variables, but then any environment changes need to be made through the class. Use of EnvironmentVariableMap is easy. But it doesn't like C-style strings, since I never bothered to deal with them. You can add that, too, if you want

coldacid

coldacid

 

Stupid wxWidgets.

No matter what, I can't ever seem to get wxWidgets to build under VC7.1. It would really be nice if the Win32 download included binaries, rather than forcing me to build it myself. I want to use the toolkit for my open-source take on OneNote, rather than using Qt (although the latter is becoming more and more of an option).

coldacid

coldacid

 

Console variables and commands

Looks like my cvar and command code is nice and good. Console commands are no longer the bulky class they originally were; Now, they are simple functors, taking a vector of string. I'm using a simple templated Functor struct, from which command functors and cvar observers functors are typedefed.


template class T> struct Functor
{
virtual void operator() (T* t) = 0;
};

typedef Functor CmdFunctor;
typedef Functor CvarFunctor;



My cvar class itself isn't the shining use of OO design that commands are. In fact, they're still quite a throwback to procedural programming like Quake's cvars. However, Quake's cvars are of proven design. Each cvar object maintains its value type, its value, and its observers. I don't keep a global list of observers because it's unlikely that any given observer will want to know every single cvar change -- it's much more likely that an observer will only watch a single cvar and nothing else.

My cvars have their type set at construction time, and after that moment, will never change type. However, assignment and conversion operators are defined so that values can be set as any type and converted dynamically. I'm using boost::lexical_cast to do the conversions, so any code that tries to set (or sometimes get) a cvar value will need to catch either std::bad_cast or boost::bad_lexical_cast.

I'm using std::foreach and another functor to call each observer when a cvar value is changed. When a cvar is successfully changed, the setters call a simple function which ensures that each observer is notified of the change.


template class T, class C> class Call
{
C* res;
public:
Call (C* c = null) : res(c) { }
void operator() (T* x) { (*x)(res); }
};

class cvar
{
typedef std::list Watchlist;
inline void CallWatchers ()
{
Call call(&this);
for_each(observers.begin(), observers.end(), call);
};
};



I also have a function for my console class which takes a command line and breaks it into a vector of string. It formerly broke the line into an array of char* (much like the argv parameter to main()) but I figured that it'd be better (and less of a hassle for memory management) going the STL route. This member function will be public (and static) so it can break down lpCmdLine in the WinMain function.

coldacid

coldacid

 

Flash for UI greatness!

I have it on good authority that not only will attempting to use SDL to do 2D graphics over top of OGRE will not work, but even if it did would be incredibly sloppy and slow.

Rather, now I'm thinking about doing the user interface with Flash, and using GameSWF and another person's plugin to render to a texture that I can then manipulate to fit in with my ideas for the interface. I'm also thinking that a binder might do better than just a clipboard, and have the pages wave as they turn between different UI panels.

I'd rather hand-manipulate the textures for the console text, but if GameSWF's ActionScript support improves and the game's window size reported I should be able to adjust things so that text stays at the same size in pixels regardless (so higher resolutions can show more text).

I'm reworking my console idea. Rather than have full classes to be registered for cvars, the cvar list will simply be managed by the the console class, and handlers, if wanted, can be provided as a function pointer or a functor. Similarily, commands will be registered as functors, and have either argc/argv or a list of strings.

coldacid

coldacid

 

SDL & OGRE == !CEGUI ???

I've decided that for Asylum, we'll be using SDL to manage input. The interesting thing about this decision is the Win32 hack needed to make SDL and OGRE play nice. What's got me curious, however, is if it's possible to use SDL for doing 2D graphics as an overlay above OGRE's renderings. If so, then I can avoid using CEGUI for the user interface.

As for that user interface, I'm thinking that going with a clipboard, one of those old medical chart ones, as a motif. Or maybe a flip-open (wire-ring) notebook. Have the different UI panels on pages, maybe even have the UI animated to flip through them!

Prototype 2 is taking a lot slower than I had anticipated. I want to get it working before going onto actual development. Some of what I want to do is pretty easy (adding the single-instance mutex, rudimentary input in-game), but getting the OGRE configuration files eliminated, and allowing resource overrides, and filesystem related work will be painful. It'd be awesome if OGRE actually had a nice VFS system; doing my own and integrating it with the resource system that OGRE uses isn't going to be much fun.

Another thing I've done while working on prototype 2 is an automated system for building, preparing an installer, and making a CD image. It's incomplete, but I'm hoping to get it all working nicely soon. Then I'll move it to Perl, makefile, or shell script (it's a set of batch files that call each other right now).

coldacid

coldacid

 

The Incredible, Edible Console!

I'm trying something interesting with the console for the second Asylum prototype. It's being designed so that cvars and commands can be added (or removed) in code. Not only that, but cvars can be observed for changes.

I'm using a Cvar base class which contains the code for managing a bag of observers (CvarHandler objects) and provides an interface to the console for getting and setting the value. A std::map is used by the console to map Cvar objects to their names. Values are provided as strings, and boost::lexical_cast can be used to convert to the actual data type (and at the same time verify that the user input is good).

It's similar for Commands. A Command base class provides the interface that actual command objects must provide, but there's no listeners. Again, strings are used for input (this time, a vector of them) and actual determination of input is done by the Command object itself. Another std::map in the console keeps Commands.

When the user gives input to the console, the console first checks if the first token in the input string matches a command name. If not, it'll check for a cvar name, and if that also fails, tells the user that he's an idiot. But because of the possibility of a cvar and a command having the same name, the console provides two special commands, get and set, for ensuring that cvars can be accessed and mutated. (There are two other special commands, listvars and listcmds, for providing the names and descriptions (and for cvars, values) of registered cvars and commands.)

So far I've not been having problems working with this system, but so far I've only built it. I need to write a driver and unit tests to ensure that it works as planned.

coldacid

coldacid

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!