First Look

Today, I am going to show a very, very primitive first look at what we're building. You won't be impressed, but the soft, creamy underbelly of what we're building is coming to fruition. In the brief demo, we're showing a basic inventory collection and use, player damage based on its current shield (Formula is still under consideration), the three dancing knights are AI driven and read from a file including all of its AI components, and the player movement has a sophisticated input system. 

As I said, this is far from impressive. The framework is nearly complete though, and we're very excited for what we've come up with.

Our next task is the map system, which I should have a demonstration of tomorrow. Currently we want to allow for switches both based on a floor switch or an area of effect, swapping of tiles for effects such as freezing water or cooling lava, collision of walls and other objects, etc. We're currently still working on this. John has something to show, but the next thing is to get it related to the rest of our framework.

We're excited at our progress, and we hope to have the Map system done tonight with a fully realized system.

Now for the technical side. We've played with some ideas using Enum bit flags which has a solid approach. Since we'll be handling collision in such a way that if you pass an x and y and it will return the tile at that location. We'd also be providing a method that returns a set of tiles within a given radius for area of effect collisions. We have a weapon that uses this extensively and quickly became a multipurpose weapon for use. I won't reveal the weapon yet, but we're excited even though it's one of the more complicated logic pieces.

Currently, the first tile system made the Tile class itself fairly complicated, and we were creating sub classes for every type of tile because we couldn't quite figure out how to encompass the large range of tiles we needed in one generic manner. So we created an enum for EventType, and made it an abstract class to allow  us to create very specific functionality to the tile such as the freezing, or a switch that activates a door (A switch is considered a tile). I was able to create this functionality using the bit flags for enums, so we'll see how we manage to incorporate it.

For now, we'll be hard at work! Happy coding!

Perpetual Beginning

Hello everyone! This blog is meant to be a gateway into the thoughts of couple game development enthusiasts. Our passion is what motivates us to keep coming up with ideas, but we never truly finished any one project. We know how it can become discouraging and challenging, but in the wake of challenge we have learned to pursue our passions anyway. Where we were years ago and where we are now has no real comparison. Thus, we want to share our progress, we want to note how the techniques we use evolve and how we use them to better ourselves in our journey. We've struggled with finishing our projects in the past, and I doubt we are the only ones. For those who struggle with keeping up in the face of failure, we're here to let you know that we've failed numerous times, and will continue to fail until we are successful.

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!