Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

A journal on my efforts to learn game development.

Entries in this blog


Automatoys: Artside of The Moon

So I found a title for my game. It shall be called "Automatoys"!

And since I'm such a helpless introvert who's unable to make more friends than the number of fingers I have intact, I of course failed to secure the help of an artist. Therefore, I am forced to make my own arts

How does an introvert hobbyist game programmer make an art? The answer is... PAINT!

Yes, that Paint. The software bundled into every iteration of consumer Windows since Win95 (or was it 3.1? Who cares...). And accompanying it are the ever faithful GIMP and Spriter. However, even with the aid of such venerable software collection, I'm still going at a snail's pace. Guess I'm just not cut out to be an artist, after all.

Anyway, here are two spritesheets I managed to make. These are for the bases, the third one is in the making. After that, the torsos, and after that, the mountable parts. Hopefully I can finish them all in two days. After that, the code part begins. These nights are gonna be sleepless...

Okay, I'm going back to drawing things manually.




An idea, finally!

So I think we can all agree that getting an idea for a game jam takes time, especially if the theme of said game jam is outside of our expectation. Seriously, "The toys are alive"? Needs a twisted genius to come up with such theme. Not.

The theme is so simple, to the point that it literally stunned me when I first read it. Of course, after I gathered my wits, I then proceeded at once to find a game idea suitable for this year's theme. So I searched, and surfed the web (does anyone still use that term, "surf"? I feel so old...) and hours later, I found myself thanking Blizzard yet again for the creation of WoW. Specifically, the little pastime inside of that game; the battle pets. I think at this point you all can roughly guess what kind of game I'm thinking right now

For those of you who are confused, I'll explain. Battle pets in WoW come in many forms, but some of them resemble those little toy robots we had when we were kids. Still can't guess what game I'm making? Fine, I'll say it: I'm trying to make a battle bot game. With configurable battle bots. DUeling each other. Yeah, the idea is not new, so sue me.

Enough with the chitchats, let's flesh out the idea.

The players won't really control the bots. They issue commands to the bot before the actual duel ensues. The bots will then carry out those orders in sequence. In summary, it'll be like rock-paper-scissors, but a bit different. There are four commands the player can issue, Attack, Defend, Wlld Attack, and Special. If any of you played the Suikoden series, you'll know what the first three are and how they relate to each other. The last one is a bit different in the sense that it doesn't really "beat" or "beaten" by anything. It's just a special move. What it does depends on what kind of utilities you have mounted. Depending on the configuration, some bots might not have all of those options.

The bots themselves are configured from three parts:
The base: This provides locomotion and armor. It affects Speed, that is, how fast the bot can act each turn, and Defense, that is, how well a bot resists attacks. Faster bots act first, and thus it is advantageous to have a fast base. But fast base have low armor, and if the base sustains enough damage, its speed will be cut in half.
The torso. This provides slots for weapons and utilities. It doesn't affect any stats per say, but it affects what kind of weapons or utilities can be mounted on the bot.
The mountable parts. Weapons enable the bot to Attack/Wild Attack, shields enable the bot to Defend, and utilities allow the bot to do a Special move, which depends on what utility is mounted.

The torso slots are divided into three types: Weapon, Shield, and Utility. Each of these is divided into two types: Large and Small. Some torsos might have two Large Weapon slots but nothing else, or it might have one Large Shield and one Small Weapon slot, or one small slots for each type of mountable parts.

There are three attributes for each bots: Armor, Speed, and Damage. Armor acts like health in most RPGs, instead of a mean to mitigate damage. Speed is used to check which bot acts first, and Damage is how much Armor can an attack take off in a single direct hit. Note that if for some reason the player chooses to not mount any weapons at all on his bot, then that bot has no Damage attribute.

Each session starts with each player issuing commands to its bot, arranging those commands in an ordered list. Once the duel starts, each bot will take turns executing those commands, and if by the end of the chain a victor has not been decided, then the chain loops back to the beginning.

By the way, I haven't decided on a title now, I'll think about it later.




Ready, Action!

Ok, so it's been a while since my last post. Since then, I've revamped the code, especially the movement code, added game states, and now, I've added a simple action menu which pops up everytimes a unit is selected.

My game state implementation is a very simple one. I simply created a class for each type of game state. So I added a Level.cs and refactored most of the codes in my main Game1.cs into it. I also made a Menu.cs for the various menus I might implement. The Game1.cs now only consists of (mainly) switch states to switch from one state to another.

I also revamped the entire movement code so that the game objects now move one tile each frame. It's not only faster, but it also enables me to keep track of how many tiles they pass through, which will be useful when I start implementing the movement point system later. The GameObject.cs therefore now contains a total of 5 move-related methods. MoveUp(), MoveDown(), MoveLeft(), and MoveRight() are all privates. Move() is public, and it calls the first 4 methods as needed.

The last change is the action menu. Right now I have 3 options there, but only the 'Move' option is implemented. The action menu pops up slightly to the right of the selected unit, and is handled by the unit itself. It's working now, but if the unit is located at the right edge of the map, then the menu appears outside of the map boundaries. I haven't coded the special offsets for these situations yet.

Here's how it looks right now:
[media] [/media]




Move, <player>!

Yes, this entry is about movement. I think it'll be a short one, though I must admit, movement in a tile-based game is harder than I thought. Ok, now on to the technical bits.

You see, the difficulty (at least for me) of making a tile-based game mostly lies on the fact that everything, virtually everything must adhere to a certain set of grid; The positions of the the objects, the map, the tiles themselves, and last but not least, the movement. Now, of course there are are aspects of it that makes the development process easier. The collision for example, is easier to implement compared to, say, a platformer, since all we need to do is mark a certain tile "occupied" and tell the objects they can't enter an occupied tile, other than their current tile. While that certainly sounds easier to do than the actual practice, it's still simpler to implement than the full-fledged collision checking often required in other types of games.

For the game, I needed a way to select a certain game object when the user clicks on it, which (since the end destination would also be determined by a mouse click) means I also needed a way to know which tile my mouse is currently in when I clicked the left/right button. I had a solution in my mind, but I wasn't certain it'd be good enough, since it involves scanning through the entire tileArray. So, I searched around and found something called "picking". Unfortunately though, further inquiries only revealed 3D solutions. The few answers I found regarding 2D tile-based picking were pretty much similar to my own solution. One StackOverflow question answer however, said that while it would certainly be heavy, it's still good enough, since we're not doing it every single frame, only on a mouse click. So, I decided to go with it.[code=auto:140] public static Point MouseCoordinate(MapParser mapParser) { Vector2 mousePos = new Vector2(Mouse.GetState().X, Mouse.GetState().Y); foreach (Tile tile in mapParser.tileArray) { if (mousePos.X >= tile.position.X && mousePos.X = tile.position.Y && mousePos.Y
First of all, please disregard the magic numbers. My tiles are 20 by 20 pixels in size. I plan to refactor that, so that it can accept an arbitrary size.

As you can see, I've put a console output there, just so I can be sure it works. I also tweaked the MapParser and GameObject class a bit since using a 2D array means your coordinate axes are flipped. And now that I have a way to tell which tile my mouse is in, I'll also need a way to tell which object I selected, or whether I have any object selected at all.[code=auto:157] public void SelectedObject(List objectCollection) { foreach (GameObject item in objectCollection) { if (item.Coordinate == MouseCoordinate(mapParser)) { currentObject = item; } else { currentObject = null; } } }
There! Now I not only know which tile is selected, and which object is selected. That leaves the movement function.[code=auto:172] public void Movement(GameObject gameObject = null) { if (gameObject != null) { gameObject.Coordinate = destinationTileCoord; if ((int)gameObject.Position.X
Yes, I know, that code looks superheavy, and superbad. I also think so, but turns out the performance doesn't get any perceivable hit. The superbad is true though. I don't have any profiling tools, so I simply fired up the trusty Task Manager and played around while checking to see if it's too heavy. For now, it gets 7-10% CPU usage and around 9MB memory. However, I realize that this is still very early, and the game contains too few objects for it to be accurately measured. So things will certainly get heavier from here on.

Oh, and if you're wondering why I had make sure the X movement is finished before starting the Y movement, that's because I wanted the movement to be like Super Robot Wars, which is the inspiration for this experimental game. In SRW (at least the GBA version, I haven't played SRW in any other platforms) objects would move in a straight line along an axis, no diagonal movements. The end result is this:





The tiled beginning of my journey

It's been a while since I first registered at, and I've taken advantage of some of its features, notably the forums and the hobbyist projects listing. The journey to become a full-fledged game developer is arduous, and full of obstacles. That said, it's also enjoyable. I've had lots of a-ha moments that is simply too fond to let go, and therefore had been thinking about starting my own blog. However, I never get around to actually doing it.

Then I came across this feature, and thought "Why not use it in lieu of a blog? It's not like I need the things that a full-featured blog have, I just want to have a personal record of what I've done and want to do next." Thus, this journal.

My first entry would be an experiment on tiles, in XNA. Its' nothing fancy, just a simple parser so that I can better understand the innner workings of a tile-base game. If I can manage this, then perhaps I can make something like the Super Robot Wars. It's good to keep those dreams alive, right? So, on to the technical stuff.

The first thing that popped up in my mind when I thought about 'tiles' was a 2D array, so I based my approach on that, and proceeded to make a Tile class to populate the array. The class has the position and the texture of the tile. I also made an enum for the tile types and some very simple images (20x20 at the moment, I'm not that good at drawing things) to represent each type. For now, I have three types, plains, mountains, and water. Then, while building my Tile class, I realized that I'd need some sort of test map to test it with. Most probably loaded from a text-based file. That means, I'd need some sort of parser for the text file. Now there's a problem.[code=auto:61] public void BuildMap() { for (int x = 0; x
I must admit that I'm not a very proficient programmer, and thus, I have never parsed text from a file before, though I knew how to read from a file. Through trial and error, I finally managed to hack a parser class, which responsibility is to read the map file, actually map its content (which is string) to a 2D array, and finally convert the 2D array of strings into a 2D array of Tiles. As you can see from the code snippet above, it wasn't the best code ever But it gets the job done. The texture for each tiles is decided at the time of its creation, along with their positions. Then, after I'm done populating the 2D array with tiles, I finally drew them. The end result can be seen in that picture above, with the game screen on the right, showing the tiles, and the very simple map file on the left. Granted, it's not pretty. But at least it's a start.

I'll write another update when I get more things done. Next would be adding a game object in there. Hope I can do it.



Sign in to follow this  
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!