About this blog
Sprawling text for ocular consumption written by a hobbyist game developer.
Entries in this blog
So I'm wondering why Tuss Toss fps drops by about ten frames when there's around 100 or so particles on screen. I found it quite perplexing, so I decide to add some profiling code to find out the problem. Lo and behold I discover this wonderous line of code that I must have put in my infinite wisdom of a late night coding session:
// Stall for timing.
Yep, way to test how long it took you to render the whole frame, dumbass. WTF you can't get 300fps in debug mode?!
Seriously though, I'm awesome.
I spent the weekend battling with Ubuntu and trying to get it running on my desktop. After nearly a day and a half of screwing with X and dependancy hell, I could never get a bunch of the things I needed running (like my dual head display). Reinstalled Fedora Core 5 and it worked flawlessly. Nothing against Ubuntu (I may install it on my notebook) but it just didn't do it for me. Fedora just feels right and works on my setup without a hitch.
Now that that's out of the way, I can get some actual work done. I'm currently plugging away at story mode right now for Tuss Toss. Once its finished (the milestone must be hit by tomorrow) we do some closed beta testing.
We've finally gotten an intro sequence into the beta. Now oure testers have an actual understanding of why this girl is throwing perfectly good soda at evil aliens. Here's a shot from the first frame of the intro, courtesy of the artist Kelso:
I've employed particles into Tuss Toss v1.1, and I'm pretty happy with them. There are two types. The first is a "streak" which occurs when the player uses the quickdrop button (also a newly implemented function). Check it out:
The other kind is a droplet, which is created when a block explodes. The droplest match the color of the corresponding block destroyed. Here's a closeup shot:
In other random news, I'm now working at my summer job on campus as an apprentice desktop technician. Also, I was recently met with a couple faculty members at my local community college. They were looking for some one to possibly teach a course in game programming and apparently my boss at my current college gave them my name. They are trying to work out the logistics right now, and if they manage to get the approval, they assured me that I would be the one teaching it. Sounds like a good opportunity so I'm keeping my fingers crossed.
There's been a lot of uproar regarding XNA among the community lately. A lot of people have become really excited with XNA at the prospect of making games with the XNA Framework, but to be honest I am very..."blah" about the whole thing.
I've been developing with C# and Managed DirectX for the past 2 and a half years, and I have learned a lot about C# as a game programming language and Managed DirectX as an API, and here's my thoughts on the matter.
1) You can be crazy productive, and knock out prototypes in an incredibly fast amount of time. The more common tasks in 3D programming are very EASY to do, but there are a lot of generally advanced things that are NOT easy (i.e. skeletal animation).
2) The documentation and object oriented style make MDX a true joy to work with for C# fans and developers, or any fan/developer of object oriented programming styles. It's incredibly intuitive and robust.
3) Deployment SUCKS. It's not because any single thing is altogether difficult, but when you have several minor pains in the ass you eventually end up with a rather huge pain in the ass.
Bottom line is that my experience with C# and MDX are great for making small and simple prototype games. However, the scalability of the API is not linear and deployment is rife with headaches. This makes it somewhat difficult to create full-featured, next-gen games. For the hobbyist, it's great.
So where does this fit in with XNA? Well the bottom line is that the same issues I have with Managed DirectX exist with XNA. It's a great Language/API combo for hobbyist or casual games, but the API is going to need a lot of maturing before we see mainstream titles use the technology. Granted this isn't an issue for most people, but it is for me (I have more lofty goals). C# needs a killer app to get the respect it deserves in the commercial front, and I just don't see it coming with XNA in its current state.
I just caution people to remember what Microsoft's true goal here is: to make money for their shareholders. I have nothing against Microsoft at all, in fact I am very thankful for what they have provided developers with C# and the .Net Framework. But the bottom line here is that hobbyist and educational game development is a new market for them to expand into. With XNA they will make a good amount of money on the sale of subscription fees and consoles from hobbyists and educational institutions, not to mention provide a lot of content for Xbox live to help compete with the Wii's virtual console. So just take XNA with a grain of salt, and if it doesn't do it for you, give Tao a try.
There comes a time in just about every game programmer's life when they decide that they will take on a task which is generally only tackled by the insane, the stupid or the brilliant. Because I feel like I fall into all three of these categories, it is a natural progression for me to take on this task. No, I do not mean making an MMORPG...I'm talking about rolling my own engine.
There's always two sides to the debate as to whether or not a hobbyist or indie should ever bother with such a task, but I am going for it. I feel like I could learn a lot in the success and failure. The end result would give me a piece of software that I could reuse for rapid development. Of course, I also have a game in mind with which to use the engine, if I didn't I wouldn't even bother.
I've dubbed it "Machina Ex Machinis" (MxM for short) or "The Machine from Machines" because Latin makes everything sound a lot higher on the coolness scale. Current features include the following:
-Completely modular Object Oriented design.
-Written in the C# language.
-Cross Platform (thanks to Mono and Tao, Windows version may use MDX).
-Primarily 2D engine, will contain support for 3D rendering features.
-Highly scaleable through a modular design to promote a longer shelf-life.
Right now I am unsure as to whether or not I plan on making it open-source. I most likely will. As you can see I have a lot of details ahead, so now I'm working on the planning and design side of things. Hopefully more frequent journal updates will follow.
We've been lucky enough to have a couple of very responsible people beta testing Tuss Toss. Right now I'm devoting most of my time fixing bugs and polishing the aspects of the game that I can. I figure I will continue this until about the 26th. At that point I will make a release version for contest submission. After that it will be an incremental release vesion (for the public) along with a shareware version.
Well I'm still trying to iron out the design decisions for the engine (more like framework) that I will be making soon. I'm still trying to decide on what technologies to use. I want the engine to be cross platform, and I'm wondering if it is still too early to rely on C# applications for games. The difficulty distributing Tuss Toss makes me wonder if it's worth the hassle of forcing my user to download the .Net framework or Mono.
I absolutely love coding in C#, but making games isn't always about what I want, it's more about what the user wants. I'm really curious as to whether or not a gamer truly finds it a hassle to download another piece of software in order to play a game. I also enjoy C++ a lot, but I can honestly be far more productive in C# than I ever could with C++. Maybe I'm just overthinking the whole thing. Maybe I should just pick one thing and run with it, never looking back.
Since I know people love media in these journals, I'll start off with a link to the music track for Boss Levels in Tuss Toss. Enjoy.
Tuss Toss is coming along great. We are in the muster stage of gathering all the content and getting it into a fully featured game. So far the level editor, free play and custom play modes are complete. All we really need now is to finish story mode, and touch a few things up.
Our soft deadline is August 1st. This gives us approximately 3 weeks of heavy bug fixing and gameplay adjustment through playtesting. Then its onto entering slamdance. We are also planning on entering the IGDA awards as well, for a little exposure and learning.
Alright so I haven't posted in a short while, and I feel like I should post something so today I'm going to do a quick tutorial on how to do some basic 2D drawing in a 3D environment, so if that's something you are interested in, read on.
In Tuss Toss I use a 3D API (Managed Direct3D) to do 2D graphics. This means I utilize a 3D coordinate space to represent my 'world' and a camera to capture the image of my world. The reason why I chose to do this, is because you can get some really neat effects by using a 3D that you cannot get in a pure 2D environment.
My basic approach was to place the camera in such a way so that I would be dealing with a normal 2D environment. This means that I could refer to things with just x and y coordinates while projecting them onto the 0 z plane. For a visual representation check out the image below.
Now as you can see the camera is placed in such a way so that the 640x480 backgrounds will fit exactly within the camera's viewing space. Now the trick is where how I figured out the calculations. Logically, you could probably imagine that you want the camera looking at the dead center of the background, and also be aligned in the dead center in the background. The major question is: "how far back does the camera have to be?" This calculation took some number crunching, but with a little basic trig I was able to work through it. Consider the following image.
What you are looking at here is a side view of our scene. Basically the distance from the background to the camera's position is represented by the variable d. Because the camera is aligned with the center of the background, and the line from the camera to the backgrounds center is straight, we can assume that line is perpendicular to the background. This forms some right triangles for us. Now my particular camera uses a standard viewing angle of 45 degrees or 1/4 PI radians. So we can assume that the angle for either of those two triangles is one half that amount. This means that angle between the longside and the hypotenous (sp?) is 22.5 degrees or 1/8 PI radians. We also know that the length of the short side is 240, since the center lies halfway down the background.
Now think back to your high school calculus. SOH CAH TOA is your friend! This is a little memory device for remembering the sin, cos and tangent definitions. The one we want here is TOA, which is short for tan of theta is equal to the length of the opposite side divided by the length of the adjacent side. The length of the adjacent side for our sake is the variable d. that leaves us with the current formula of:
tan(22.5) = 240 / d.
Now we do some basic algebra to get isolate our unknown. That leaves us with the formula:
d = 240 / tan(22.5).
Crunch those numbers and you should find that you have the same camera distance supplied in the first diagram. It is important to realize that I am using a LEFT-HANDED coordinate system so this z value is positive.
Well there you have it. This technique should serve you well for using a variety or resolutions for a background in a 2D game. This technique could also be the basis of using a scaleable hud in a 3D game as well by setting your projection plane a short distance from your camera. Hope I didn't bore/confuse too many people.
I haven't updated in a while because I took a couple days to step away from the project. I've been contemplating where I've been and how I got to this point in my indie development path. I started learning C++ only 2 and a half years ago. It's kind of hard to believe all thats happened occured in that time, and how I've grown. I've become a good programmer, not great but certainly good. I've become a good game designer, and an adequate team leader. These are two things I am trying diligently to become better at. My knowledge grows everyday and I know that I have a long way to go still. However, I really have come a long ways from the day when I was scripting a mod for Neverwinter Nights and said to myself: "I don't really want to make mods, I want to make games, and beautiful ones."
Since then though there is one thing that I haven't been able to shake, and its the lack of interest in my team's first graphical game Tuss Toss. It currently has a measly 53 downloads on the GDNet showcase. It really is a good game. I know it has its flaws and I am doing the best I can to learn from them. The game is completely full featured. You'll be hard pressed to find a more vivid and lively color scheme and high quality 2d art. It has great sound and music. Cool custom level design and an endless free play mode. The gameplay is simple yet addictive. Is it fun? I thought so, and so did a lot of people. Not everyone did though, and there were some pretty glaring shortcomings.
My first review on the showcase was not a good one. The reviewer is entitled to his opinions and I truly believe they meant well. However I really think it stopped a lot of people from trying the game out. I ask myself constantly how I could have prevented that review, and I know one simple way: by speeding up the gameplay.
How could I have done this? A couple ways come to mind. I could add an autodrop button as suggested. It would do wonders to speed up the game, and assist the player. Having to wait for a block that you don't need to land is boring and dumb. Another thing I could do is go back and tweak some of the levels. A couple of them were just plain tedious and could be redone. One that I made personally was from world one where I made the level appear like the Suck's world these were from. Waiting to get that many blue tusses is just awful. Speeding up the gameplay in these ways also favors the player, which makes the game easier and more enjoyable. A block drop game isn't a brain buster, it's a test of quick wits and reflexes.
I really don't want to turn this entry into a post mortem, but suffice it to say all these thoughts have brought me to a single question. Should I try to fix Tuss Toss? Is it worth it? I know what gameplay decisions I would change, but what also would I do? I've been toying around with the idea of even rewriting it in java and a different graphics API to make it incredibly portable. I've even thought about rewriting it to run only in a window. The one thing that stops me from doing these things is this question: Is it worth the effort to try and rebuild this game the way it should be, or should I cut my losses, acknowledge my mistakes and learn from them by not repeating them in my future (and current) projects?
Updates have come painstakingly slow lately. I added some simple picking to the alpha I'm making which worked perfectly without too much of a hitch. It detects what tiles are being clicked on using a ray-triangle simple intersect formula. I want to add a couple more basic things to the alpha, like meshes and maybe lighting. Other than that There's really not much more to do than jump in and start getting into the thick of things. Several things are really keeping development slow. Those being my 10 hour workdays 5-6 days a week.
Stupid little things also keep my team held up, not to mention a lack of enthusiasm and help on their part. Can't help but to feel that these are really my fault as a team leader who doesn't really have time to "lead." Ahh well maybe that's just the long workweek talking...I should get back to something productive.
Finals are over, time to work on stuff I actually want to work on!
As you can see I've got the main title screen up and running. I've also laid the ground work for the game's states. Things are a lot more cleaner this time around than in the original game, and I am pretty happy of how smooth things are going. I have also added a fade-to-white fader instead of my old fade-to-black fader. The artist and I thought it might fit the game's color scheme better, and I am really liking its overall effect and a trasition mechanic.
Certain things are a little rocky though, as I am using both textured quads and sprites. Occlusion has become an issue at times. But we press on. My only regret right now is not spending the amount of time that I should. Especially since I've been having thoughts of starting a new side project.
The following is an IN GAME RENDERED SCREENSHOT! (wewt).
Basically what you are seeing is a test level randomly generated. Below the tile mapped spaces are two layers: one has those crazy words/symbols and the other is the cloud layer. I also added some alpha blending into the tiles and symbol layer for a really "dream-like" appearance. Let's just hope my artist doesn't flip. The neat-O thing you can't see is that the cloud and symbol layers are scrolling independently of one another.
I know it's a relatively simple thing, but I'm pretty proud that I was able to accomplish what I set out to do for once, and solve all my problems on my own along the way. Can't wait to add some models to this sucker!
The ASP or Automated Security Program is the most common of network securities. It is both versatile and ruthless in its hunt to expell network intruders.
Now that I have some free time and can really be programming things that I want to program, I've continued on with the first phase in the Tuss Toss remake. My talented friend and artist, Kelsey, has converted all our old backgrounds into useable texture formats. Kelso also decided to change Trixie's pose as he wasn't satisfied with it in the original game. Here's a look at what the bakcgrounds look like with the new font stuff written over them.
The next part of phase one is to get all the block art converted to texture formats and have them able to be drawn to the scene.
I know I haven't posted in my journal in a while, but things have been a bit crazy lately. The semester is at an end and I am currently in exam mode. My main concertn right now is programming a hide and seek game using quake bots for my AI class as a final project.
Also, I have been ready for a very important event in my life, I am finally moving out on my own. I'm a little scared at the unknowns that lie ahead, but this is something that I really need to do to move my life forward. I will officially spend my first night out on monday in my new appartment. Wish me luck.
My friends and I at TiStudios have also decided that we are going to enter Tuss Toss 1.1 in the 2007 Slamdance Guerilla Gamemaker Competition. It's a lofty goal, but we are hoping it provides a strong motivation to complete the project.
Megeas is still undergoing some hardcore design. I have had to make some pretty important decisions that will have huge impacts over the course of development. So lets hope they are the right ones. I will try to get an image soon to show the architecture.
This is NOT an in game shot, still conceptual.
Lately I've been working on the level editor toolset. Building tools is a breeze with C#, and I highly recommend using the language and resources to anyone, regardless of what language/platform/API you are working on. Take a looksee at what I've accomplished in just a short time:
I've still got a ways to go here, but the tools are definitely comming along great. In a very positive mood right now :). I also know you fear my elite icon art.
Guild Wars has made me quite unproductive lately. Usually after the initial thrill of a new game settles down, I'm able to get some work done. Despite that though, I'm really enjoying the game. I won't go into a rant about why I like the game, but if you've got any interest in the game it's worth checking out.
I've finished my font writer wrapper and I'm mostly happy. It uses the Direct3D font interface to do most of the dirty work. The upside to this is the ease of use of the class, but the one thing that kinda dissapoints me is that I become limited in the fonts I can use. I really wish there was a way I could load a custom font from a file, but as far as I can tell there weren't any constructor overloads in either the Microsoft.Direct3D.Font or System.DRawing.Font namespaces that had a load from file parameter. Although I couldn't add this one feature, I was able to create a neat linked list feature that allows the user to make as many font objects as necessary. Creation of a font yeilds an integer handle back to the user in order to reference the font. This handle works almost like a pointer. I was pretty happy about doing this because it allowed me to keep the actual font objects hidden from the user and safe from any unwated changes that can occur to unprotected data. Not to mention the flexibility and scalability it gave me. Yeah I know it's just a font writer class, but at least I'll have something that can be reused with relative ease.
Today at work I got horribly lost trying to pick up product for a customer. The supplier that I was getting then material from was in a town called Podunk...I found this midly humerous as I was in an angered state from being lost. So after 5 hours on the road today the morale of the story is this: "Retail sucks, get your damn degree in comp sci so you don't have to sell rocks anymore."
In Delphi news I am currnetly programming an Effects class. This class is slightly complicated and will be used to apply any type of offensive or defensive effect. From dealing a simple amount of damage to creating graduated attribute buffs, this class is going to describe it all. No doubt this will take me a considerable amount of time to implement right, only to find that I've done it all wrong.
Yes, I sell rocks.
Tuss Toss is now the currently featured game at gamesareart.com. Feel free to swing by there and check it out. I really love what they are trying to accomplish at gamesareart.com and hope that Tuss Toss finds an audience there.
Been slugging away through the level editor still. You can now add just about every scenic element to a level and even adjust lighting properties. Here's a little screenshot, because I love you.
Today at work I tweaked the particles so that the would rotate on creation and face the direction they are traveling. For the first time in a looong time I had to bust out the arccosine up in this piece :-p
I'm much more happy with that now, and so is Kelso. Gonna try to keep these updates constant. :).
Please don't give into the haters. This new scheme is much more professional and trendy than it used to be.
Dark and bland color schemes are not professional looking, and they are not attractive. By increasing the visual standard of this website you have also increased its appearance to those that visit here, and its position among the game development community.
Dark color schemes do not reflect the majority of the games produced by the community on this site. Granted there are games that are made by community members here that enjoyed the dark color scheme to reflect the dull and muted colors of their game. Well those games generally don't seem to be gaining much interest anyway (case in point a recent popular commercial release which has made very little proft).
Game design isn't just about game programming. Just because the color scheme of the website doesn't match the lighting scheme of the parents' basements that some community members reside in, that doesn't mean its inherintly bad. We all know programmers are often lulled into a comfort zone and are generally unwilling to accept change. Some times they just need to be shaken up.
So yes, I approve of the new layout.
P.S. Happy Thanksgiving everyone!
Yeah I know I've been delinquent with the entries. Selling rocks all day was taking a lot of my time. But luckily my last day was Tuesday, so I know have some good chunks of time to get some stuff done on the game before school starts. I'm going to do my best to update on a regular basis from now on in order to motivate myself into progressing more and more.
Now for those of you who are curious, my position was as a Masonry Salesman for a retail building supply company. Hence, I sold rocks. I can honestly say that what I've learned from my experience is that retail sucks, especially when you don't work on commission. Ahh well, that's all behind me now (hopefully).
So far today I've been focusing on adding combat abilities to the entities of the game. I got through a few before I realized that I needed to at least stub out other objects in order to make my logic work right. Ahh the Love/Hate relationship I hold with OO programming. After a short break, I'm going to dive back in and fix the mess I've created.