We began working on a game a couple days ago. First by designing and discussing exactly what we wanted. The whole idea basically started when I had called John, my fellow author on this blog who is more graphics oriented, and telling him that I was planning on taking a vacation during the week recess I have from classes. During that time, I suggested we pool our passions and build a game from start to finish. The game is very simple: a 2D Zelda-Like top down view with our own steampunk feel to the game. It is very cliché in the sense that the you are on an island with 7 dungeons, you must beat them all to defeat the final boss. Now, as "serious" as the game sounds, there are elements of our humor everywhere in the game. We have really enjoyed discussing it, and would definitely add as many elements as possible. We intentionally went this route because we only have a week to do it.
Why only a week, you ask? I found out that my director is resigning where I work. I'm very saddened by this, but I of all people should know that when something new and challenging comes across our intellectual careers, we have to take it for the sake of our own sanity. I couldn't be happier for his success, and I wish him all the best.
The problem is this: his last day is my last day of scheduled vacation. I had mentioned to him that I would be building a game on that time. The new challenge is to get something playable that I can bring in on his last day. Challenge accepted.
Without further ado, I'll begin talking about our game and our progress through the steps we have taken.
On the first night, we bought a white board which has proved to be invaluable in our quest to decide on what we want. Disclaimer: Not the greatest quality picture.
This was essentially tallying up the basic components we needed. Since this is a simple game, we have a dungeon, items, enemies, and the player. Pretty standard high level concept. The rest of the illegible scribbling on the board was our attempt at the design of the enemy system. We already have a basic idea of what we want for the Entities in the game. Enemy will inherit from Entity. Entity contains what it needs for the position, velocity, and the textures of the Entity. I wrote the Entity class in such a way that allows switching of sprite sheets. We did this because, for instance, our player will have multiple sprite sheets for different equipment. We decided to put the toll on additional graphics rather than the logic of transcribing equipment onto the player.
We realized later that this is probably too much functionality for an Entity. Nonetheless we're rolling with it until something goes horribly wrong.
Back to the enemies. We wanted to create enemies in such a way that did not require a plethora of sub classes for each type of enemy. This would get gross and we'd end up copying and pasting a lot of code. To that end we decided we would have an interface for "AIComponent". This is the primary functionality of Enemy.
Enemy allows 3 different types of AIComponents, but they are all bound together by the same interface. We have a Idle component, a Decision component, and Action Components.
We were contemplating using decision trees, but I don't have any practical experience with the concepts and in the interest of time, I think what we came up with will work just fine. It is certainly not ideal as we have a very tight coupling between components and Enemy. We do not need AI for other areas though, so we'll overlook that for now.
What this allows us to do is to set a default "Idle" component. We can have any number of these such as "DoNothing" or Move randomly. Second, a Decision component can access the ActionComponents of an Enemy. This allows decisions to take place based on player position, among other factors. Such as randomly pick an attack, or if behind the player do this, etc. If the HasPlayerInSight is true, then the decision component is called through a delegate, otherwise, the idle component is run. This is again a design choice for simplicity. This method works well, and allows us to reuse simple components such as Move and Jump for any enemy, while providing more complex AI for bosses or special enemies. Finally, not all actions will take the same time. So the Enemy class provides a callback method to end the action, and allow another to be chosen.
I'll stop here for now, even though I have much more to share! I hope this blog becomes useful to others in their path, as much as it helps me.
Happy Coding!
No comments:
Post a Comment