Siva: Hell, it's about time.

Finally got time to get started working on the projects. End of term, summer kicked in and had zero time for any hobbies. New house, new job, new courses, yet still the same projects. Ive hatched some ideas for this next fall term and time to kick things into production.

Learning some new essential skills, mainly DBs. Will be an asset to any type of venture with a requirement for large amounts of data.

Looking into SC2 engine, seeing as to what it can do.

Will update soon,
Siva

Kinda like Duke Nukem

Now after a month of life getting in the way, I'm back to working Naos!

short post talking about a few big changes.

First, I'm doing away with the old system of application, logic and control.
Its just going to be Control and Logic, with application features filed into control.

Secondly, I've decided to simply use delegates instead of the old message passing system that would have incurred a great deal of overhead.

Third, the control system may have configurable controls, made possible but the use of Reflection. Hopefully I can learn reflection in time to implement it. Can't think of another way to have configurable controls. Basically what will happen is that there will be delegates that to be created at run time, not compile time. Therefore, the appropriate method must be selected given a selected control set up.

New Project Site

Hey guys!

I have just launched a Google Site for keeping Track of the next game project, now named Project Naos. The project naos website is at https://sites.google.com/site/projectnaos/, head there to take a gander at what will be the bulk of the documentation for the project. I will of course continue to update Proshe with my meanderings about the game, but official documentation goes on that site.

On to work news, Siva was in the area this weekend so we decided to get together for a meeting to discuss the work thus far done and plan out what to do next. Also present at the meeting was Calvin, who will be intermittently helping out with the game. The results of our meeting will be up in the next post.

Another bit of news for the future. Swapan will be joining the Team after the completion of Naos. Our plans after Naos may be to move away from developing PC games and develop either for the XBOX or for IPhone. That decision will be determine in the time between now and the completion of Naos. We will continuously brainstorm ideas during this period, ideas for both platforms, and whichever idea stands out as the best, will decide what platform we work on. Another factor in the switch to IPhone is that we would have to learn Objective C in order to code for the IPhone, whereas we are all already fairly comfortable in c#.

Think fast! *Splash*

Graphics

The graphics handler on the player would run at a preset frequency. It does not care about how fast the game itself actually runs, it will run as fast as we set the frame rate. After a period of waiting, the graphics thread would send a request to the logic game world to give it a snapshot the current game world. The event handler of the logic thread would see this request, and would do a callback on the graphics thread using AddGameWorld() and AddPauseMenu() if required to pass the snapshot.

Another idea to implement is to make every state of the game its own game. When the “gameplay” game ends, a “Title” or “high score” game begins. A global variable inside the main loop of the game could be used to keep track of the current game that’s going on. The graphics thread would simply call the current game, and ask for a snapshot of what to output. The snapshot passes lists of items that need to be outputted, and the graphics thread simply cycles through the lists drawing every relevant object.

Yay, after 4 posts of blogging, the random global variable count is solidly at 1, as opposed to the bajillion in Tetris.

Now for another interesting idea I had. Instead of having a plain old background for the title game, we could have the map levels showing behind the title menu. But then that got me thinking, if we could have the level BG running anyway, why not just through the entire game in there, with an AI playing. I don’t remember if I talked about this or not, but I also had the idea of having mini bosses that spawn super randomly. And these guys would actually put up a fight, using smart movements and ninja like evasion of your shots. This would imply that your shots are evadable though, so this is where I plan to deviate from Raiden. The shooting in Raiden would require much more finesse and not just holding down the button. I want it to be like the AC130 from Modern warfare 2, if anybody’s played that.

So with this kind of system set up, another challenge arises, we have a lot of AI that needs to be written. At the very least, we need 4 classes of AI, Player-AI, Miniboss-Ai, Regular Scrub –Ai, and Boss Ai. If this is done right though, imagine how awesome it’d be. We could just sit back, and watch our AI fight each other. Crap, the Player-AI needs to be seriously intense, using collision detection projection and also objectives.

With all that talk about player-AI, we need to make a class that can accommodate it. When a user is created inside a player class, it will need to be handed an object distinguishing it as a player or an AI. If it’s an Ai, it will initialize an AI object and begin taking commands from that. If it’s a player, then it will begin reading player input.

Things to do for the future

-Design AI structure
-Figure out things like how enemies would spawn and fly in formation etc.

Get in line buddy!

HEY GUYS

So, story time! I was on the bus home yesterday after hanging out with a few friends. And it was a loooong ass bus ride. So my first thought was to whip out my notebook and start working. After 30 minutes of that, and at the point where my wrist was sore, I had an epiphany, I was a workaholic. I spent 6 hours a day sleeping, the other 18 hours are spent between my full time job, and writing notes for the game. My whole life had been going from one phase of slacking to another. And for the first time in my life, I found enjoyment and maybe even addiction to work. Getting into game making was definitely a great choice. Life is good.

And now on to the real reason you’re here. Today’s post is going to be a doozey; it’s going to hit a bunch of areas. Let’s start with how I’m going to implement the event handlers.

My plan for the event handler system is to have each class of event have its own handler. There’d be a collision detection handler, movement handler, etc. Each of these handlers would need to inherit from an interface class. If for nothing but for me to practice using interfaces lol. Inside each event handler, will be a queue item. There would be an add event method that would be public and could be called by other actors. Each handler will also have a transfer event method. The event handler inside the main logic thread will act as a hub and all other event handlers are simply nodes accessed by the hub. There may be further transfers depending on if some event causes chain reactions or something. There will also be use of delegates in event calling. For things like collisions where logic, graphics, and audio all need to be called.

In the game architecture where there is a huge separation between the various actors, I cannot implement a central event handling center, which could just be a single thread. Splitting it into multiple threads that run all the event handlers for each actor, is way too resource consuming. So instead of having individually threaded event handlers, the event handlers would get the illusion of threading. In each cycle of the outer thread that they’re all running in, I would allow each of them to run for a certain number of inner cycles, depending on importance. For example, I would let the collision detection handler run maybe 10 times and take 10 items off the queue, but I would run the player input handler 20 times. I want a much more emphasis on responding to player actions than the collisions. Missing a collision here and there is fine in a game like this, but missing fine adjustments by the player due to bad threading is not acceptable.

Objects get a timestamp of the time that they’re added into a queue. The top entry in the queues should be checked by the event hander that takes items off the queue before handling it, it is discarded and moves onto the next item if the top item is say older than 1 second. If it’s older than 1 second, clearly something has gone wrong and that event is now irrelevant.

There are also the events handlers that only run at specified times. Mainly, the pause menu event handler. When a pause menu is called, the thread that calls it passes control of the player input queue to the new handler. I was originally going to say, that the queue should be cleared out once the new handler is called, so it only processes new commands, but any commands sent by the player after he hits the pause menu button is clearly in anticipation of that menu being there. The player input queue isn’t going to get nearly as many events as the other handlers anyway so meh. The queue system isn’t even necessary in this case.

Raiden AI and More

Before Raiden AI, I'd just like to point out the great job Xin did with the architecture designing and brainstorming a breadth of concepts we have to touch. I in the meantime was out of commission by the flu... -.-

Back to Raiden:

So, what is AI?

A field I've always been deeply intrigued by, the best definition i can come up with is that its the game developers method of making a game fun.

My reasoning is that the games i have the most fun with are very detailed in almost every aspect of their gameplay. As in, they are not button smashers. At the same time, the game can be difficult to the point that you lose interest in it. The biggest example i can think of is "I wana to be the guy". One of the most frustrating games i have ever attempted. Another one that is similar to Raiden is touhou. This game is a Japanese version of the game, and is more about learning a sequence of steps and maneuvers to win rather than split second timing. I find this game to be more similar to DDR, RockBand, and that type of franchise than Raiden arcade style gaming. Again, not what we are going for.

Easy <-------------------------------------------------------------------> Super Hard

Pacman .....................................................................................I wanna be the guy

Where is Raiden?

I think there shall be some testing to be done on the exact point at which motivation shall beat the frustration and urge the player onwards. Most of the great games have this feeling of difficultly, perseverance, and reward that is built flawlessly into the experience. Remember the feeling when you beat that final boss? What made that boss difficult? Probably the AI. Keep in mind though, the boss was eventually defeated, thus it should be known that the process you took to finishing it was allowed by a game designer. Now thats some serious forethought! (or game exploiting, but we are not a hacker forum)

Recognizing that AI is more than just how to code an enemy to attack at you, is crucial in producing an enjoyable game.

What is AI in coding?

Making an enemy attack you.

Yes. That's about it. In Raiden, this isn't too hard. Couple Cases:

If enemy has a weapon that can be orientated at angles, calculate vector to hero, fire.

If enemy is independent of a set path (free flying),then maneuver in ways that would cause additional difficulty for the hero

If homing missile, home.

etc.

What is the real fun AI?

Level editing! Creating preset formations or attack patterns that would require the user to think and make split second decisions to succeed. I would like to re-iterate: not making touhou. The game should still be able to be completed by someone playing close attention and having a quick finger. Making the game completely random would rather be dull or impossible. A mix seems to be the best idea.

What else can we do?

Adapting levels. A common strategy in Raiden is to get a weapon (and following upgrades) that result in a certain type of gameplay. For example, theres the spray type weapon, which shoots wide angle weak projectiles. There is also the single channel laser, which has devastating power but limited map coverage. Plus, different ships have different weight to speed ratios well. Thus, when the games adjust their gameplay to meet these ends, as developers, we can throw in tricks that would require them not to get too eased in. Varying the enemies, or changing enemy styles as the level proceeds would cause the user to think, vary up their weapon choice, and be super vigilant. This is at a higher level than us currently; however, it's always good to plan and think ahead in this field.

So whats the wrap?

AI is a term more about how intelligent the developers are than the enemy on the screen is.

AI is good. :)

Couple links to mentioned stuff in body:

I wana be the guy: http://kayin.pyoko.org/iwbtg/

touhou: http://en.wikipedia.org/wiki/Touhou_Project

Raiden X: http://www.freeworldgroup.com/games4/gameindex/raiden.htm

Engineering this Mofo

In my last post, I talked about the type of architecture I wanted to approach the game with. Next up is to explain how exactly I am going to implement parts of it. Again, most of these concepts are ones I took from Game Programming Complete, 3^rd edition. I really recommend all beginners to buy this book. Though my lack of C++ has stopped me from benefiting from the provided source code, the extensive explanations and excellent presentation has really taught me a lot, and the concepts not thoroughly explained, are have explanations abound on the internet.

Threading

As you’ve probably noticed in the previous post, I am putting a heavy emphasis on distinct separation between components of the game. In Tetris, I followed the default methods set out for me by XNA upon creating a project. Throw all your updating in one method, all your drawing in another etc. While this was a very easy concept to grasp conceptually, it was horrible from a code perspective. It became hard to track the progress of the code as the game runs.

It’s much simpler to divide up the game into different Objects. All that would be required to track the progress of the game would be to watch the state of specific objects as the game runs. I decided to think of all these objects as a game within your game. They will all run independently and communicate with each when required. If any of the other objects decided that they didn’t want to play anymore and just sat there, all the other objects could go about their merry way. Though they might require communication between that non-responsive object, they will still function nonetheless.

Another feature of threading that I found immediately useful while reading up on it is the ability to freeze a thread while it calls another thread and waits for it to finish. I immediately thought back to how overcomplicated my pause menu system was in Tetris. A simple thread to interrupt the main game code would have sufficed.

To summarize, threading allows for me to separate parts of my code for ease of access, it allows for me to really push this type of architecture and see where it can take me. And lastly, threading’s a topic I would have to deal with a t some point or another if I want to be an avid coder, might as well throw myself into the heat of it, best way to learn.

Actor System

So after all that talk about separating game and player, how do we actually go about doing it? First, I concentrated on how graphics would work in this game. Based on the previously explained architecture, it was easy to decide that the player Actor would be responsible for printing the players own character onto the screen. But then I realized, what if I wanted to put local multiplayer in the game (I definitely do). Then this becomes more complicated. The two players could draw their own players sure, but who would draw the enemies? The game background? I decided that I would make the two Users objects that belong to a higher actor class. This higher class would be responsible for managing the two users. Two would be the maximum number of players I’m going to cap it at. This type of system could extend to as many players as needed. One thing to note about XNA is that game performance is heavily dependent on how many times you call spriteBatch.Begin(). Ideally, you only want this called in one place. So it would be prudent to leave all the graphics code inside the higher actor class, rather than distributing it out amongst the players. All players will receive exactly the same view and audio regardless of its implemented anyway, since this is a single screen local multiplayer.

Another dilemma was whether to put the viewport properties inside the Actor class, or to put it in the Game logic. On one hand, it’s readily obvious that the viewport directly affects what an actor see, so obviously it belongs to an actor individually. But on the other hand, perhaps more important hand, the viewport is actual a critical part of the gameplay design. When I say viewport, I mean the section of the map that is currently accessible to players and what is displayed on the screen. While it is true that the viewport is the basis for which the graphics processes depend, the viewport is also independent of the player. It moves through the level at a constant pace, in fact the viewport affects what the player can and cannot do. It is more of a gameplay mechanic than a graphics property.

Another thing that the viewport dilemma brought to my attention would be whether or not I want to allow multiple resolutions of my game as an option to the player. Though I may choose not to implement such a feature, it would be prudent to keep the viewport data in such a way that different players playing on network multiplayer can each view the same game on different resolutions. While this is also definitely not going to be implemented in the game, it never hurts to think about best practice when coding.

Messaging system

Since the game is designed to keep the Actors separate, the Actors must have a way to communicate, to this end, I decided to use event driven programming. In this way, actors only communicate with other actors when they decide that there is an event of significance that the recipient should know about. Such events in this game might be that the user pressed a movement key. The player actor is the one who detects that this has occurred, through polling of the keyboard state. Once this event has been detected, a message object is created, containing details of the event and perhaps what actions might be taken. A method from the recipient actor takes this object in as a parameter and adds it to an appropriate queue in the recipient object. This is set up for a central event handler in the recipient object. The event handler thread will process the event queue as the events line up and decide where to send this message object so that it can be dealt with.

The use of a queue is important because of the heavy use of threading in this game. The threads will not all run at the same time, so consequently the event handler in the central object may not be able to run fast enough to handle all the incoming event real-time. As a failsafe, if the queue really starts growing, a second event handler thread could be created whose entire purpose is to fast track through the queue to enable the event handler to catch up to the point where gametime matches real time.