About this blog
Sprawling text for ocular consumption written by a hobbyist game developer.
Entries in this blog
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.
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:
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.
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.
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.
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.
Level editor is mostly working now. Just need to get saving and loading done, which will be added fairly easily. Here's a shiny screenshot.
Well we are officially entering crunch time for Tuss Toss. The game has 1.5 months to be nearly feature complete. Then comes about 3-4 weeks of testing and polishing. When this is done, we release to the public by entering the Guerilla Gamemaking Competition for Slamdance. Sounds all well and good, like I actually have a plan or something. The downside is that being so busy, I won't be able to enter 4e5 this year, and after being out of 4e4 this is a real dissapointment. Ah well, maybe I will have time later for a small/fun entry. But I'm not even letting myself think about that until Tuss Toss is done.
Next up is adding in the new wildcard block, and brick gibs for wall explosions.
THE BURGER VORTEX IS HERE TO SAVE YOU!
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.
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. :).
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.
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.
Just a quick update to keep myself in the posting habit. Work on Tuss Toss is continuing, at a slightly slower pace while some graphics content is being produced.
Meanwhile I've started a small side project. Basically its a system that procedurally generates NPC's through the use of evolutionary and genetic algorithms. I'm naming the system "MEGEA" for Massive Entity Generation with Evolutionary Algorithms, at least for now. Code is being written in C++ with a strong emphasis on Object Oriented programming concepts. I will include a small graphical harness/game with the project is complete. I plan on using OpenGL for renedering and hope to make Linux/MacOS variants along with a Win32 release.
I want to start a side project (which will end up being my main project). I am stuck with the age old developer question: "What Language and API do I want to use?"
Details regarding the project:
1) It will use a 3D perspective.
2) I may plan to sell it, or at least make it commercial quality.
3) This will be a main portfolio piece, showcasing my best work as a designer and developer.
4) I would like to complete it in a year.
Things about me:
1) I am proficient with C/C++, C#, and Java.
2) I like object oriented programming.
3) I am confortable with Managed DirectX, I have used a moderate amount of unmanaged DirectX. I have never used OpenGL.
1) I would like to port the game to other OS platforms if possible, but finishing the project on time is more important.
2) I have had some recent disappointing realizations of Vista, and have recently started using Linux (but still mostly Windows), thus spurring some desire to learn and use OpenGL.
3) Being infatuated with OO programming, OpenGL's syntax is a little "ugly" to me.
4) I love C#, but I have desires to port my work, and since most professional studio jobs I see require a display of C++ skills, this makes me want to use C++.
Any suggestions are welcome...please. I'm looking for some divine inspiration here! [lol]
Phase two of Tuss Toss 1.1 is complete! This means that I have the game built to a playable state again. I have already made some changes to speed up the gameplay, and they feel great.
Now we are on phase 3. This phase consists of basically adding in two new blocks that weren't in version 1.0. These will be a wildcard type block, and a transporter block that swaps the horizontals and verticals with one another. New art and game logic will need to be created. This also includes effects and animtations.
Finally in other news, today was my first day back from spring break. I tons of work due in the next two weeks, and my head is starting to spin. From employing the A * algorithm to a quake 2 bot, and loading/starting user processes in geekos, I think I'm gonna lose it O_o.
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.
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.
Well on a personal note, the spring semesters starts monday here at URI. I'm taking three courses: Advanced Programming Concepts, Operating Systems and Networking, and Artificial Intelligence. I'm looking forward to the AI class the most. The professor holds a doctorate from Oxford and is super-duper smart. He is teaching us by basically stripping down Quake II AI and implementing our own while learning about popular AI techniques. I'm really gonna learn a lot and can't wait.
In other news TussToss v1.1 has reached its first milestone and is on to phase 2. The purpose of phase two is to basically get the game to a basic working state. That means implementing logic, scorekeeping, timing and a very basic particle generator. It'll be nice to have the game up and working again so we can add the finer points of our remake. Till next time folks, and thanks for reading.
I can now draw blocks again, so nearly everything rendering wise is back to normal. Here's a shot:
Next (and the final part of the first phase) is to draw the tusses animating in their burst effect.
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.
Finals are over, time to work on stuff I actually want to work on!
One of the major issues with Tuss Toss was that we didn't use any sort of font engine. Since we didn't need to dynamicly draw any text on screen, we simply made bitmaps of the words we used and then copied them to the screen. This was a very poor idea in hind sight and has been our first step towards something better.
This shows the new text drawing abilities that we made. Now first thing that I should note is that DirectX offers some great API calls for drawing text. However, you can see that the game's fon't really couldn't be handled by the basic text drawing methods. Instead we created the entire fontmap and copied it to a texture. Now we use the Direct3DX sprite interface to draw things in 2D or 3D. Text can be scaled, rotated and have its alpha value manipulated. Also, because the 2D graphics are not drawn pretransformed in 2D space, things can actually fly towards the camera at the player for some neat effects.
Creating a font engine really doesn't take that much time and will really improve Tuss Toss.
Delphi was way out of the scope of something that I could and should be working on, and a friend really helped me realize that. So isntead we are working on a new version of our original game, Tuss Toss.
The lowdown: Being programmed in C# with MDX as the graphic, sound and input API of choice. The old game used C++/DirectX also, but the graphics used DirectDraw. Now we are updating to Direct3D for its obvious benefits. Some new features are going to be added that we had originally included in our design. These include some new blocks, some new graphical features, and the ability to create custom levels.
The work has been broken down into 8 phases. We are currently well on our way into the first: Content conversion. This basically is a phase where we take all the art my partner made and convert it into dimensions that can be used for textures.
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!