I just received the following email -

Quote:

night embarrass corner off she out? carefully am nothing similar. across a yours. evening goes steps mentioned, purpose taught anybody yours social rich? benefit black immediate prison thats how, reference raise next. a across somewhere companion steps carefully, arms least embarrass wife friends,

Seriously. Wtf?

I’m convinced its some kind of code. Or just random spam mail. Whoo whoo.

5 comments

• Random Observation of the Day!
  Being sick + Being hungover == baaddd

Apparently I went through a bottle of wine and another half bottle of champagne last night. It was really fun, but this morning (well, basically all of today) was absolute hell.

Well, duh.

2 comments

• Random Observation of the Day!
  Pickled herrings were invented in 1375.

Okay, so I’m still working (albeit slowly) on what I have tenatively dubbed “namespace mgf”, another three-letter acronym for “Mini-Game Framework”.

I’ve decided that I’m going to use some old code I wrote for a state stack to implement a stack of minigames. Essentially, this means that we’ll have a common IGame interface which derives from the StateStack::IState interface which looks something like this -

class IState {
protected:
        StateStack* m_parentStack;

public:
        bool m_static;
        bool m_active;

        virtual void init() {};
        virtual void pause() {};
        virtual bool run(double) = 0;
        virtual void resume() {};
        virtual void shutdown() {};

        void pop() {
                this->m_active = false; }

        IState() {
                this->m_active = true; }
};

And I just noticed this is a much older revision than I originally thought – there is no implementation for “hollow” states (states which are pushed onto the stack and executed, but allow the state below them to run as well), which are useful for GUI rendering.

I’ll code them in if I need to, but as we’ve offloaded all GUI-related stuff to a whole framework I think it should be fine.

Moving down the hierarchy, we have the IGame interface, which essentially adds in a couple of things – a list of pointer-to-players (if you remember, a player is essentially an attribute map) that are registered to it, and pointers to a static graphics adapter and GUI object.

Essentially the planned execution path for the completed system looks like this -

1. Main game stack manager created. Graphics/Event adapters initialized. GUI interfaces initialized. Main game state loaded (probably a menu of some sort) and program enters main loop.

2. Input from user is recieved by GUI (captured through the event adapter assigned to it) and is passed down to the Main game state (which has registered itself as a listener for button events, or whatever).
3. The main game state loads the game selected, via m_parentStack->push(..).
4. The state stack creates the new state and pushes it onto the stack. the main state’s pause(..) method is called, and it unregisters its listeners and anything else that it doesn’t need.
5. The game state runs, possibly pushing more states on the stack, etc etc, and eventually pops itself.
6. The main game state’s is re-activated and its resume(..) is called. It begins cleanup, and pops itself off the stack.
7. The state stack is now empty, and the main game loop is exited. The GUI interfaces are unloaded, and the graphics/event adapters shut down.
8. The program then BSODs the system.

So yeah. I guess the only thing really left to implement is the Game State manager, which shouldn’t be all that difficult. Then we can get down to the grub of writing mini-games

Comments are off for this post

Okay, this is a little rant about alcohol.

I enjoy alcohol. I consume a lot of it, in various forms. I guess I can be considered a social alcoholic – I drink because it loosens me up in otherwise non-existant social situations.

I swear though, I’m surrounded by lightweights. Whenever someone overdrinks (if its not me) it seems like I’m the one who takes care of them. Which is really annoying.

Myself and a two other friends were sitting around drinking and watching TV when a flatmate comes home smashed. Wow, interruption. So I end up watching him until he goes to bed to make sure he’s okay.

As the girl was leaving she mentioned to me “You can always go watch some porn.”

…

Thanks

3 comments

Okay, so I’m about 1/3 through the first bottle of wine. Its good :]

Anyway, I’ve been working on some prototypes for my generic game-system-within-a-game project. With some inspiration from other well-established systems (ie, TA) I’ve decided on a generic way to represent a player such that any given mini-game can both access and manipulate the character data.

Its by no means a new idea (in fact, I implemented something similar when I wrote my ‘generic text-based game engine’), but essentially a player is represented by an attribute map. At this point the map is a string-to-Attribute map, where Attribute is defined as

class Attribute {
    std::string id;
    float val;
};

Now, the clear-and-present problems with this -

There is no way to group attributes. Say, if you wanted to have an inventory. It wouldn’t be technically feasible to implement in this manner. One solution is to give each attribute flags, for example, something could be flagged with “FLAG_ITEM” and thus be a part of the inventory.

This isn’t what I really want to achieve at all – I want a generic way to represent a player’s attributes, but have a common interface such that its flexible enough to work between widely varying genres.

At the same time, if a given mini-game is going to look for a certain attribute (ie, “gold”) then its going to have to be pre-defined and used across all the games wanting that attribute. Which would mean that there has to be some agreeance on a common standard.

Another consideration is the target game genre – not RPG. I doubt that an inventory would be necessary, aside from a list of flags (of powerups, or quest items, or whatever).

That said, I think it is important to maintain a method to grab a set of attributes based on a common identifier. After writing this (as this is essentially a brainstorm for me) I’ve pretty much decided to add in a flags field to the Attribute class, and a method in the player class to grab a vector of all attributes displaying a certain flag.

So yeah. That’s the player system for you. The player system being, essentially, the only method of communication between mini-game “modules” (or whatever).

Time for more wine :)

Comments are off for this post