About this blog
Air Force Academy adventures inside!
Entries in this blog
Hey everyone, it has been quite some time since I last posted a journal entry, but if you thought that I've just been sitting on my laurels and not doing any game programming, well you'd be almost completely right...
As every hobbyist game developer has experienced, real life often fails to be very conducive to any game programming or developing, and the past year has been no exception for me. But I'm sure no one really wants to know all the details, they just want to see the progress that Prinz Eugn and I have been (slowly) making on our latest project, so without further adieu...
Given our busy RL schedules, Prinz Eugn and I decided from the start that A2X would be a long term project with limited scope. We really just wanted to make a fun little game with one or two levels so we could do all the cool things that never made it into our previous games. We're well on our way to accomplishing that goal, and its about time we released some sort of demo in order to see how playable it actually is, and (more importantly) how well it runs on other computers. We're titling the release "Angels 2X: Block Zero", after the naming convention used by the U.S. military for its combat aircraft. "Block numbers" can are essentially the military aviation equivalent of a version number (ie. F-16C Block 52 is more modern than an F-16C Block 32). So A2X: Block Zero represent the very first public iteration of the game.
What's in it?
Block Zero represents the bare bones of the engine, and we're using it to gauge the performance of the new game on other machines before we get too far ahead of ourselves. You can expect:
1. A flyable airplane
2. 4+ weapons to test (from guns to guided missiles)
3. One level to do with as you please
4. Rudimentary enemies to destroy
5. Destroyable structures (Collapsing skyscrapers, tool sheds, etc.)
6. One Fire Support unit (B-52 strike)
What's NOT in it?
There's plenty of stuff left on our to-do list before we reach "Block 1", but its all subject to change based on RL and whatnot, but here's what we'd like to have in the game before we make our first "official" release.
1. More offensive units (ie. Surface to Air Missiles, Flak, Tanks, etc)
2. Full mission scripting
3. More player weapons
4. You get the idea....
When can we expect it?
While the game is pretty much in the state we need it to be in, there is still a few things that need to be done before we push it out the door, like a rudimentary menu. These should hopefully be done in a week or two, so hopefully we'll have it out there by then...
Now that that's out of the way, here's a few cool things you can look forward to once we put the finishing touches on Block Zero:
Anyone who played Command and Conquer will recognize the smoke markers that we put into A2X. They are fired as rockets, but upon striking the ground, they begin emitting colored smoke rather than explode. This seems pretty useless... until the B-52 flies over the marked location and bombs it back into the stone age....
Innocent Orange Smoke...
Pretty much everything in the game can be destroyed, and the larger buildings blow up real gude...
Go really fast
We tried to bring all the cool parts of flying fighter jets (everything?) into A2X, and that includes going reaalllly fast and seeing the compression waves:
As you can see, even though the game is pretty bare bones, there's still a ton of stuff to do, and hopefully you guys'll have fun with it and it won't break too bad...
Well thats all for now, I'll try and keep you guys updated on the progress as we get closer to letting you guys play with our baby...
Sorry for the lack of updates, life has been kinda busy lately!
I've been working on Axis Shift (or Space Strategy Game(SSG) as I've been calling it...) as much as I can, but unfortunately, that equates to about a half an hour every night before I go to sleep, so progress has been slower than I would like. Anyways, I do have some updates for you guys, and I'll try and lay out how we're going to do some of the more complicated stuff in the game.
Space Debris: The Visual Side
Since every good Turn Based Strategy game has some form of terrain, we decided we needed to have some sort of "terrain" system for the space combat of "Axis Shift: For Realz This Time". Since the entire game takes place in space, asteroids were the prime choice for creating obstacles to the ships in the game.
Implementing the asteroids was as easy as adding an attribute to the Tile class that specified whether it had asteroids or not, and the concentration of them. Making them visually appealing on the other hand was not as easy. Even though the game is tilebased, making something like an asteroid field look random enough using static tiles would be a pain in the ass, so we took a different approach. Mark drew up a few asteroid sprites, and whenever a tile is generated that contains asteroids, it also creates a certain number of random asteroids with random sizes and spin. This creates a very random looking field of space debris that moves and looks quite realistic.
Here's a picture of my initial asteroid test using my own asteroid sprite.
And here's how it looks now that Mark has contributed his half of the equation:
AI: Part One
The AI in this game is going to be the hardest component to get right, as we've never really dealt with AI that had to think that far ahead before.
The plan for the AI in SSG is that the AI will be split up into different levels. The highest level is the Strategic Level, where the general guidelines for what the AI ship's goals will be.
The Strategic AI doesn't specifically tell the Ships what to do, it pretty much looks at the aggregate situation and decides stuff like what targets get what priority rather than "Tell Ship X to attack Ship Y". If the Strategic AI can't see any targets, it will look at where it's ships are situated, and based on what direction the last enemy ship was spotted, give out a general search command in that direction hoping to find the enemy fleet.
A neat feature of the Strategic AI is that it gives directives to each type of ship. For example, When a general search directive towards the bottom of the map is given, only Light Ships will listen to the command. This prevents Carriers and Battleships from going off on their own without support and getting pounced on as they blindly search for the enemy fleet. Instead, Destroyers and Fighters will search for the enemy fleet while the Capital Ships obey their own directives. Alternatively, if the directive given is "Destroy all Enemy Fighters", a Carrier or Battleship wont directly seek out and engage, instead leaving that task for the Destroyers and Fighters.
So while the Strategic AI gives out general Rules of Engagement, the next tier down is the Tactical AI, which is what tells each ship how to move and what to do, but thats a subject for another update....[wink]
Random Academy Paragraph
I've decided that this paragraph will focus on the better aspects of the Academy rather than the shit we have to put up with[grin] One of the coolest things we have happen here are the random flyovers that occur every week or so during out noon meal formations. So far we've had a few F-16's, A KC-135(boring!), and a few C-17's. We even had two huge special forces helicopters (MH-53's for the curious) land in our courtyard, and the Spec Ops guys ate lunch with us(They were certified badasses...) Another pretty emotional experience was during the Air Force's birthday parade. The entire Cadet Wing formed up outside, and the Commandant of the Academy called out the names of every graduate who has died in the line of duty. After he called a name, the current Squadron Commander of the Cadet Squadron the person was in while they were at the Academy would respond "Absent Sir!". The ceremony lasted about an hour, and finished with a four airplane flight of F-16s that performed a missing man formation in honor of the fallen. Its a good way to get reminded of why you're going through all the shit involved with this place...
Well guys, I should have another update sometime soon! Peace Out!
The New Project
So my new project is pretty much a simpler version of what Axis Shift was supposed to be. Axis Shift was going to be a Turn Based Space Strategy Game where you commanded fleets of ships and complete various missions while managing your empire's economy on a galactic scale. It was pretty ambitious, and although we got really far into development, the sheer mass of work involved pretty much doomed the project to failure.
Well this time we're trying to keep it simple, so hopefully it will get done this time!
For the second go at Axis Shift, we're limiting our ship types to 5 main classes.
Battleships- Big,slow, and powerful, but has the largest firing range out of all the classes
Cruisers- A sort of intermediate battleship, a better balance between movement range and firing range.
Destroyers- Fast and powerful, but has to get really close to do any damage
Fighters- Long ranged and difficult to counter except with other fighters
Carriers- Weak attacks, but carries fighter squadrons to do its dirty work
Balancing the classes is going to be pretty dificult, but Eugn's going to post about that later in depth, so I'll let him do the explaining (He's been doing his research[wink]).
Mark "threw together" this new Banner for the new Axis Shift, and I must say it looks pretty cool. He's particularly proud of the explosion, and I cant argue with him!
Random Academy Paragraph
Some of the courses we had to do in Jack's Valley were pretty cool. One of the better ones we did was called "Ops Warrior", where we were taught how to fire, clean, and maintain an M-16 rifle, then we were handed real M-16's with blank cartridges, split up into two teams and then proceeded to have wargames the rest of the day. It was tiring, but totally worth the experience. I also managed to qualify as an "expert marksman" in the Air Force by hitting 35 out of 40 targets at 300 yards with iron sights. It was a good time.
On the other end of the fun spectrum was the "Assault Course", which is essentially a 3 hour long beat session, only you're running uphill with barbed wire and smoke grenades going off... They give you a fake M-16 and a helmet, and you have to run through this course doing a series of ridiculous things, like low crawling through a huge puddle of muddy water ( "Oh, you got your gun wet in the puddle? Guess what, you have to go back to the start of course!"). And the worst part was that even if you completed all of the obstacles, you had to start over again until they told us to stop (3 hours into it). But for all of the pain involved, finishing that course was probably the best feeling I've ever had. At the beginning of the course they make you read this sign that says "Only the strong will survive...", and at the end, they make you jump over this wall and read the sign at the end that says "Only the strong survived..." It felt good to read that[grin].
Well thats all I've got for now, hopefully Eugn will put up an entry soon that goes into more detail about how the game will be played. Peace Out!
It seems to be homecoming time for GameDev lately, because not only is this my first post here since going off to the Air Force Academy, but fellow dev Hopedagger has also returned to Journal Land!
So I pretty much have a lot of stuff to talk about, so let's get on with it shall we?
So as some of you may remember, I was accepted into the United States Air Force Academy this year, which is the first item on a long checklist that eventually leads to me becoming a fighter pilot. Anyways, I was pretty sure that I wasn't going to have any time to be screwing around on a computer programming games given how busy we are with all the academics, athletics, and physical fitness stuff we have to do. Well, I've found myself being drawn back into the black world of game development. Being a cadet at a military academy is probably one of the most stressful ways to do the whole college thing, and I found that coding at the end of a stressful day(we have plenty of those) really helps me to unwind and relax. Maybe it's just because it reminds me of the good old days when Eugn and I would spend 3 hours a day designing our next grandiose game project. In any case, it looks like I can't escape the coding bug, which means more game programming exploits for you guys to read!
So since I spent a vast majority of my days standing at attention staring at nothing, I had nothing better to do than design a game in my head. I decided that I didn't want to do another Angels 22-esque game, and I knew that the laptops they were going to issue us weren't going to be the greatest machines, so I settled on a Turn Based Strategy game. Some of you guys might remember Eugn and I's prior turn based strategy attempt, Axis Shift.... or maybe you don't.... in any case, it was way too ambitious of a project for us to complete, and it fell apart a few months into development. Well, I feel like revisiting the Axis Shift idea, except with a far more limited scope. I'll be posting another update in a day or two that details what the game will be all about, but until now, you'll have to be content with this screen:
Random Academy Paragraph of the Day
So the last few months of my life have been packed full of weird stuff that I'd like to convey to you guys, but in an attempt to prevent this from becoming my personal blog of RL happenings, I'm going to limit my storytelling to one paragraph per update, we'll see how it works out:
But yeah, so Basic Training sucked.... A lot. The first day there was probably the worst day of my life. They woke us up at 4:00 in the morning (or 0400 [wink]), and kicked our doors in, while blaring "Welcome to the Jungle" over the loud speakers in our dorms. We then proceeded to get "beat", which is their little code word for a ridiculous amount of pushups and leglifts. Then we we'd go to breakfast, get beat some more, practice marching, get beat, go to briefings on military stuff, get beat again, and eventually go to sleep at 9:00 that night. That pretty much sums up the first month I spent at the Academy. The last half of Basic Training took place in this hell hole called "Jack's Valley", where we marched 7 miles just to get there, then set up a tent city and lived there for 14 days, running a plethora of hellish obstacle courses, and... getting beat (sensing a trend?). Tune in next update to find out what crazy shit we did in Jack's Valley!
Well, it's getting pretty late here and I have an early start tomorrow (as always...), so I'm going to have get to sleep. It's great to be back at GDNet, and hopefully I haven't lost all my game developing skills over the past 2 months! Peace Out!
So the RL has been pretty exciting for me lately. As some of you may remember (or have deduced), I have an interest in military aviation and want to become a fighter pilot when I graduate college. Well, it looks like I'll be getting my wish if everything goes according to plan, because I was recently accepted into the United States Air Force Academy. That was probably one of the biggest hurdles on the road to becoming a military pilot, so I'm pretty excited about the whole deal[grin] Unfortunately, this means I wont be able to devote much time at all to game development... at all. I have 6 weeks off the entire year, and the rest of the time I'll most likely be up to my eyeballs in work. So it really pains me to say that I will most likely not be participating in the forums or journal land any more after June 26th when I report in...
That Flying Game...
So Mark and I had this grand scheme to complete one level of Angels 2X to release before I had to go to the Academy, unfortunately, life got in the way and we weren't able to finish it. I gave Mark all the source code and executables, and he's probably going to just give it away to whoever wants it. It's not the prettiest thing in the world, but it works...
Anyways, thanks to everyone in the forums and journal land who helped me along over the years, GDNet has been the only forum I regularly visited and felt like an active member in, and I'm really going to miss browsing through it every day.
BTW, since I'll be leaving I unlocked the chain tying Mark to our projects, so quick spam him with requests to draw pretty piktars for your project, they'll make even the crappiest game 100x better(See Angels 22...)!!!!!!
Peace out guys.
Arguably the most important element in any Angels __ game is the badass jet you get to fly. I put off implementing the airplane in A2X because I wanted to focus on the background stuff for awhile rather than making the game fun to play. Well, I finally ran out of stuff I could realistically do without a player object, so I bit the bullet and made the Airplane object.
I had this hardcore advanced flight model thing planned out, I'm talking angle of attack, instantaneous pitch rate, post-stall maneuvering, stuff like that. Well, I haven't implemented that stuff yet, because it's going to take some hardcore testing to get right, and I dont want to deal with that right now, so the airplane just runs on the A22 style flight model (ie. flys the direction it points). This is good because it lets us play the game without having to debug the flight model as we go along, and it'll make a good "Novice Mode" for people who have trouble with the advanced model.
This was a feature I wanted to implement in Angels 22, but by the time I got around to doing it I had coded myself into a corner, and it wasn't going to work. Well, following the current trend of "getting it right this time", I implemented this early, and it's pretty cool. At the beginning of a level, you can opt to record the session for later review.
The way it works is that when you start recording, the game keeps track of the buttons you pressed every frame, and the time step that was used to update all the actors that frame. Also, a couple times a second, the players' position and velocity is saved, which sets the replay to where it's supposed to be, just in case it starts to diverge after awhile. I haven't tested it with a whole level yet, because we currently lack all the stuff that's going to be in a whole level, but it seems to be working just fine.
I went a different direction in the level structure for A2X than I did with A22. The Angels 22 system was pretty shoddy, with all the level and object information packed into one complicated text file that became more and more unmanageable as we added features. In A2X, I split up all the aspects of the level into 4 sections, each of them saved in their own file, then spliced together when loading a level:
This is pretty self explanatory, its just the heightmap, bodies of water, weather effects, etc, that make up the landscape the level takes place on.
This is the information for all the objects that exist in the level, such as Trees, Flak Units, Airplanes, etc. This is also where current game data is saved for features such as checkpoints and whatnot.
This is where all the scripting for the level is saved, stuff like spawning special enemies and determining win conditions. Stuff like that.
This is where the 3 other elements are all put together. Essentially it's how the game knows what files are used for the level.
Using Angels 22 as a model, I implemented simple scripting in A2X in about a days time. It still uses the Trigger-Action setup that A22 used, but with a few small tweaks to make it easier to use for the non-programmer level designer(Mark).
I wrote a pretty good overview of the A22 scripting system in an older post in my journal, so you guys can check that out if you'd like, the A2X system is mainly different internally.
Pretty much, every script element was hardcoded into Angels 22, including what variables existed for each trigger/action, which caused many a crash. The A2X system has a library of all the action and trigger commands, with a list of what variables to look for, which makes for a much easier to maintain system.
Mark and I are putting together a little movie to showcase how awesome A2X will be. Mark is in charge of editing and narration, so it should be pretty good.
Alright, thats all for now, it's time for some Halo 3, Peace Out!
Despite my lack of journal updates, I've been doing quite a bit of work on Angels 2X.
So after getting the terrain finally working the way I wanted to, I needed something to decorate it with. I decided to implement trees as the first objects in the game because they're technically the simplest ones, and because it's tradition. Trees were the first object I implemented in Angels 22 and I would wager they were the first non-flat tile for Angels 20, so it's only fitting they were in there first for A2X.
The trees in A2X are pretty much the same as the trees in Angels 22, except that they can be knocked down instead of just caught on fire. So now depending on what weapon they are hit with, trees will either catch on fire, get knocked over, or both. This results in a cool effect, with explosions blowing down trees on either side of them, and burning the trees within a certain radius. It's pretty neat to see in action, but until I make a video of it, screenies are just going to have to do:
Trees just sitting there:
Trees knocked down:
This was a late addition to Angels 22, and it added so much "oomph" to the explosions. I recently implemented screen shake in A22, so explosion and whatnot can rock the screen back and forth. Once again, hard to show in a screen shot, but in the up coming video, you'll see what I'm talking about...
One night Mark and I were screwing around in the A2X editor and we realized we were making our own sound effects for when the explosions went off. Soon after, I had imported the old Angels 22 sound system to A2X, and we had actual explosion sounds going off. So yeah, sound now...
I'm pretty proud of how well this turned out for how much effort I ended up putting into it. For Angels 22 the water was a simple gradiented rectangle drawn on top of the terrain. I always wanted to have a better system, but I was never able to figure out how to do good, simple 2D water. Well after playing a few 2D indie games I decided on a good system, and got to work implementing it.
It's pretty simple, essentially there's a mini dynamic heightmap, with each of the points on the map moving independent of each other. It was really easy to implement, and it looks pretty good IMO. Another improvement over the A22 system is making the water into an actual object, so we can have many different bodies of water on one map. Also, all the aspects of the water is modifiable as well, such as the max wave height and the roughness.
This was a big priority of mine. Getting proper Save/Load stuff working was a real pain in Angels 22, but with that experience in mind, the A2X system is much better. It still uses the A22-style text files, but the A2X system has one huge improvement that I call "Special Data". In Angels 22, all the objects were saved with only 4 variables, their class, type, xposition, and yposition. As you can probably guess, this really limited what kind of stuff could actually be saved. In A2X, the same 4 basic variables are saved, but there is the option to use "Special Data" to fill in the blanks on more complicated objects.
For example, the tree objects have many internal variables that dictate their outward appearance. An example would be "STUMP", meaning the tree has been cut down. By using the "Special Data" system, the game can save the specific state of the tree, so that when the level is reloaded, the tree looks the same as it did when saved.
The whole system is probably sounds really wierd to all you XML folks out there, but it works well, and I learned alot from making it.
These little objects are pretty simple, and were the second actor type I created. They exist in two states, alive and dead, so it was pretty simple to code them. The closest A22 equivalent for these objects are the old buildings. They have multiple damage states, and they transition instantly from one to the other. This works well for the smaller objects, such as sheds and whatnot, but for larger buildings and structures, a better system is required, but thats for another journal entry[wink]
Using my surprisingly flexible particle system, I was able to make pretty good looking fire using the same textures that are used for the explosions. A simple overlap of smoke and flame emitters with different lifespans and fade rates resulted in a pretty good looking effect. I'm sure they'll start to look better once Mark makes me some actual fire textures, but until then, I think this will do....
Well, thats all I have time to write down for now, I have a long plane ride tomorrow, so I'm sure I'll get some more work done then. As always, comments/questions are welcome. Peace Out!
It's been awhile since my last update, but don't worry, I've been making crazy good progress on A2X, and hopefully we'll have a demo of some sort for you guys to try out soon.
Data Driven Stuff
One of the most important lessons I took out of the whole Angels 22 experience was the importance of data driven programming. There was so much stuff in the A22 Engine that was hard coded, and therefore a bitch to modify late in the development cycle. Since I got to start off new for Angels 2X, I made it a point to not make anything hard coded, and to have almost every little bit of data accessible from outside the program. So far it's been working out pretty well, and I'm sure I'll be happy I did it once we start coming up with cool ideas months from now.
This was one of my first priorities for the new A2X engine, as the particle system in Angels 22 wasn't very good, and you can do lots of neat stuff with really simple particles. Anyways, I learned from my A22 experience, and I knew exactly what I wanted in the particle system, which was a lot of variables to screw with, but making it easy to use in game.
The problem with Angels 22 particles was that they were all generated on the fly, so in order to make a new particle emitter, you needed to call this incredibly complex function with around 10 parameters for stuff like "particle sprite" and "gravity value". Well in the new engine, you create particle emitter types once, and then you can just create new instances of the same type. For example, once you come up with a combination of values that makes the particle effect you want, you just save the emitter, name it, and voila, what was a complex function call becomes a simple:
new ParticleEmitter(xpos, ypos, "EMITTERNAME");
Fitting in with the new data driven approach for the engine, all the definitions for the emitters is defined in an external definition file, so no more endless recompiles for me!
In Angels 22, explosions were just an 8 frame animation that Mark drew up, which meant that all the explosions looked the exact same. Well, this time we wanted to make a more robust and realistic system that would at least have a somewhat random appearance. After studying how some of our favorite games did explosions, we decided that the best way to make a good looking explosion was with rapidly expanding (and short lived) fireball sprites with overlaying smoke that lingered and drifted after the fireball disappeared. Luckily, thanks to the thought I put into designing the particle system, we were able to easily utilize the particle emitters to get the effect we wanted. A series of slightly offset particle emitters and some good artist-ing from Mark resulted in a pretty good little system that met all our initial goals. A nice by product of not using premade sprites is that by simple increasing the potential offset and number of particle emitters in an explosion, we can effectively scale the system up to whatever size explosion we need.
In the process of our research, we also realized that one of the coolest parts of any explosion is the visible shockwave you can see when the explosion takes place in humid areas. We decided that we needed to somehow simulate these shockwaves. Luckily, it wasn't that hard, a simple circle texture that quickly expands and fades out around the explosion gave the effect we wanted.
Unfortunately, not much of the explosion stuff looks that good in screenshot form, so you guys'll have to wait a while to see it in action. Until then, here's a good screeny of an explosion and the shockwave around it....
One of my favorite features of Angels 22 was the in-game level editor that allowed you to screw with stuff in real time while you played the game. That's a feature I wanted to carry over into A2X, but I decided the GUI system needed an overhaul, as the A22 system was kinda clunky. So what better thing to base a new UI off of than the system you're using the make the game itself? I decided to go with a Windows style "window" system that uses a series of collapsable menus to manipulate the level. The new system was kind of a bitch to get working, but it's really working out, as it is really easy to add new buttons and features to the system itself, in addition to the level. Anyways, here's a screenshot of the menus in their expanded and collapsed form.
Alright, it's hella later here, and I've got an early start tomorrow. I've got quite a few more topics to talk about, so I'm sure I'll be posting sometime in the near future with some more good screenshots. Peace Out!
So I finally got some spare time to work on Angels 2X, and I must say, after a few days of work, I'm having trouble getting away from the computer. Game Dev is addicting.....
As many of you may remember, the terrain system in Angels 22 was useful in scenarios with gently rolling hills and smooth elevation changes. Well, we wanted to be able to do more stuff with the terrain, so making the terrain work better is the first thing on my list of stuff to do for A2X. Accordingly, the new terrain engine has been what I've been working on for the past couple of days. It's still a 2D heightmap, but with a much higher resolution (ie. smaller spaces between elevation points), which lets us make much more drastic elevation changes without looking too angular. The higher resolution, along with a few other tricks Mark and I have come up with, makes the new system much easier to work with than in A22.
The New Engine
For Angels 2X, I've completely wiped the slate clean. I'm starting completely new and only using the A22 code as reference for how I did it "back in the day". Among the benefits of this approach is that I can apply the stuff I learned during the development of A22, but couldn't implement in the middle of the project.
The most obvious change in A2X will be the new camera system. In A22, the whole game was done in OGL's orthographic mode, which meant that zooming in and out easily was out of the question. The A2X engine on the other hand allows zooming in and out, which is handy in many situations. If anyone reading this ever played the original Angels 20, they'll recognize the zooming feature we're talking about. As you gain altitude, the camera zooms out, allowing you to still see the terrain, where in A22, you'd essentially be blind. The new camera system also allows for some cool cinematic effects, but I think I'm getting ahead of myself.....
Another new feature of the A2X engine is the inclusion of a "skybox" texture that acts as distant wallpaper to make the background of the level more interesting. In Angels 22 the sky was just a simple solid color, so you can see how this is quite the jump forwards. This feature also has some cool implications, as Mark and work his magic with the background and hopefully get some cool stuff going on back there.
Here's some screenys I took today to document the progress on the engine. Keep in mind this is about the 3rd day of actual development, and most of the textures are stand-ins or old A22 textures.
This screenshot shows of the drastic elevation changes that can happen now, this will be about the standard zoom for flying near the surface. You can see the big poofy clouds in this screeny too, which are left overs from Angels 22, just scaled up really big. Note the gradient in the sky, the entire background is a texture that Mark made up, so we can have pretty much whatever we want back there.
This is a screen of the same level, just zoomed out really far to demonstrate the zooming capability of the engine. I really like this one because of how the clouds look. Unfortunately, the poor quality of the terrain texture really shows here.
This shot is zoomed up really close to the terrain. You can see the grass placed on top of the terrain, just like in A22.
The Next Step
My next task is going to be encapsulating all that I've written so far, and getting rid of all my prototyping code. After that, its time to get some objects in there, I'm wary to start putting in Actors too early before we really decide on a final design doc for the game.
Well, thats all I've got for right now. Unfortunately, I have my first round of finals next week, so this might be the last post for at least a week, because those will probably take up quite a bit of my time. Questions? Comments? Feel free to ask[wink]
It's nice to finally have the time and means to get back into the Gamedev groove!
As many of you may remember, I was trying to go to the U.S. Air Force Academy for college, until I was temporarily medically disqualified for heartburn. Well, I'm now spending at least a year at New Mexico Tech and reapplying to the Academy this year, as I've been hella busy doing school work and whatnot, which is part of the reason I was out of the GDNet circuit for awhile there. Well, now I'm getting into the groove of things, so hopefully I'll be able to spend more time gamedev-ing and writing journal entries!
I'm really liking the whole college thing, being out on my own is kinda nice, and so far I've been doing alright for myself schoolwise. Unfortunately, the male/female ratio at my school is abysmally low, which really starts to hit you after the first month or two...
Well, my homebuilt machine finally kicked the bucket a week or two into my first college semester, so I was computer-less for quite some time, which really sucked ass, and was definitely a contributing factor to my complete lack of coding for a couple months. Another downside of the loss of the computer was that I essentially lost access to all the code for FoT and A22, and until I get the motivation to pull out the hard drive and plug it into another computer to get the stuff I need off, I'm kinda out of luck. Luckily I was able to get a pretty pimpin' new lappy, which makes me happy!
If any of you guys read Mark the Artist journal lately, you'd know that in light of recent events and revelations, we're changing up the game plan for the Angels XX series of experiments. We came to the conclusion that we just dont have the spare time or the resources to make a complete game, and still have it live up to the standards we want. So now instead of making a complete game, we're going to focus on making a 3 level "tech demo" that includes all the popular features from Angels 22, but without the ambitious attempt at making it all fit together with a complex storyline and 20+ levels. This doesn't mean that we're planning on making only three levels and then forgetting about the game, just that our initial goal is to make three well crafted levels to show off the good parts of the game concept. In fact, the plan is to implement a .WAD-esque package file that includes all the level information and whatnot, so we could essentially release "expansion packs" if the concept really takes off.
A nice side effect of my old computer dying is that I now have to start coding essentially from scratch, and that I wont be tempted to use dated and crappy modules from Angels 22 to speed things up.
My short term goals for the A2X project right now is to make a better terrain system. The old one was okay for most situations, but it had inherent flaws that made it hard to use for levels that didn't include gently rolling hills and no abrupt changes in elevation. I'm planning on starting to code a terrain prototype pretty soon here, so check back often and hopefully I'll have a few screenies for you guys.
So my friend and I flew a Cessna 172 up to Albuquerque a few weekends ago to hang out with some friends of mine. After spending the night, we returned to where we parked the airplane the day before. Much to our surprise (and my delight), there was an F/A-18F Super Hornet parked next to our little Cessna, which was extremely badass, as the Super Hornet is one of my personal favorites, and I'd never seen one up close before. Anyways, here's a picture of the jet next to our little plane (you can see it's nose in the bottom right corner of the pic). I dunno, I just thought it was cool...
Dragon88 requested that I elaborate on my side project, and I am happy to oblige.....
Well, this is actually the first time that I've attempted to code a modular physics system, so hopefully it doesn't show[wink] In our new project, every collidable object has a "CollisionMesh" object which essentially outlines the areas of the object that can be collided with. The CollisionMesh is formed from one or more "Polygon2D" objects, which in turn are formed by a series of "Line2D" objects, which are made by two "Vector2D" objects.
In order to test for a collision, each vertex of the CollisionMesh is tested to see if it's inside the other CollisionMesh polygon we're testing against. In order to do this, I used the Crossings Test to determine if any of the vertices are inside.
This is a pretty simple task, as all that is required is for you to cast a long ray from the vertex you are testing in any direction, and see how many sides of the CollisionMesh it intersects. If the number of intersections is odd, then the point is inside the polygon, and if the number is even, you are outside the polygon, as seen in my handy diagram below:
There are also a few other functions used to determine which "Line2D" you collided with in order to find its normal vector and whatnot, but thats basically how everything works. I'm considering cleaning up the code and posting it in here, because I remember having a hell of a time getting any sort of collision detection working when I was first learning.
In my next entry, I'll detail how my (crappy) messaging system works! Peace Out!
Lots of ground to cover today, so lets get started!
Fortess of Terror!!
Well, FoT is slowly steaming ahead, although I just wish the thing would finish itself overnight, because I'm getting kinda tired of the concept, and I'm excited for our next project. Since my last update I've been pretty much adding boring functionality to the game, such as a main menu (which looks kickass thanks to Mark), and making the inventory function as advertised.
The game is really reduced from its original concept, which was to make a good shooter with kickass randomly generated maps. It has now evolved into a fun shooter with extrememly boring randomly generated maps. Mark and I just couldn't come up with that many types of tiles, without having to make an entire different tileset for different room types. The functionality for multiple tilesets is in the game already, we(Read: Mark) just don't want to spend the extra time drawing all the stuff, but if someone really wanted to, they could draw their own, modify a few config files, and have them be in the game.
So yeah, the game is pretty much almost done, I just need to make the enemies a little bit smarter, and add a few things.
The Next Project
As you may have read in Mark's journal, Dogfight Online is out of the question for now, so we sat down today and thought up what other games we wanted to make. We eventually settled on a topdown sandbox-gameplay space shooter. I realized today that every project post-A22 has been essentially one of Ravuya's ideas, just a few months later[wink] Mark's much better at conveying game concepts than me, so I'll just let him cook up a huge entry to explain what the new project will be like....
My Side Project
Ever since we were working on the original Axis Shift game, I've been using the same rendering, animation, and texture atlas code. The system still works pretty well for small projects, but once the textures start piling on, it gets really messy to get stuff done. So I decided that before I began hardcore coding of our next project, I was going to go in and clean up all that old code. Well, my "cleaning up" resulted in the complete rewrite my old system, and I didn't stop there, I began coding up a bunch of modular classes for stuff that I always wanted to have in my projects. So far I've written 4 modules:
-An HTML Logger
-A New Texture Manager
-A Small Polygon Collision Detection System (gonna come in handy later)
All these modules are going to come in crazy handy when we start making our new game, which we don't even have a codename for[grin] Hopefully all the modules will be easy to use, and maybe I can even compile a library for public use....
Well, thats all for now, Here's a random screenshot from FoT to keep you guys satisfied, Peace Out!
I don't any time to write anything, but I think this screenshot sums up what I did today...
Sorry for the lack of content, in my next update I'll talk about how the networking is going to work (just for you HopeDagger[wink]) Peace Out!
EDIT: Changed the journal title to get Ravuya off my back[wink]
Sorry, not that big of an update tonight, its pretty late, and I've got an early start tomorrow.
I've been working pretty regularly on FoT, and I'm making some good progress in terms of putting items and weapons in the game. One of the limits Mark and I put on ourselves at the beginning of the project was that we were only going to have a few weapons, basically your standard FPS set:
Having such a small amount of weapons allows us to balance them much easier, and make the game a lot more fun to play. Anyways, Mark recently sent me a bunch of neat new textures to help fill out the inventory display. As you may remember, the inventory had a huge black rectangle that was curiously empty, well no more!
In the screeny above you may have noticed that now the player has a health readout, which actually works, although Mark has yet to give me a dying player texture, so until then, there's no actual "dying".
This is a cool feature that I really enjoy in the games I play, alternate fire modes for weapons. Almost every weapon in the game will have a unique secondary fire that can be used by clicking the right mouse button. For example, with the assault rifle, your primary fire is a 3-round burst of bullets, but the alternate fire launches a grenade out of the gun that detonates where you had the cursor when you fired it. Hopefully cool little things like that will help differentiate the weapons and make things more fun.
A genius idea I had at the beginning of the project was to get an annoying boat horn sound effect, and put it in as a placeholder anywhere that needed sound, but didn't have the right one yet. This is a good thing because it annoys me into going to the internets and finding the right sounds to replace that annoying horn. This helps prevent the problem of getting to the end of the project and having to pay really close attention to see if things are actually making noise or not.
Well, thats all I feel like writing for now, theres a few more technical things that I've done, but I lack the energy to type them out right now, so all you guys who enjoy peeks at how FoT works will have to wait until next update[wink] Peace Out!
Sorry for the lapse in updates, I've been pretty busy working on FoT, and by the time I'm ready to write an update, I fall asleep[grin]
Console Pt. II
In my last entry I showed you guys my console system. The system you see in that entry wasn't actually doing anything, it merely let you type things into it, and displayed messages. Well, now it can actually interpret commands you give it, and then execute them. It's a pretty simple system, I have a function called "DissectString()" that splits up a string into components, based on where the commas are. For example, if I passed the string "AddGameObject,100,150" it would spit out three strings, "AddGameObject", "100", and "150". Once the command is dissected, it is analyzed piece by piece, to determine the correct course of action. I've been adding commands as I need them, but the most handy command by far is the "AddGameObject" command, which allows me to spawn anything in the game at the position of my choosing. Here's the new console (pretty much the same thing, but look, a Shotgun pickup at (100,100) wierd[wink])
We want this game to have a simple inventory, where you can equip things and use items you've picked up, such as medkits. I coded up an inventory menu, and Mark has been slowly drawing the icons for all the items you can pick up. As you can see, we've also added a new weapon to the game, the SMG, but we'll talk about that later.... Right now, the items lack their descriptions (thats what the big box on top is for), but you can use items and equip weapons from it, so at least it works.
The SMG is your starting weapon in FoT. It's automatic, and fires at a high rate, but the bullets are a little weak, and the gun is quite innaccurate. What makes it really cool is its alternate fire: When you hold the right mouse button down for a little while, a laser pointer pops up, and upon release of the button, an "aimed shot" is fired that does way more damage than the primary bullets. It's essentially a "charge shot", but instead of making the gun shoot a bigger bullet or something like that, we make the bullet much more accurate and powerful to simulate aiming for a weak point, such as the head of a zombie. Here's a screeny of the laser pointer in action....
Well, thats all I've got for now, but things are chugging along quite nicely, so check back soon! Peace Out!
Sorry for not posting for a couple days, work and life in general have been kicking my ass, so not much development has been getting done on FoT, but what I did do is pretty cool IMO. This is going to be quite the short entry, so hopefully the screenys will make it worthwhile....
Yep, whats a zombie game without a shotgun. In FoT it's actually a "flechette gun", but it pretty much acts like a shotgun. In this "action shot" below, you can see me firing the shotgun (notice the intricate lighting on the player from the muzzle flash)
Note the HUD at the top of the screen (doesn't work yet, but looks cool)
Well, one of the downsides to random level generation is that in order to test some things you have to generate a map over and over again until you get one that generated the thing you want to test. Now this could be solved with some hardcoding, but as past experiences of mine show, that code often becomes intertwined with stuff and never comes out. Solution: Make a good old fashion text console you can input commands to! So today I implemented the display portion of the console. You can type things into it, and other objects can make "announcements" that are displayed (ie. when a Zombie Rat is spawned it announces it). Tomorrow I plan on making the command functionality work, which will let me manipulate the level without having to hope the level generates the right way. Besides, it also looks really cool[grin]
Well, I've got to go to sleep now, I'm taking Mark soaring tomorrow morning, so maybe he'll take some piktarz we can show you guys. Peace Out!
Not much time to write this entry, but Mark drew up some cool stuff that I implemented today, and I just had to show it off...
These were Mark's first attempts at making humanoid enemies, and I think it turned out really well. I implemented them as being terrified creatures that run in random directions from the player, creating a scene of mayhem when there are lots of them in a room. They don't hurt the player (yet...) they just run around and absorb bullets. Mark also arted up a sweet death animation, which looks freaking awesome in motion, so hopefully we'll have a demo out soon. Anyways, in the screeny below you can see a bunch of.... sleeping.... scientists and rats which the player has dutifully exterminated:
Thats about all I have time to write about right now, as always comments are welcome! Peace Out!
Nice meaty update for you guys tonight, so read on!
Well, over the past couple of days I've been implementing weapons, and I must say, the game is alot more fun now that you can actually shoot things! Mark got back a couple days ago and he cranked out an in-game sprite of the Sniper Rifle in the game, as you can see in the mini-screeny below. The weapons work by overlaying an image on top of the armless protagonist to make him look different when holding the different weapons. Also, since the overlay is completely done in a texture, Mark can animate the weapons to his hearts content, which results in some pretty awesome things, as you'll see in a later screeny....
What good is a gun if you have nothing to shoot at? Mark also supplied me with a "Zombie Rat" sprite, so I got to work implementing these little guys and giving them rudimentary AI, as you can see below. Anyways, they can be killed by the weapons I just implemented, and they have a cool death sprite, which is accentuated by the following....
Most of Mark and I's games have been relatively "sterile", meaning that they were never super violent or gory. Well, for this game we kinda want to shift the paradigm and make this one pretty bloody, I mean cummon its a zombie game[wink] Anyways, I made an add-on to the blood pools from my last post, making them slowly grow as time goes on. This results in the cool effect of killing a creature, and then watching a pool of blood form around its corpse. Now, this is pretty cool by itself, but Mark came up with the idea of having the large guns leave a spray of blood behind whatever they hit, so I coded that up as well, and I must say, the results are quite vivid, as you can see in the screenshot below, showcasing all the cool stuff in the game as of tonight...
Now, the only thing cooler than exploding an evil rat with a high power sniper rifle is doing the same thing, only with cool sound effects. Well, fear not because thanks to me thinking ahead when I made the A22 Sound system, I was able to plug it into FoT and get some kickass sounds playing when stuff happens. The Sniper Rifle shot is incredibly cool, and adds a whole lot to the feeling of the game. Now all I have to do is find a dying rat sound....
Mark and I have decided that this game will be a "Demo every week" type game, where we release new versions as soon as we get cool stuff done, so you guys can all test the game out and let us know what you think. We still have a few small things to fix before we release a demo, so check back often to see if we've posted a demo.
Well, thats all for now, let us know what you think! Peace Out!
Not much for you guys tonight, but lots of progress has been made, trust me[grin]
Before Mark left for a week, he left me with a few good textures for the game, such as the nice tables and floor tiles you see in the screenies. He also left me an animated player sprite, which I just implemented tonight. As you can see below, he has no arms, as their positions will be dependent on the weapon you have equipped. Other than that though, he's quite the improvement from using that medkit to test stuff out....
The room transitions in FoT are pretty simple, the screen simply scrolls in the direction of the new room until it's the main room, whereupon the game continues. The transition isn't slow, nor is it instantaneous, which should deter most people from simply transitioning from room to room, taking a pot shot, and then going back to the old room. Anyways, its not really a good screenshot feature, because you have to see it in motion, but here's a screeny of the game in the middle of a transition:
The Story So Far....
While we haven't quite decided on a background story/reason why you are shooting zombies, but do have this much nailed down:
-It takes place in the same timeframe as Angels 22
-The Laboratory you're in is in Soviet Russia
-Those damn Commies are up to no good.....
I know its not a lot, but at least it rules out space marines and aliens (or does it?[wink])
Well I had my first real mind boggling bug in FoT today (and yesterday I guess), I know most of you don't care what it was or how I solved it, given that no one has ever seen the code for this game, but hopefully you can learn from the moral at the end....
So I finally implemented multiple rooms last night, and everything was going fine, until I plopped my handy little moveable health pack in the level to see how the rooms transition. At first glance, everything seemed ok, until I moved from one room to another, whereupon the collision detection got all screwy, and I started colliding with invisible things that stopped the medkit in his tracks. I had no idea where to start looking for why this was happening, so I started experienting, and discovered that the things I was colliding with were in the same layout as the first room, even if I couldn't see them. That was my first clue that somehow, tiles from previous rooms were somehow "leaking" into the newly transitioned one. I then proceeded to look at the transition code to see if I was updating the old room, but rendering the new one. All this time could have been saved if I had just gone to the source of the problem in the first place, the collision detection code. After exhausting all other options, I remembered how the objects actually know where the tiles are to collide with in the first place. Instead of passing a reference to the level everytime I needed to check for collisions, I had made a static array of tiles in the GameObject baseclass. These tile objects were set equal to the room's tiles at the beginning of the program, which worked fine, until you moved into another room, whereupon the object still used the old room information to check for collisions. A quick line of code to update the tile info when rooms were transitioned quickly fixed the problem, which brings me to the moral of the story. If something doesn't work, look long and hard at the actual function that isn't working, because 9 times out of 10 thats where your problem will be. I spent about 8 hours trying various fixes before I even looked in the collision code..... Arghhh!!
Well, I'm going glider flying tomorrow in a single seat Grob G102, which is pretty damn fun, because you're all by yourself, and the glider isn't weighed down by an extra seat and instrument panel. The weather looks favorable tomorrow, and hopefully I'll get some good flying in, which means kewl piktars foryou guys if I remember to bring my camera.
Well, thats all for now, and as always, comments are welcome. Peace Out!
Today I'm going to be talking about how the level generators decide what kind of crap to put in the rooms, and what kinds of controls the user has to regulate the types of rooms that are created.
The map parameters are a set of data that essentially gives the Map generator a checklist of things that should be included in the map. While the final list of parameters is going to be quite long, the current one is pretty small, as you can see below:
# of rooms - How many rooms are in the map?
% fork - How often will the path randomly fork and branch into two paths?
Weapons Level - What kind of weapons will be found on the map
Monster Level - How difficult will the monsters be in the map
# of Locked Doors - How many locked doors (and therefore keys) are there?
# of "Monster Traps" - How many rooms are traps you fight your way out of?
# of Supply Rooms - How many rooms with supplies are there?
# of Bosses - How many bosses are there on the map (handy for mini-bosses)
Possible Catalogs - What tilesets are allowed to be used?
As you can see, by modifying these parameters, the level can be tailored to fit the kind of experience you want, while still retaining the random layouts that are the foundation of the game.
Like the map parameters, the room parameters are a set of data that is used to generate the correct type of room that the map generator requires. Unlike the map parameters though, the room parameters are used more to make sure the random room has what it needs, rather than shaping how the room is made itself. The current set of parameters is rather simple, with thing such as where the doors are in the room, which ones are locked,etc. As the game gets more features added to it, the parameter list will obviously grow to accomodate the new things.
Today I implemented "GameObjects", or anything that isn't a tile or GUI element. GameObject is an abstract base class that serves as a template for anything that needs to interact with other objects in a specific manner, such as a healthkit healing something, or a door opening. I also implemented a few small items to test out the functionality of the "GameObject". You can see the objects in the screeny below(Note: Mark's still gone, sorry about the eye-bleeding sprites[wink])
As you can see in the screeny, I've implemented both locked and unlocked doors, healthkits, keys, and decals. The locked and unlocked doors are both animated, and the locked door will only open if the object attempting to open it has an accesslevel greater than or equal to the security level of the door. The keys boost the access level of whatever object touches them, allowing entrance into the locked door. The healthkit is actually what I use to test collision detection and object reactions, so it can be moved around with the arrow keys. The decals (the crappy red blood spots) are randomly placed, and rotated. Once Mark gets back he can start making a variety of blood splatters so the carnage doesn't get too monotonous!
Well, thats all I have for now, tomorrow I'm planning on getting a few Room's actually linked together, so check back soon, and feel free to leave a comment if you have any questions. Peace Out!
Just a quick little update this time, as I didn't have much time to work on the game today.
As you may have seen in my past few updates, the Prebuilder is a console app that creates a random layout for a map. Now the layout generation is relatively simple, the generator starts at the extreme bottom of the map area, and then adds rooms and randomly branches off to create "forks in the road". This cycle repeats until the number of rooms requested has been met. The difficult part comes later however, when attributes are added to the rooms in the level. An example of an attribute is if the room has a locked door, or if it is a "trap room" that you have to fight your way out of.
Most of the attributes can be randomly placed in any room on the map without any problems, as they aren't dependent on attributes placed in other rooms. An example of these independent rooms would be a supply room with health, an aformentioned "trap room", etc. All the events in these types of rooms are independent of any outside things.
Thr tricky part comes when you have interconnected attributes, such as locked doors and the keys that unlock them. These rooms are special because they must occur in a certain order (ie. the key must come before the locked door). In order to insure this happens, when the rooms are being created, they are placed in a list that organizes them in order of their creation. That way, when a locked door is randomly placed in the map, the key can be placed in any room that was generated earlier than the door. I implemented this feature last night, and despite a few setbacks, I managed to get the system working consistently.
As you can see in the screeny below, the map generation is coming along really nice, and I'm adding special attributes like a crazy person! You may be able to see some wierd things in this screeny, such as having 2 rooms of the same attribute really close to eachother (look at the two armories right next to eachother at the beginning of the map). Now that the basic functionality is in there, I begin to refine the generation, and hopefully get rid of some of those little oddities.
So yesterday night, I went with my girlfriend and her parents to see a concert with these two guys playing folk and country music (not even close to being my favorite genre). I went not expecting to have much fun, but when I got there I was shocked to discover that one of the musicians was none other than the evil Senator Kinsey from Stargate SG-1 (pretty much the greatest show evar!1!~!). Turns out he's a really nice guy, and can play a mean guitar to boot, so the night was saved from being a total waste[wink]
Doom RPG FTW
Also, yesterday night I was bored on the trip to the concert, so I decided to buy a new cellphone game, and after browsing for a couple minutes, I settled on Doom RPG. Expecting to find a crappy half-ass RPG with a doom storyline, I found an incredibly fun game. It was so addicting, that I ended up playing it for about 2 hours last night after I got home. The controls are good, the graphics kickass (raycasting on a phone!?!), and the dialog with other characters is actually pretty funny, here's an example (its a series of emails you can read)
Major Whatever: Where are those reports I asked for, you were supposed to have them done yesterday!
Sargeant Guy: Sorry, I've been playing this old game I found called DOOM, it like 100 years old, but its so incredibly fun and addicting. Its wierd though, the setting sounds alot like what we've been doing.
Anyways, the moral of the story is to buy Doom RPG, it kicks serious ass for a phone game.
Well, thats all I've got for now, but I'm still working, so I might have another update sometime tonight.
I've got more random level goodness for you guys today, along with a screeny of a random room from the generator!
I have the whole development cycle for FoT pretty well planned out right now(we'll see how long I stick to schedule[wink]), and unfortunately, the order I plan on implementing stuff in makes a playable demo out of the question for a little while. The plan at this moment goes like this:
1. Random Room Generator complete
2. Level Layout Generator complete
3. Map system complete (ie. Rooms linked together)
4. Doors, Keys, and Switches complete
5. Player implemented
6. Powerups and Weapons implemented
7. Simple Enemies (stuff with little A.I., like zombies)
8. Smart Enemies (stuff with smart A.I, like.... you'll see[wink])
9. Front End and UI Complete
10. Super Secret Feature Implemented (seriously, its gonna be awesome)
Hopefully by following this "Don't move on until its done" schedule, all the features in the game will be complete and will mesh together nicely when the game is completed.
Today I realized that the catalog system I implemented yesterday needed to be revamped to include a few features that I overlooked. First of all, there was no way for the generator to distinguish wall tiles from decorative tiles, which poses a problem, as you don't want desks and lamps to be making up the walls of your fortress. In order to remedy the situation, I implemented different categories of tiles in the catalogs, so now the tiles are placed in either the "Floortile", "WallTile", or "MiscTile" categories, so the generator can look in the "WallTile" section when building the boundaries of the room, then look at the other categories when filling it out. So far, the system works great, so chalk one up for thinking ahead[grin]
Tile Batches are essentially a way for the generator to know that certain tiles fit together, such as a 3 tile wide desk. Every single Tile object in the game has a batch ID attached to it. Most tiles don't use batches however, and their batch ID is set to -1. When the generator chooses a tile to place on the map, it first looks to see if it has a valid batch ID. If it does, it then looks up the layout of the batch, and places the other tiles that belong with the chosen one in the right places. Unfortunately, the game doesn't automatically know what tiles go with batches, so every single batch has to be declared by hand, which kinda sucks.
As Dragon88 pointed out in my last entry, it would really suck if the generator made levels where the exit door was blocked by a pillar, a river of spilled acid or something like that. Luckily, there are a few safeguards I've built into the generator that should prevent this from ever happening.
A* Pathfinding - This just runs a simple A* routine from the entrance to the room, to all the exit doors, to make sure that a suitable path actually exists to the exit. If the pathfinder fails, then the room is discarded, and another one is randomly created and tested again. More on the A* later.
Tile Radii - Every tile has a certain radius that must be clear of other impassable tiles in order for the new tile to be placed there. Since all the exit doors are placed adjacent to walls, all the really big tile batches won't be able to be placed their because it wont have enough space to fulfill its radius requirements.
"One Tile Barrier" - This one is pretty simple. All it does is make sure that no impassable tiles can be placed right next to the walls bordering the level.
A Lack of... Stuff
Well, Mark is out of town until next Sunday, which kinda sucks because the only good artwork I have from him was done over a 2 day period before he left, so it is obviously limited. He did manage to crank out a few floor tiles, some walls, and a pretty cool desk thing before he left though. As you can see in the screeny below, the art looks pretty good, there just isn't much of it yet.
As you can see, its still lacking quite a few key elements, such as doors, more objects, and proper corner tiles.
More on A*
Today marks a landmark achievement for me, I got my first successful A* implementation working. I've tried before, and failed pretty consistently, because of a lack of persistence, but in order for the whole random aspect of FoT to come to fruition, some form of pathfinding was required to pre-test all the random rooms. So today I went to the Articles section of GDNet, read up of A* theory, and then got to coding. A few hours later, I had a completely functional A* algorithm!! This is good news, because it means that the smarter enemies of the game should be able to at least find their ways around the room to try and kill you in the most efficient manner. You can see a screeny below of the algorithm finding a path through a random room:
Map Layout Refinements
After a few refinements to the prototype map generator, it started cranking out huge levels that look pretty cool, heres an example:
This brings up an interesting topic that Mark and I have been debating, whether or not the game should take place on one gigantic map, or split up between a couple smaller ones? What do you guys think?
Well, thats all for now. Let us know if you guys have any questions or suggestions, comments are always welcome[grin] Peace Out!
Well, I promised you guys a screenshots and a more detailed description of what you can expect our new project (which will from now on be refered to as Fortress of Terror(FoT) in all of my posts).
Pretty much the goal of this game in our minds is to be a new experience everytime you play the game, but we don't want the player to feel like the levels are generated randomly. Hefty goals I know, but I think we can at least meet them halfway[grin]. Anyways, the whole game takes place in "Rooms". The "Rooms" are non-scrolling, one screen arenas, where you do.... stuff. Each "Map" is made up of a series of interconnected "Rooms", with a distinct start, and finish. Since rooms are always square in shape, and because we are limiting doors to being in the four cardinal directions, the entire level can be represented in a 2D array of "Room" objects, and the player can traverse freely through doors to an adjacent "Room".
The Rooms are all tile-based, and each one has a "theme" randomly assigned to it. We build "themes" by placing all the tiles and objects that we want to be in a certain type of room in a sort of catalog that the generator can pick from when creating the Room. By using this system, we can avoid such obvious random behavior such as having pits of lava in a laboratory, or a desk in an aircraft hangar. An example "Catalog" is shown below:
Tiles: Floortile1, Floortile2, Desk1, Desk2, Chair1, Table2, DissectionTable1
Items: Healthkit, Stimpacks, PistolAmmo
Enemies: Doctors, Zombie1, Zombie2, Zombie3, PistolGuard, AK47Guard
Then, using the information in the Catalog, the generator can build a convincing room.
Room's are also split into 4 subtypes to help differentiate their layouts. Each subtype has its own criteria for laying down the main area in the room. The current subtypes are:
Empty - An empty room (*gasp*)
Scattered - Random pillars and stuff
Corridor - Obvious hallways leading to the 4 doors
Maze - Twisting passages
Hopefully, those groups, along with random layouts and objects should be diverse enough. The Room generation is working pretty well right now, but due to a severe lack of quality artwork (Mark's out of town for a week), I'm going to hold off on showing you guys a screeny, sorry....
The Map generator essentially creates the array of "Rooms" that makes up the game. It pretty much works by simply starting at a random point in the array, and then picking a random direction to work in, eventually branching out, until the number of rooms requested has been made. Obviously, there's a little bit more than that involved, but you get the idea[wink] All the rooms are then stored in a list in order of their creation. This allows the generator to make sure that any locked doors have their keys placed before the door itself, and other things like that. Some limitations have to be placed on what rooms can connect to other rooms and whatnot, so that the list doesn't get all screwed up with multiple passages and stuff. Anyways, the Map Generator is working as well, and I'll actually show you a screeny of it "in action", as its just a console app right now. The "H" character is the first (or home) room, all the other rooms have numbers so you can see which way they are flowing. The Rooms with an "S" are where "splits" or forks in the road occur, and the map splits up.
So thats all I'm going to tell you guys for now, tomorrow I'll try and go into more detail on how the Room generator does its magic, but until then, Peace Out!
Its certainly been ahile hasn't it? I wish I had a lot of awesome Angels 22 screens to show you guys to make up for my absence, but unfortunately, most of the work I've been doing is either top-secret(ie. gonna be ca-razy go nuts!), or behind the scenes stuff that you can't really see. Hopefully I'll be able to interest you guys by ranting on and on about the technical stuff I've been up to, and an update on my life, Prinz Eugn style.
As some of you may know, I've been trying to go to college at the U.S. Air Force academy, and become a fighter pilot like my father. Unfortunately, I was medically disqualified for service because of.... heartburn! Yeah, WTF. Anyways, I applied for a medical waiver that would allow me to go to the academy anyways, and everyone I talked to expected it to be granted quickly. Well, I found out about a month ago that the waiver was rejected, and I can't go to the academy this year, which fucking sucks, because I was apparently an extremely competetive candidate, with good chances of being appointed. What gets me the most though is that one of my friends is applying to Westpoint, and he got a waiver for asthma, while I was rejected for having heartburn, which I don't even have to take medicine for. Fortunately, my heartburn "problem" can be fixed with a relatively simple laproscopic surgery, so I'm not completely out of the running yet, I just have to reapply next year. In the meantime, I'll be going to the wonderful school of New Mexico Tech!! I was offered a nice scholarship there, and its actually a very well respected engineering school, so I'll hopefully go there for a year, and then get accepted to the Air Force Academy, and start over there as a freshman in a year. I was pretty pissed off the first couple of days after learning of my waiver rejection, but I've decided to look on the bright side, so I made a pro/con list in my head for the whole situation, which I will now transcribe to the internets.....
-I get at least one year of "real" college life to experience
-I'll be getting experience in a lot of classes that will help ease the transition to the Academy
-I get to keep on programming games for awhile longer!!
-I can stay unhealthily obsessed with GDNet for at least another year!
-I get a new car
-I can work this summer and get the monies!
-I have to restart as a freshman if I get into the Academy, so it'll be 5 years of college
-I have a whole year to get out of physical shape (I just came off of the swimming season)
-I have to work this summer to get the monies....
-Tons more I don't even feel like listing
Air Force Academy Trip
Before I found out about my disqualification, me and two of my friends decided to rent an airplane over spring break and fly up to the Air Force Academy to see what it was like, and meet some friends we know up there. It was pretty much the adventure of a lifetime, as it took us about 4.5 hours to fly up there, through dangerous mountain passes, gale force winds, and overpriced aviation fuel. It was pretty freaking awesome though, and I documented our trip with my digital camera. I've picked out two of the best piktars, and while I know most of you guys don't care about my personal life, theres still some pretty cool pictures of the scenery on the way.
This is a view of the mountainous terrain we were overflying most of the way there. It wouldn't have been a good place to lose an engine...
I really like this picture, its a mountain road we were following through a really high mountain chain. Even though we're about 700 feet off the ground, we're at about 12,000 feet above sea level, and the airplane was barely maintaining altitude with all of our baggage weighing us down. Fun stuff.
While I was rooting through my digital camera looking for the trip pictures, I stumbled across some pics from my dad's retirement ceremony from the Air Force. It happened a little while ago, but some of the pics are kinda funny, so here are the best ones....
Taxiing in from his final flight
The traditional Air Force "hosing down" of the retiree
Nice family pic in front of his F-4
Even the Hooter's Girls showed up (They even brought chicken wings)
My growing IL2 Sturmovik obsession...
I've been a fan of Sturmovik for a long time, so a couple weeks ago I bought the new installment of the series, IL2: 1946. For the record, it kicks serious ass. I can't stop playing the damn thing, theres around 300 playable airplanes, online play, pretty clouds.... I just can't get enough. Anyways, its sucking up a huge amount of my time, so I thought I'd post a kickass screenshot of my grilling some guys online in a Spitfire. BTW, on the offchance that someone who reads my journal actually plays IL2 online, leave a comment so we can play together (there was a player named TANSTAAFL online awhile ago, which got me curious).....
One of my friends turned me on to gliding earlier this year, and I must say, it is probably the funnest flyin I've done in a long time. Initially I was pretty skeptical about it because I had this idea in my head of going up, and then coming right back down a few minutes later. Turns out, that New Mexico has some of the best soaring weather in the world, and a skilled pilot can pretty much stay up all day using the various kinds of lift (ie. thermals). It didn't take long for me to get my license, as I've had my private pilot's license for awhile, and ever since I got it, its been my primary "thing-to-do" in the afternoon.
Secret Uber Project: X!!!11`!!~!
If you've read this far, then good for you, you'll be one of the chosen few who know what Eugn and I are going to be up to for a couple weeks. Angels 22 development pretty much came to a standstill during the final weeks of school, and we never quite were able to get back into the groove, so we decided to try and make a simple little game that is definitely not something we would usually try and do..... A Dungeon Crawler.... with Guns, Commies, Zombies, Robots, Biological Experimentation, and more!!! Don't worry though, we haven't abandoned Angels 22, we just need some new scenery to get us back into the A22 dev mood. The new project has a few limitations that we are imposing on it to keep it from feature creeping its way into next year, and the current limitations are as follows:
-Levels are made up of a series of interconnected "Rooms"
-"Rooms" can only take up one screen
-Basic AI only
-Level Generation must be completely random, requiring no input other than parameters
-Resolution of 800x600 for that old school feel (and to make Mark's life easy)
Anyways, our new project lacks a concrete name at the moment (All my project files are in a folder called "Fortress of Terror", while Mark has been internally refering to it as Lab 81 or something), so if anyone has any suggestions, go for it!
The project is currently coming along great for having started two nights ago, as I already have random room generation working somewhat, and Mark has already begun the task of creating artwork for the project. I'm going to hold off on giving you guys a screenshot until I can put some more of Mark's art in the game, so check in next time for a kewl piktar!
Well, thats all I've got for now, I'm feeling very much back in the saddle, so hopefully there won't be such a huge lapse in journal entries like last time. Peace Out!
Its been a while, I hit one of those development ruts where I just couldn't make myself want to work on Angels 22, but lately I've been picking it up again, so hopefully I'm all done with my down period.
As a few of you may remember from (quite) a few entries ago, AI for the NPC planes in A22 has been "implemented" for quite some time now. Well, unfortunately, the old implementation.... well, it sucked. You see, the development of Angels 22 has been plagued with lofty goals being tacked onto an old engine that wasn't initially built for the stuff we're doing with it. The AI system is no exception, what was originally meant to be a simple search and destroy system has evolved into this huge wingman system that is supposed to be able to dogfight the player and to use advanced features such as the thrust vectoring and boosting. Unfortunately, the current "switch/case" implementation didn't lend itself well to adding complex states and behaviors, so I threw it out and started from scratch, using a class based finite state machine instead of the spaghetti code FSM. Hopefully this refactoring will make tweaking AI behavior a bit more user friendly and we can have some good old fashioned dogfights going on soon enough.
This is just a cool thing we have in the game for some reason. I'm still not sure why the New Soviet Republic built a new version of a failed Soviet moon rocket (N-1), but it looks freaking cool, and I'm sure Mark will mold the story to fit in the rocket, so its all good. Check out the scale on this thing in game:
And once it gets out of the atmosphere, the stages begin separating....
This is a neat little feature that I think adds alot to the game. The game just records a bunch of statistics for you to look at. You can also earn "medals" for performing specific acts, such as disabling 5 ships, which will give you a pirate medal. Anyways, here's the temporary screen I created with my stats for your pleasure. And don't worry, we still have more stats to add.
EDIT: I almost forgot, night-time looks much cooler now that we have stars, I can't believe I didn't think of that one sooner.....
I'm sure there's more stuff, but its crazy late, so it's going to have to wait until next time. Remember, if you haven't already, try out the Angels 22 demo and let us know what you think. Peace Out!