MerryChristmas++;

Day Late but whatever, Merry Chrismas to everyone who Celebrates! And Happy Holidays to anyone who doesn't! :)

Anyway, Me and Jared haven't posted in a while, Work, Holidays, and More Work have taken its toll on us, and we've been enjoying some down time. We spent some time talking about where the game is going in the next few months. I, personally, will take what time I can to get that map system revamped.

I like this game a lot, and I've put some thought into the concept Once I get the Map system Revamped, I don't know where else we're going.

Sorry to Leave you guys with Just Text but I have nothing Handy to Upload for you. :(

If you want the LowDown on what Me, personally, have been working on, Its after the break!

Binary Trees!

Hello everyone. I know neither John or myself haven't posted in some time and I do apologize, but I am currently taking two advanced courses on top of work (bad decision), and it is catching up with my free time. I can't believe I'm already nearing the end of the 4th week of the class, though. That's ridiculous. It feels like it has been one week at most. Still, in the short amount of time I have learned a lot. Since I don't have any new game programming developments, this is going to be a fairly technical post in computer science for those up to the challenge. If not, and you're only here to see game updates, this entry likely won't interest you. So if you're interested, press on and click the jump, if not, I understand!

Steampunk Island!

On a random note to begin with, Me and Jared hit the new Microsoft Store. Jared isnt as excited as I am about Windows 8. Just the fact that Windows 8 and Windows 7 began development at the same time, so they've had plenty of time to work out most of the bugs.(On top of having a Developers and Consumer preview) I don't think it will be Bad, Its just not entirely worth it if you don't have a touch screen(Which Id get so that's not a problem on my end)

In Short- I want it.

Also I want Spotify Back...

ANYWAY on to...

Jack Hunter: Final Voyage of the Natalia 

Excited to be back? Yeah Me too.

I've spent a lot of today working on some ideas for the look and feel of the game... I also Rough Drafted a basic story line leading up to the events of the game. 

Long story short your a Student of the guy who built a Island/Airship called the Natalia cause he was paranoid water world was gonna happen, you find out he was killed by pirates and that the Pirate leader set the Natalia on a crash course with England. you happen to have read through the schematics of the Natalia in your time working with the professor and know how to stop it before it crashes. Game On.

The big update here was going back and looking at the story and matching the environments. Ill be spending some time going back to the art side of things and making Walls and Such match the theme of the Game a little better. 

Here are a couple of the Reworked characters, Notice the Lightning bug, Which was a little ball of Jelly is now called the "Tesla's Electromagnetic Discharge Insect Drone" and on the Right we have the "Wheeled Anti-Personnel Heated Dispersal Unit" 

I was re working the enemies because originally I had too many organic enemy's, Not to say there aren't any, but the Professor was living on this Ship alone and its HUGE. Makes sense he Built robots to do menial takes like weld pipes and Oil things. and the Security Drones were to keep the Livestock living there out of the machinery 

I'm also looking into the steam pipe puzzle I'm still seeing what I can do with it but it should be awesome.

The last thing I got done today was I worked on the MapTool which is done for now, I just need to get the tool to Do Switches and Ill LITERALLY have all the pieces to loading part of the game done.

But for today im Passing out, tomorrow I Should have time to get stuff done. 

Till Then!
-John

The Bits, Nibbles, and Bytes of Life

Many new developers struggle with the idea of bits and bytes at a low level, and why they are useful to us as software developers since we have high level languages that abstract it away from us. Most of us are aware that a computers language is in 1s and 0s. Glorious 1s and 0s reign supreme in the digital world. Analog signals such as the human voice are analyzed and converted into a static on or off signal. Sequences of bits come together for a common purpose: to represent and execute information at the programmers whim. Sometimes, being in charge of development can give someone a God complex. We have all the control. Even though there are occasions where the computer (doing exactly what we told it to do, no less) is seemingly rebelling against our authority, we can eventually tame the beast into submission.

Still, the emphasis on the underlying beauty of the digital machine isn't as prominent as I feel that it should be. Consider this simple program in C++:

int a = 0, b = 0, c = 0;

a = 5;

b = 5;

c = a + b;

It's so simple. Even the people who have never seen a line of code could reasonably guess at what's happening here. We are declaring three variables, a, b, and c, and we are assigning the constant value of 5 to both a and b, and finally, storing the result of a + b into c. How could a computer not understand something so simple? The truth of the matter is that this 4 line program gets converted into, with collective optimism, a 17 line program in the computer language not including a lot of the setup and finalizing "stuff". Here's an extracted segment of just the 4 lines we see above in assembly:

; 4    : int a = 0, b = 0, c = 0;
mov DWORD PTR _a$[ebp], 0
mov DWORD PTR _b$[ebp], 0
mov DWORD PTR _c$[ebp], 0
; 5    :
; 6    : a = 5;
mov DWORD PTR _a$[ebp], 5
; 7    : b = 5;
mov DWORD PTR _b$[ebp], 5
; 8    :
; 9    : c = a + b;
mov eax, DWORD PTR _a$[ebp]
add eax, DWORD PTR _b$[ebp]
mov DWORD PTR _c$[ebp], eax

The first three lines store the constant 0 in the storage locations of a, b, and c. Remember, that these names are meaningless to a computer. Each variable has a memory address. This code is still an abstraction which is translated to the computers CPU language. The commands like mov and add will be translated to a binary op code such as "0110", which in turn is translated to an electrical signal.

Before I get too excited, there is a point to my madness. How does this make us better developers? How does knowing what code is translated to at the raw, naughty level of inside the machine useful?

The simple answer is this: Everything we learn can be applied in places we would least expect.

There's another reason, though. I'm going to use C# and the .NET CLR (Common Language Runtime) as an example. The + sign can be used to add numbers, but it can also be used to add Strings. In addition, there's an explicit function called String.Concat. What happens at the lower level? How are these different? Are they different? Consider this C# Snippet:

String str = Console.ReadLine();
String str2 = Console.ReadLine();
String test = str + str2;
String test2 = String.Concat("hi", "test2");

I read two strings from the user and store them in str and str2. I then explicitly call String.Concat with two compile time constant Strings. (Compile time meaning these are known at the time the code is compiled, as opposed to str and str2 which are known at run time because the user has to enter them). So what happens? What do you think? They're the same! Here's the code compiled into the intermediate language of the above snippet:

.locals init ([0] string str,//Declare the local variables by index
[1] string str2,
[2] string test,
[3] string test2)
IL_0000: nop //No meaningful operation is performed
IL_0001: call string [mscorlib]System.Console::ReadLine()
IL_0006: stloc.0 //This pops the item off the input buffer and into the variable str
IL_0007: call string [mscorlib]System.Console::ReadLine()
IL_000c: stloc.1 //This pops the item off the input buffer and into the variable str2
IL_000d: ldloc.0 //The next two lines push the local variables back onto the evaluation stack to be passed as parameters to concat
IL_000e: ldloc.1
IL_000f: call string [mscorlib]System.String::Concat(string,string)
IL_0014: stloc.2
IL_0015: ldstr "hi" //Load a string onto the stack directly
IL_001a: ldstr "test2"
IL_001f: call string [mscorlib]System.String::Concat(string,string)
IL_0024: stloc.3
IL_0025: ret //Ends the function

But wait! There are two calls to String.Concat? The compiler will convert the + sign between two String types into a Concat call. So at run time, there is no difference. There's also a reason I used "ReadLine" to get input from the user. If we use compile time strings like str = "hi" and str2 = "test2" and do str + str2, the compiler will be clever and combine the strings directly into the IL code instead of making a String.Concat call. This saves CPU cycles at run time. This isn't apparently useful, but to extend this concept is an important lesson. The reality is, in typical business development, it probably won't be necessary to think in these terms. In game development, however, this can make or break some performance factors. Game developers are always thinking of how they can save precious CPU cycles. Although I am far from experienced, this is a lesson I learned while working on Armor Potions.

Consider another example. When we think of the remainder of two numbers, what do we think of? Bonus points for anyone who successfully mentioned division. Well, sometimes a compiler is very clever. Using .NET as an example, and this is what originally got me interested in looking at the compiled code, is that if we take the remainder of dividing by 2, the .NET compiler uses no division at all! In fact, it's very clever while using the binary representations of the integers. Division, to a computer, is often compound subtraction which wastes cycles. So this optimization by the compiler is an interesting point. However, there are other solutions for getting the remainder of a number when dividing by two, one that saves even more cycles.

Consider the binary representation of the number 15, which is 1111. For those who don't know, binary is a base 2 number system. This means that, from left to right, the digits represent a power of two. The above number can be constructed as 8 * 1 + 4 * 1 + 2 * 1 + 1 * 1 = 15. This knowledge helps us in some cases, and because it's the computers language, we will use it to our advantage. Note that this is an odd number. What is the definition of an odd number? It's 2n + 1. Note the 1! An even number is simply 2n. 2 times any number n is an even number. In this case, if we add 1 to an even number, it becomes odd. The rightmost digit in a binary number represents 1. So if that digit is 1, then the number is odd. If that digit is 0, it is even. So any number ANDed with 1, and if it equals 1,  it is odd. In C++, it would look like this:

15 & 1 == 1; 

12 & 1 == 0

and so on. This works because with an AND 1, we're comparing the right most digit to compare the value. It should be noted that these are not that much faster than normal methods. The compiler is sometimes clever and does the optimizations for us. We shouldn't be spending all of our valuable time looking for these subtleties. My point is that these exist, and in some cases, such as my example with collision in a previous post, it can actually be a solution. Things like using bit strings to represent the collision behavior of a tile is an oft used mechanic. It's important to understand that these can be very useful in the developer tool kit. We never know when they will come in handy.

Ughhhhhhh

I've been working on the Map System a bunch and I've realized how incredibly much I need to fix, Working that all out will take more time then i had originally planned.

Plus with all the work in real life I have had over the last couple weeks... I haven't had the time nor energy to actually do any of it. 

I figured out how to make the system I wanted to make work so now its just a matter of finding time to do it. and figuring out how to integrate it back into the game as it literally breaks the old map system entirely.(and it only breaks it because I took out all the shortcuts)

Momentum

My apologies to anyone that does read this for our lack of frequent posts. I decided to post this as an interim idea rather than waiting for the next big break with Armor Potions.

John will be working on the new map system, but if he wants my help I'm glad to offer it. My part will be more likely fixing bugs and coding the AI for the new enemies that he comes up with (FYI, anyone interesting in doing graphics for this game is strongly encouraged to contact us as it's our weak point). The graphics will be the last part of the game to be finished. Before that is gameplay and the progression itself.

Right now, our map system deals with a hierarchy of sub classes from the Tile base class. Anyone who is savvy to software development will probably be cringing at the thought. Even I do, and I was part of the decision due to time constraints. John and I sat down and, well, John is the one that thought of it pretty much. We'll be removing the sub classes and using a single Tile class to operate on all the tiles. To be honest, I'm still not completely clear on how it works, so I'll leave John to describe it. We'll basically be adding an additional layer to the map where currently we have the bottom layer which is non-collidables such as floor tiles and such. The second layer was originally anything collidable (switches, etc). The switches as a tile though means that we're forced to make the switches the same size as any other tile. This has many drawbacks. For a game like Zelda, it didn't make much of a difference because the tile resolution was very small for the game boy screens. So everything being in unison size was the least of their worries.

Since we have a much larger tile size, we need to be able to say that the switch can be other sizes. Just imagine a floor button switch the same size as the wall Tile. Yeah. Although that might be humorous in some parts, it's not ideal in all situations.

Eventually, I'll be creating a link on the side bar here for updates to our release build that will contain a read me with instructions on how to play since the controls have been updated slightly (I am not particularly fond of them, so any insight here would be appreciated).

The rest of this is going to be slightly off topic from the entry, but more on par with the title of this entry.

Many people struggle with motivation, and I am no exception. There is no golden rule to suddenly become motivated. However, many don't realize the power of momentum.

I try to learn something everyday. Mostly within my field, but I am pretty lenient with myself as long as it's something interesting. So, regardless of motivation status, here is my challenge:

Take 5-30 minutes of your time every day, and learn something. It's preferable that it's something you're passionate about, or within your field of interest. I say 5 minutes because it doesn't usually take as long as 30 minutes. Take the first thought of something you're not sure about, Google it, and absorb the knowledge. The best part about this, is you can even come back with more questions! Keep this momentum!

I personally am happy to talk with you about what you've learned, discuss it, analyze it, or look up and solve a question with you. My point is, do this every day. I don't stop at one thing, but that's because I have months of momentum behind me. It can take as little as 5 minutes of time to learn something beneficial. I shouldn't have to say this, but anything related to the latest movie, celebrity, politics, or anything of that nature does not qualify as beneficial. If you can tell me what the technology or history behind a current [thoughtful] movie, then I'm all for that. Something as simple as the making of snow white is absolutely baffling.

The reason this is so helpful is because you feel better about what you did for the day. You're on track to your passion, and you know something you didn't know before which, to me, is invaluable. I hope that some of you will come to me with what you've learned so that we may enjoy a cup of tea and an intellectual discussion.

As an example, here is what I recorded of what I learned one day:

• Magnetic materials in sub freezing temperatures can store a digital 1 and 0 in a space as small as 12 atoms, and are even showing signs of quantum mechanics http://www.nytimes.com/2012/01/13/science/smaller-magnetic-materials-push-boundaries-of-nanotechnology.html?_r=1&
• The bus and CPU cycles times are closely related. Things sent across the bus, such as CPU interrupts, are determined by the bus speed (such as 400 MHz), and execution of instructions are determined by CPU type (Such as 2 GHz)
• The stack plays a fundamental role in not only programming languages with function calls, but within the CPU directly as well because when interrupt handlers are called, it must push the function onto the stack and pop it to return to the original program that was suspended. To put it into perspective, every keyboard press triggers an interrupt, stops the current program executing, handles the interrupt, and then finally resumes.

This took me about an hour of research, but all I am asking for is 5 minutes of your time. Be productive, and learn something. Some of you might be fortunate to have jobs that allow you to learn fascinating things everyday, but for those who don't, this is even more necessary. And don't say you can't, because you all have smart phones and probably have what I call "wait states" that you could quickly do something. This is meant to be a work out for the brain as opposed to a work out of the body.

This is something I challenge everyone to do. 

Energy Drinks!

Hey there! I'm hyped up on Caffeine!

So Today was kinda productive on my end, and I apologize to Jared for being sidetracked.

I got 2 of the maps done! the first of 2 is a small map that has some enemies and some doors that are opened with a new type of switch. one that is activated with the Space/A button not like the other switches that are elemental. The second is a bit bigger when compared to the first but still only contains Switches.

These only contain regular switches that have to  be manually activated because you start with ONLY the sword in the finished game. the first item you get is the Fire Eball which activates fire switches. so I theoretically COULD change the switches to fire switches in the second dungeon... but BLAH whatever.

I also started working on finishing the Code for the map maker so that it loads the map, cause I hate starting from scratch every time. i'm still writing the long number parsing for the switches so until that's done the maps are basically the 3 we have.

This weekend me and Jared are going to be going over Interact-able things like wall switches, Chests and NPC's(maybe? not set in stone, but might be a help.)  we're also going to sit down and fix the event system with Switches and doors. cause I suck at programming and that was the easiest way to get it done, so now we can come up with some ingenious way of doing tiles.

That's the Shpeal with Armor Potions. I'm also kinda working on a side project. if you want to read more its after the break:

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!