Performance

Performance is an interesting problem to solve, and one I am none too experienced with. While playing our game I've noticed a considerable hiccup, mostly when many projectiles on the screen. As a good guess, I commented the logic pertaining to projectiles, ran, and to my surprise the performance glitch still existed.

Stumped, I turned to the internet for assistance. Turns out, there's a reasonably good piece of software called SlimTune that came to my rescue. It is technically a beta, but it is open source and easy to use once you decode some of the results on your own. Not all the visual data has come to being useful just yet.

So what was the problem you ask? Well, I navigated the labyrinth of function calls and to my surprise, the problem was not what I expected.

The method call to the enemy draw was causing the problem. Not because of the textures or any complex logic, but because I was drawing a primitive rectangle around the enemy health bar to give it some emphasis. This was the lazy route and would've been solved when we used an actual image for the health bar, but it just goes to show that as useful as primitives can be, they can cause quite the backup.

We Still Exist

Hello everyone. I know we have not posted in a while. As I had eluded to, our activity will not be as frequent. Tonight, since I had some time, I decided to make a few changes to the game. Very small changes, and I will also post a video of the game since I never did that with the playable version. This post will start off technical, for those interested, and end with the playable video.

I made a couple performance changes. Nothing that would effect anything too much, and I imagine there are countless other areas that this could be applied. I wanted to point out some subtleties in the .NET language that can, without being aware of how things work underneath, cause some unintended loss of precious CPU cycles when running constantly for every game update. During event driven applications these generally don't matter much, but in the game world we have many complex computations where the CPU cycles are better spent.

The first one was the inventory. Previously, we did the logical idea in the loop by adding an if condition, and if the current inventory selection is the equipped selection, draw the selector icon behind the item image. You can see this in the video as we select items. However, we call this method on every update, and an if condition can do nefarious things to a CPU pipeline. That is, modern CPU's use a pipeline to optimize instruction execution per clock cycle. With a branch, the CPU doesn't know which instruction to execute until the branch is evaluated. I won't bore with the more technical details of instruction execution, but the inventory had a notable branch that wasn't required. Even though it wouldn't cause any serious penalties, this statement is only true once in the entire loop. This makes branch prediction somewhat useful, but the guess can be avoided entirely by doing the calculation ahead of time based on the selected index.

The next one was in the camera. We use a special algorithm for locking the map in place to the player isn't distracted by the nothingness in behind all the image drawing. That algorithm is responsible for moving the map when the player is in a specific boundary, but when the player moves to a corner, the map stops moving to a minimum of 0, 0, and a point based on the map width and height. This method made use of the player position, width, height, and its translation from the attack image (A translation of -64, -64). Originally, we used the properties in player to get the position and sprite width and height every time it was needed in the calculation. Because is is a property, this is creating a function call for every player.Position and player.CurrentSprite, and player.CurrentTranslation. That's a total of 6 function calls!

A function call requires for memory to be allocated on the stack (a memory data structure that is used as a pointer for the current executing method), all data on the CPU registers to be temporarily stored and new data allocated for the function call, and then deallocated off the stack with the return value. This is a lot of extra work, called a context switch (particularly brutal in database applications), that can be avoided. So, what I did was create local Vector2 variables for each of these, and used that. At the expense of a small amount of memory, we've reduced half the function calls. Using the X and Y values of a Vector2 is a value shift, because these are public variables rather than properties, and this invokes no additional functions.

The last one, and this currently only effects loading of the maps, is one of my previous changes to the AI component. I had mentioned that I used reflection to solve the problem of AI Components being referenced by all enemies. This was a solution, but as I looked back wasn't the ideal solution. Reflection is a lovely tool and makes most scripting needs not needed in the C# language due to its versatility. However, it can be slower and produce overhead, although not enough to be a major performance drain, is typically slower than direct access. There was another reason, once I thought of a different solution, I felt that it was a more reliable approach and fit into the AI Component paradigm in a way that I was comfortable with. Reflection added unnecessary logic to the create method which had made me a sad panda. So, in the end I added a clone method to the AI component, and I allow each individual component to clone itself and its required properties, rather than looping through all of them with reflection when they might not even need it (Looping includes branching). We add a function call, but the amount removed from using reflection and the cost of indirect access should be better since the components can have various functionality. This would also allow enemy spawns to be more efficient, should we ever include them.

I apologize to those who aren't here for the technical dribble, but this is part of our passion, and I know many struggle as I did. It took many years of dedication to have the understanding that I do, and I would probably still be considered an amateur. A happy one, though! Some people would roll around naked in money, but me? Ones and zeros, baby.

Well, now that you have a mental image that is none too exciting, I present to you the video!

As you can see, we have a playable dungeon with a "boss" at the end. The boss being a clone of the light bug but with a blood red glow, if you will. This is what I presented on the Friday before last. Enjoy!

Success(Cont. By John), My Drive, and The Future!

YAY! finally me and Jared have built something Playable and moderately worth showing. Its been a long week and a half of working an average of like 13 hours a day but I feel like it turned out well!

If you want to see Jared's Post is 'should' be below, this one hahaha

Me and Jared have been trying to make ANYTHING for a long time now, this proves not only to others but to ourselves that we can do something, get something done, and to me that means a lot. My dreams are slowly but surely coming true, and I plan to continue forward in this direction. I'm really happy with how it turned out, but with anything, There's so many things I would have done different had we more time. But overall its good for a first run.

More insight into my personal drive for the project, and the future of this project and others after the Jump

Success!

I'd like to formally announce that John and I have met our goal of a playable game! I brought it into my office today, tried to look fancy with my xbox controller, and played our lack of content game! There were a couple performance hiccups, but I didn't care. It was the first time I was able to show something I've helped build with true pride, knowing that my code is running well, and that my dreams are coming closer to fruition. My audience was a great group of people that I have come to love and respect over time, and I'm glad that they were able to share in that experience.

All good things must come to an end though. It is a harsh reality that this project will take someday. As I said in my previous entry, we would like to complete it, but it will take time to build everything else, mainly the content of the game. That's what is so beautiful about this game. We built the entire framework such that the content of the game will simply be using what we built. We squashed bugs here and there (and I am sure there are many more), and stuck to it and came through.

The game itself is not impressive by any means. You have one dungeon, some enemies, a random brute light bug enemy at the end and some switches. We wanted to build more, and change the keyboard input (I'd do it now, but i'm above the neck in homework which I am currently procrastinating on, plus I am lazy), but we have a build that we can give to people should they want to try it. Others may get over it within minutes, but for me, and I would say for John as well, that the ingenuity that we displayed in building the game will be with us for the rest of our lives as we continue to drive towards our intellectual passions.

Some may not completely understand why we did this. I'd like to try to explain that in a way that makes sense to me. Why would I spend my vacation, and for 12-15 hours every single night work on this game? My vacation was literally nothing but working on this game. John and I have been asked this question, and I'm going to explain why the best I can.

I personally have many reasons other than passion, including personal ones. However, when I was younger, games were how I passed time. Games involved me in a world that I could make sense of, and allowed me to be the person I am today. There is so much to some games that not everyone realizes. There are entire universes to explore. You solve problems and witness passionate stories from minds that worked tirelessly to bring hours of entertainment (For the record, this is why people who pirate games piss me off to no end). Not all games are simply about getting to the next level. This is what I love about games. They gave me something to look forward to in the future, and I want to do the same for others. Knowing that I could inspire someone to be passionate about something, games or otherwise, is an ultimate goal of mine, much like those who wrote games for me gave me my passions. It's a tough road, but eventually, you, me, and anyone else can achieve something if they try hard enough. That was the ultimate goal of this week. To show that we could, and that we did.

Finally, we started this blog to show the immense progress that can be made by two passionate people. If you compare the videos from before to how the game shaped up - you can't even tell that they're the same thing! As I had mentioned to others, knowing that this is our lovechild, that we built it from scratch using nothing but our own knowledge (and XNA, of course), is a tremendously good feeling. We know the code inside and out, and from when it was nothing but a little visual studio project! They grow up so fast!

Anyway, I hope we have helped inspire some people to pursue their passions, whether it is in games, computer science, or otherwise. Beginning, and working on something that you're passionate about, and then completing it is a feeling that words can't express. I'm so glad that I did this, even if it took my entire vacation. It was one of the first times that I was able to show people something I created, even if it wasn't perfect, that I was incredibly proud of. John did a wonderful job on maps and graphics, and we came together on everything.

I believe my rant is over now, and for those who are simply waiting for the game, the link is below:

http://www.thelunchboxlegion.net/AP/ArmorPotions.zip

The not as intuitive keyboard controls are:
W - Move up
A - Move Left
S - Move Down
D - Move Right
Space Bar - Swing sword (It will swing in the direction of the player)
Mouse Click - Fire selected projectile (From the lower left corner)
Arrow keys left and right will switch the selected item

Note: You need the XNA 4.0 redistributables to play this game! The easiest way is likely to go straight to the source:  http://www.microsoft.com/en-us/download/details.aspx?id=20914 

If anyone has any questions, suggestions, anything at all please reach out to us. We would especially like to hear if anyone has actually been affected by our work :)

Until next time!

Deadline

On the final stretch, we came across many things that we'd like to do. Although I'm highly satisfied by what we've managed to do in such a short time, it is unfortunate that we are unable to complete everything. For the presentation tomorrow, the graphics will be unfinished, but most of the functionality will be present. I'll share a couple problems that we had before going there, however.

Floating point numbers are an interesting beast in the world of computer science. The arithmetic can easily become unaligned when done many times. Our health bar is a clock in the game, and I had gotten it working.  Then, I decided I wanted to animate the clock strokes because it looks much better than a simple jump to where your health currently is. So on the first check in of the code (lines 84 and 90), we had to make a check to see if the current angle was greater than 0. What happened was, as shield and health were depleted, the angle was a little off to the right, rather than at a perfect 0 degrees.

Then we had a new problem. Healing did not animate. What's worse, it didn't even move back up! So we had to add additional checks to get this to work correctly. This all worked perfectly fine before animation, but because we were doing it one degree at a time (1 / 2 * PI), precision was eventually lost. Now, we have a perfectly functional health clock. 

Tonight, I was adding the enemy loader to the game. This way, on loading of the map it will maintain and update the list of enemies for the current dungeon. We had really only tested with one enemy, and other enemies used different components. When loading many of the same enemy, the reference to the AI component was the same to all components. This caused bizarre behavior with the enemies, they quite literally moon walked off the map. Although humorous, with time dwindling it was more on the frustrating side. In the end, I had to create another new instance on load the enemy, and set its properties through reflection. The reward is present though, as our game is looking more and more like, well, an actual game. Some graphics will not be complete, but this is as good as any. It will be a short presentation if anything as there is no real content at the moment. I can, however, show the functionality.

Some may also notice that I added a feed of all of our code commits. For anyone interested in the code (Be wary, it's certainly not perfect), that is your stop.

We'll be building a map to contain more environmental functionality tomorrow since we're very tired after the past week.

Since I'm excited regardless, here are a couple more pictures of our progress!

Thank you to everyone that supported us! We'll likely continue working on this for a little bit longer as we still have functionality to complete, but time is much more precious now that I will be back to work and classes. I will continue to post about various other things, including ideas for the game. I welcome anyone to give us suggestions, and to directly communicate with us about our game.

Until next time!

Map Collision and its Intricacies

I began working on map collision yesterday and made some measurable progress. I made additional progress today, and John made a new map to play around in. We realized two things. The maps we had worked with were all originally square. Thus, when we went with a map that was not square, we realized that our map was being drawn incorrectly! That is, the width of the map was being drawn as the height of the map. This resulted in a change in the calculation in drawing the map. Easy enough. Then, we had another problem. The collision deals with the x and y axis individually. When we held down the left direction, the collision would be fine, but when you pressed down as well as left, it would put you through the wall like the below picture. Eventually, you could wiggle your way outside of the map.

I figured that this would be a complex calculation in the collision logic that didn't allow for the corner tile to be checked against collision. I didn't think that was logical, but I went with it. Turns out, the problem was simple.

The collision result was being overwritten when there was more than one tile being checked. With my supreme knowledge (lol) of Boolean logic, I added a bit-wise OR operation to the collision for each check. Now it returns true for each axis if there ever was a collision, and false otherwise. So to clarify, what was happening was in the first iterations of the loop, there was a collision, but in later iterations there was no collision, which overwrote the fact that there was a collision with a previous tile. This solved the problem with the way our collision logic currently works.

You'll also notice that there is a little white box. That is its collision box. That means that we do not collide with its upper body when it comes to walking. In the words of John, our  perspective is all kinds of messed up. But we'll let that go for now. An example is below:

We are in crunch time with getting the remainder of the functionality working. We still need combat, and we're going to be shrinking the tiles. We'll be working hard before any further updates. Until then!

The Calm

After 50 to 60 hours of relentless hacking at our creation, we've decided to take tonight and tomorrow as a time of rest. We still have much to do, but we are not concerned with being able to get it done by our deadline, even if they are complicated tasks. All the pieces are beginning to flow together. We integrated John's camera with my entity and item code, equipment was tested and works, AI area of effect attacks and states as well as being able to change complete behavior with the change of a single text file. Our design likely has flaws, but we are very happy with what we've done, and I'd hate to sell either of us short. John has done a tremendous job with the maps and the graphics. We are really pulling together to accomplish what we set out to do, and I'm very excited that we've made it this far.

The below video will show this. John posted some concept stuff in the last post, and you'll see it in action here. The first video I posted was mostly temp graphics that I had laying around. I am pleased at the style we're giving the game.

The first thing I should warn about is that we have not implemented collision yet. That is one of the tasks for the remainder of the week. However, this should be enough to show our massive progress since we started. We're currently hovering around 2,000 lines of code. In retrospect, that is not a lot, but it's always a fun metric to look at if nothing else. The light bug AI uses a generic "Area of Effect" module that will charge and attack when the player is near, and move randomly otherwise. I can change this behavior as well as its properties painlessly. Further, I can add this AI to another enemy and change the image, the delay of the charge and the lifetime of the effect without touching code at all. This shows how the AI comes together, and with its versatility, John's map system can easily be integrated.

You'll also note that the player no longer "moves", but everything around it moves. This is the integrated camera system, and what you see in many 2D games but may not always realize it. While the player still moves internally, the drawing centers everything around the player creating an effect of the player moving, while keeping the player centered. The player has a couple inventory items that can be cycled, and are shown in the video as linear, area of effect, and cone projectiles respectively. A cone is a linear projectile, but it fires at a spread of 45 degrees to create a "flame thrower" effect.

I've thought a lot about what keeps me going, and I honestly  believe that because I've been so busy between work and classes these days that it makes me appreciate the time I have to accomplish something. Before when I was discouraged, I would quit. Now, I keep going. It truly is the best way, especially when what you are doing is difficult. This game will not be perfect, but we've learned so much about the environment we're building in.

Our tasks for the remainder of the week currently include:

• Map and Enemy collision
• Linking map switches (i.e. door switches) to doors, so when activating them they correspond to the correct door
• Designing at least one dungeon to be playable
• Combat
• A couple tile textures that need to be implemented such as deep water and lava
• The GUI for inventory and perhaps a couple of other screens

Most of these are simply extensions of what we have already written, with the most difficult being map related items. Tomorrow will be a slow day, but some progress should still be made.

I'm amazed we've gotten this far and are on track for our deadline. One success after many failures is a great feeling, and even better than I can say that I've completed the challenge imposed on myself for my director. With our track to success has come dedication to our passions. 

For now, we have some limited functionality that is useful to a player. Next time though, we should have a fully playable demo!

Until then!

Today I Ate a Taco

It was Delicious. I felt wonderful afterward.

Now on a completely separate note, hey there anyone whos reading this, I'm the OTHER guy who can post here, Mostly I do Graphicals and Sounduals and make up words and such, like Permaquips and a few words you read in getting to this sentence. I also do the lesser programming stuff that Either Jared doesn't want to do, or I take on myself to make things slightly nicer to look at.

So, Since this is kinda an intro to what I'm doing on What were calling code name: Armor Potions

The last 3 days I haven't posted due to our busy schedule of "get shit done, go, go, go" what I've done is basically come up with a basic theme for the environments and scribbled some temp graphics, Which I have PLENTY left to finish but I thought Id share some concept stuff here for... Archiving... purposes.

This is the basic Player scribble, Ill get a good one at some point, and ill color the rest eventually but Meh. the basic concept was supposed to be a Top Hated Gentleman since the Scene I was going for was a Steampunk feel, eventually he gets goggles and a Mechanical Ball that shoots Fire Lightning and Ice and when I feel like adding it a trench coat. for now he goes coat-less

this is actually the second enemy i made, the first was a kind of Gelatinous Cube, which I liked but I havent spent time on, this one was easy so I pounded it out real quick, its partially transparent so the floor tiles and such show though its body. the idea was that it was a bug, that was also a Jar holding fireflies in its belly. and it uses the Glow to power its electrical attack.

This was the electrical attack I made for the Lightning bug, I used an old technique to make lighning in gimp and came up with this... I was pretty proud just saying.

This was a picture I took, before I somehow lost or Destroyed them, of most of the enemies minus a few others(Which were on the back but we don't talk about those... they were bad) if you notice the lightning bug is in the upper-ish right hand corner. that became the above. Lightning bug you saw

Beyond that I coded like 80% of the tile system and 0% of anything else. Ill be doing input at some point but that's after we get GitHub working.

Untill I have Post time again, Later!

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!