Zonerunners: Bad news

Well, it’s been awhile since the last update, sorry, but this post will sum up everything that’s happened since. It’s a lot, so grab something to eat and sit down.

I think it takes a really big man to admit he screwed up. In this case, I worked on Zonerunners for seven months in denial. There was no clear plan on what Zonerunners was as a game, just “it’s a platformer.” As I worked on Zonerunners I noticed my code was getting stronger and more efficient, whereas the old code was the reverse. But it seemed no amount of good code could fix the bugs and errors I had created in a five month period. Then the doubt began to seep in.

Mid-June and I’m really feeling it now. The code was getting harder and harder to program and stuff was crashing and breaking down. A good idea one night soon became a monster the next and the game started to show signs of grinding to a hault. It was around this time that I gave a copy to my friend to play. First impressions were awesome and he seemingly liked the game and played it a lot. Despite his positive reaction I did not like the game in the same way he did. I saw the game as just another average platformer with a different health system and okay A.I.

I can’t remember how many times I spent reprogramming the A.I. just to create another bug I had to fix later on. Spending countless minutes working away at stupid bugs I could only mask. July came and I didn’t touch it very often, afraid to make a bigger mess.

In late July, I broke. The release date came and I had nothing. A bike ride with my friend through the country helped me make my decision: It was time for a change. Later that week I started a new project file, a clean slate, with no expectations and only a vision to power my creativity. This vision was of devastation and the effects of nuclear warfare.

The Perfect Roguelike

One of my beta testers for Zonerunners was talking about ADOM in the only IRC channel I visit the other day. I had played the game before but hated it, but I gave it a try one last time and fell in love.

ADOM is amazing, I mean, breathtaking! After playing graphically amazing games like Crysis and HL2 and then stepping into a world filled with ASCII characters and being taken away is downright awesome. ADOM took a lot of work to get used to, and it didn’t take long for me to want more, something I’d like to play.

And then it came to me like all my other ideas do: out of nowhere. What about a roguelike that basically places you in a military setting, like a standoff? Then again, how about just a military theme all together? You get the mission, a set of objectives, and certain amount of ammo and then you’re set free to do your job. I put some thought into and decided to give it a go. I’ll have pictures tommorow.

Zonerunners: Cool stuff

It’s been awhile since I’ve updated, I know, but I have too much free time (seriously) now and keep forgetting to update. In today’s post I’m going to give you a rundown of most of the major features and changes since last time.

Smaller Zones: “What? That’s not a feature! That sucks!” Well, there’s no simple way to say this, but GameMaker just can’t handle large Zones. Half of the main zone was completed (comprised of many small testing areas for certain features) before I found out that GM wasn’t going to agree with me. It felt really awesome starting a new level and using the ENTIRE engine on every area and not just scattered around. I had a lot of fun making the first “real” level, it starts just right after the plane crash at the start of the game. Although I need to spice up the crash site a bit, I think it’s pretty hardcore the way it is, but I feel there should be some kind of grassy area between the crash site and the first outpost you have to raid. Right now it’s like, “Crash, now KILL EVERYTHING.” without any pause, but that might be cool if I pull it off right. Maybe I should have a couple of guards come and check it out, starting off the first real battle. I also plan on giving the player several injuries so they get used to typing in codes FAST (I’ll explain this later).

Level Editor (OpenZone): I know you thought, “Hey, isn’t there already one?” Yeah, short story is that it’s stupid to think that a game and level editor will mesh perfectly the first time. I’m on my third rewrite of this thing and I’m thinking about making a level editor that can edit both Zonerunners and Glider Forever (my other game) levels in Python or something. It’ll be a challenge, but they can already read files and make a level out of them, so I just have to make a program that can make those files. Level scripting is pretty cool, basically every object has three events you can script (A “Create” event, for defining variables. “Step” to perform an action every second. “Draw” guess what this does?). I’m also trying to work out easier updating for the game, by storing the code that might change in these “script” files and just having the user download these changed files and replace them with the old.

A.I.: Once again, the A.I. is going to need a some revisions to be brought up to the first major version (1.0). These things include that ugly bug where they spot you though the wall above you and try to go through the wall/suicide. That’s about it, except for jumping when they see a gap in the floor.

More later.

Zonerunners: This and That, That and This

If you’re a programmer and you hear the letters A.I., you probably think, “Heh, no way! Not for me…” Ever thought why? Maybe it’s because you think it’ll be too hard, and maybe it’ll be too much math for you to handle. But let me tell you: It’s not. The key to programming to A.I. is to act human while programming it and keeping the general idea in mind the entire time: To make it human.

But how? Wow, tough question! Let’s take Zonerunners as an example:

A.I. Thought process:
Do I see any bad guys?
YES: Are they close enough?
YES: Shoot them!
NO: Get close enough to shoot them.
NO: Keep looking!

Am I low on health or ammo?
YES: Go find some ammo/health!
NO: Stay still.

Are there any orders for me?
YES: Do them.
NO: Continue doing previous activity.

This is mostly how the A.I. works in Zonerunners. Sorry, no code yet!

Zonerunners: Closed Beta

From the Ongirmar Forums:

Despite setbacks, code flaws, and GAMEOBJECT, I’ve managed to pull off a beta. This is strictly in-house, minus my buddy Solar and the #gamehippo crew, so please keep the link as close to you as you can. I’ll be taking the link down as soon as everyone gets a good download.

What you’ll be getting:

What’s done of Zonerunners (no story elements)
OpenZone: Level editor (saving and loading)
ZoneFX: graphics editor (custom characters, tiles). Still can’t decide if I’ll release this, let alone code it before the beta is out.
.zrn: In-game/external scripting. Probably won’t make the release.

Take note: I’ve added tons of new stuff to the level, that’s why you spawn towards the end of the level and not towards the start (I wanted to show off the fancier stuff)

GRAPHICS WISE- Still no change, everyone is the same as the player. There’s some soldiers to the far left that will be more than happy to follow you, but you’ll have to find them. LOOKING FOR PIXEL ARTIST.

Yep, you read that right: Zonerunners is ready for closed beta! What does this mean? It means the game might come out soon!

Like I said before, this will be a fairly tight release. The idea is to keep the release as close to me as I can so nothing gets leaked. There might be a somewhat public release, but only after the beta testers get through, well, testing everything.

Zonerunners A.I. Test Video

Sorry about the quality, but dialup dosen’t like large videos.

This is a small video of the A.I. doing it’s thing. The first half is of some nifty pathfinding, and the second is a small clan war. Don’t forget to comment and check my other videos, which is all Zonerunners stuff.

The module design

    In C++ you can add “libraries” to your program, basically making harder things easier, and making the impossible possible. For example. you might find a library that makes drawing to the screen easier, or maybe even one designed to aid in the game development process. In Zonerunners I want the same control, maybe even more. But for any of this to happen I’d have to do some serious thinking.

So now I have to decide: Do I want the hassle of external script reading and the hassle of fixing things outside of the GameMaker GUI? Do I want to give the player some ability like importing their own script into the game? Or will that be too much of a risk?

All these are issues that must be addressed when approaching the idea of a module design, which is the ability to attach external “modules” of code onto the existing engine without recompiling it. The possibility of keeping the module design until the game is finished, upon which you make all the external scripts internal (inserting them into the Game Maker GUI), is also a good approach.

But like I said, I needed a way to code while actually PLAYING the game without handing over total control to the player. If you look back at my previous post called “The Introduction!” you’ll see my code for the in-game console towards the end. We’ll be using the same approach for this, so look it over!

Modules work this way in Zonerunners: An external script is loaded and parsed much like code is handled with the console. Only this time, the parser also runs through a list of blacklisted commands (commands I don’t want the user using), and are removed from the script. Wow, that was simple!

Dynamic Level Loading

    Probably one of the biggest challenges of Zonerunners is the fact that the game is one big level, meaning very little load times and little to no hiccups that normal games usally have upon loading the next section or level. For those familiar with Game Maker, there’s a handy script called instance_deactivate(), which takes the object out of the main game loop without deleting it. Meaning you can delete it, but bring it back with all it’s stats intact. Cool, huh?

Well, for Zonerunners I found that doing this would basically ruin the game code-wise. You see, for the game to work I have to have control over everything all of the time, because the A.I. itself must have the same control. Putting it simply: Deactivating the enviorment (which also plays a major role in speed) would render the A.I. useless since it can’t read what’s around it. The reason the game was coming to a hault on large maps was due to the intensive A.I. script running for every character EVERY frame. As you can imagine, this would slow the game down to a near 10fps on a large map, let alone a small one. I had to fix this fast, for the future of the game depended on it.

I was fully prepared for a one-hour coding spree when I somehow managed to make a simple script in under five minutes that solved the problem:

if x>level.xa and x<level.xb{return true}else{return false}

“What?” Yes, this solved my problem. What it does is check to see if the calling object is in the currently set level boundaries. If the object is not in the area, it’s not drawn to the screen, it’s STEP event does not run, but it’s still “there”. This way, depending on what I set the current boundaries as I can make small levels inside one big level.

The Introduction!

Hello everyone! I’m a 15-year-old computer programmer from a small country town in Indiana. Normally, you’d think I’d be busy hauling hay or doing typical farm-stuff; not true! Although I do enjoy physical activity (unusual for computer nerds) I also enjoy wading knee deep in code and game development fury! I’m currently in between using C++ and Game Maker. Yes, I know, Game Maker is frowned upon as the evil of the entire programming world, but I swear to you, this time it’s different. For now on I will record my progress and post code snippits from my game Zonerunners, and small helpful hints on proper Game Maker usage.

Day 1: 7:34 PM 3/26/2008

It’s been awhile since I started Zonerunners, but it’s never too late to start showing people the guts of the game without confusing them! I’m currently on Prerelease Version 2, which may not seem like much, but is actually a huge step forward into the game engine and theory. Right now I guess you could say that I’m finishing the A.I., basically doing a lot of polish to make it like good enough to release.

One of the biggest problems I’ve had with Zonerunners is the fact that most of the engine was new territory. I had never really went in depth into a platform engine until now, okay, I had messed with a few before, but never really went all that far into them. So as you can see from some of these code snippits the code is still rough since the focus has been on the A.I. since the beginning.

if tar=false{
if _y<300 and scan=1 {_y+=10} if tar=false and scan=1 and _y>=300 {_y=-300;scan=1}
switch (clan){
case "TESTERTOASTER":
for (t=1; t<=test[0,0]; t+=1){if distance_to_object(test[0,t])<=viewdistance{tarid=test[0,t];tar=true}}
break;
case "QWERTY":
for (t=1; t<=null[0,0]; t+=1){if distance_to_object(null[0,t])<=viewdistance{tarid=null[0,t];tar=true}}
break;
}
}

The above is from the main A.I. script, called ai_seek(). What this does is check to see if the object calling has already targeted something, and if not, find one by searching a list of enemies that are stored in an array depending on which “clan” the object is in. Each clan has an array of enemies, which are added to the array once they engage in some form of combat with a member of the clan.

Next up is a very very simple “console”. If you’ve ever encountered a console in a game you know what I mean. For those who don’t: It’s basically a text box from which you can execute/modify values from.

exec=string_delete(argument0,string_pos("(",argument0),string_length(argument0))for (i=1;i<=com_array[0];i+=1){
if exec=com_array[i]{
execute_string(argument0)
}
}

This console is called con_exe() (short for Console Execute) . What this does is takes the argument and checks it against an array of valid commands. But since most arguments would be along the lines of “move_object_to(100,200)” I have the string_delete() command automatically cut everything after the first “(” at which point a FOR loop checks the modified command against the previously mentioned array of commands. If the FOR loop detects a valid entry the unmodified argument is executed with execute_string().That’s all for today!