Woo
702
1
Advertisement
Random Game
Operation Tiger
Apparently, this game was issued by the Australian military in an attempt to get people to sign up.
Other
One thing I just remembered I was working on before I took a hiatus for Game Programming was the XML Action/Event-based 'scripting' system I was planning. I think this should be high on the 'play' list of things to work on, alongside my generic entity class. The concept is actually pretty simple; in your game you define a number of 'Actions' which can be performed by an Entity. Think of a door which can 'Open', 'Close', 'Lock' and 'Unlock'; you'd provide an implementation of these methods and assign them to the Entity 'class' within the system. An Entity will also have a set of public or private attributes which contain 'descriptive' data about itself.
At the same time, you'd also give an Entity a set of events; 'OnOpened', 'OnClosed', 'OnLocked' or 'OnUnlocked' in the example of the door. When it comes to scripting these entities, there should, in theory, be no 'coding' to do. Imagine an editor that will list these events; you will click on the 'OnOpened' event for a given instance of a door Entity and then set about dragging and dropping your atomic actions into the pane. Think of simple command-based scripting combined with an Event handling mechanism. When a given door Entity is 'Opened', the 'OnOpened' event will be called and will evoke each of the listed actions (some actions should be conditional).
Such a system should, in theory, be completely programmable through a GUI by a game designer without the need to learn a scripting langauge. The system should also be representable in metadata, meaning the entity scripting can be saved and stored in an XML file.
Other
Does anyone else work on several things at once? Or do you just go with the one thing? My 'problem' (as it were) is that when I'm working on a game, I will also work with some theoretical components at the same time (like the system above, or like my generic entity class). The problem usually results in me dying to try out the new components in a real-life game test, so I'll rip out my old 'functional' code and implement my new system. That's one problem I have with C++, I always get interested in the many way you can skin a cat, rather than say Blitz Basic where you just did what you needed to to get by.
UPDATE!
Just heard back from girlfriend - apparently my snake has escaped and it's heading for the rat cage. Haha.
UPDATE #2
Rats were unharmed, the snake's only 2 feet long so couldn't hurt them if he'd wanted. I got a 'new' camera as a present too =)
Operation Tiger
Apparently, this game was issued by the Australian military in an attempt to get people to sign up.
Other
One thing I just remembered I was working on before I took a hiatus for Game Programming was the XML Action/Event-based 'scripting' system I was planning. I think this should be high on the 'play' list of things to work on, alongside my generic entity class. The concept is actually pretty simple; in your game you define a number of 'Actions' which can be performed by an Entity. Think of a door which can 'Open', 'Close', 'Lock' and 'Unlock'; you'd provide an implementation of these methods and assign them to the Entity 'class' within the system. An Entity will also have a set of public or private attributes which contain 'descriptive' data about itself.
At the same time, you'd also give an Entity a set of events; 'OnOpened', 'OnClosed', 'OnLocked' or 'OnUnlocked' in the example of the door. When it comes to scripting these entities, there should, in theory, be no 'coding' to do. Imagine an editor that will list these events; you will click on the 'OnOpened' event for a given instance of a door Entity and then set about dragging and dropping your atomic actions into the pane. Think of simple command-based scripting combined with an Event handling mechanism. When a given door Entity is 'Opened', the 'OnOpened' event will be called and will evoke each of the listed actions (some actions should be conditional).
Such a system should, in theory, be completely programmable through a GUI by a game designer without the need to learn a scripting langauge. The system should also be representable in metadata, meaning the entity scripting can be saved and stored in an XML file.
Other
Does anyone else work on several things at once? Or do you just go with the one thing? My 'problem' (as it were) is that when I'm working on a game, I will also work with some theoretical components at the same time (like the system above, or like my generic entity class). The problem usually results in me dying to try out the new components in a real-life game test, so I'll rip out my old 'functional' code and implement my new system. That's one problem I have with C++, I always get interested in the many way you can skin a cat, rather than say Blitz Basic where you just did what you needed to to get by.
UPDATE!
Just heard back from girlfriend - apparently my snake has escaped and it's heading for the rat cage. Haha.
UPDATE #2
Rats were unharmed, the snake's only 2 feet long so couldn't hurt them if he'd wanted. I got a 'new' camera as a present too =)
Advertisement
Advertisement
Advertisement
Discussion