Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.






Back

Posted by Drakkcon, 03 November 2006 · 80 views

I just got back from China.

Here is a list of weird crap that I ate:

-Sea Cucumber
-Soups made from various parts of the lotus plant
-Chicken Feet
-Tripe Sausage
-Duck's tongue
-Jellyfish
-Pork Gellatin
-A whole fish (literally)

The general rule in China is to not ask what you're eating. It's dangerous.


Okay, now that I have had a huge hamburger, I want to work on another game that I probably won't finish. The game will not use XNA, even though I was really excited about it, because I would rather learn how to use Managed DirectX.

All I know is that the game will be an RPG. It will be set in a fantasy/sci-fi universe. And it will be sort of like crono trigger, except with a more tactical battle system.

I know, I know, don't use all your creativity all at once [rolleyes]

I figure it will help if I post every time I start a part of the game. Like, so I can get suggestions. I'm not sure what the ideal order for working on stuff.

I plan on creating several interfaces to simplify the parts of my engine:

-Resource
-Subsystem
-DataStore
-DataAccessor
-Game

Anything that the player hears, sees, or anything that is rather large and needs to have specific lifespans will be a resource. Graphics, sound, animations, scripts, and anything that will load from my custom resource file format is a resource.

Subsystem should be pretty obvious. It's a game system. The Game interface will have a method that allows it to add subsystems, which it will then tick as often as possible.

Datastores are what allow different subsystems to communicate with each other. I only plan on using one, but I'm not making it a singleton because it's perfectly reasonable that you might want different subsystems to share different data with each other. Basically, the data store is a collection of lists of Events. Event looks like this:


struct Event
{
public string subsystem;
public string type;
public Object data;
}


That's it.

The datastore simply adds events for certain subsystems, and it's up to the DataAccessor to search it's list for events, and then report that to the subsystem.



Anyway. I'm jetlagged, so that may be totally incoherent. If it isn't, I would realy, REALLY like to hear suggestions for, or problems with this design. Please comment!




damn, isn't sea cucumber toxic?
Maybe. I had horrible diarrhea for the next four days. Then again, that could have been the water...

Recent Entries

Recent Comments

PARTNERS