Jump to content
  • Advertisement

Truerror

Member
  • Content count

    110
  • Joined

  • Last visited

Community Reputation

523 Good

About Truerror

  • Rank
    Member
  1. Truerror

    Math for Game Developers: Calculus

      They would. At least most of them would. I wasn't really interested in physics before getting into game development. But now that I've experienced myself how those principles could be used, I'm more motivated to study it.
  2. Truerror

    Automatoys: Artside of The Moon

      Go ahead. They're not licensed, so feel free to use them.
  3. Truerror

    WOA2: Day 3 (Polish + More Gameplay)

    That looks awesome! I say that if you release this on Steam, I'd buy it. Games like Harvest Moon are a rarity these days. Most devs opt to go either the sim way, or the totally arcade way where you have to possess a good enough reflex to be able to play them decently.
  4. 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.
  5. Truerror

    An idea, finally!

      Hmm... I see, I believe. (I did notice your mention of the relationship between the "Attack", "Defend" and "Wild Attack" actions; I wasn't sure, however, whether the strategy of the game was intended to turn out more or less like Rock-Paper-Scissors.) My concern then might be that those tells might make it too easy. You may have thought of this already, but it might be worth having some degree of hidden information; the opposition then attempts to guess the player's configuration based on the full collection of items, inferring the hidden information from the choice of combination.     Thanks for the comment. Yes, I thought about it. Unfortunately, while I do have an idea on how to handle this, it's still not as detailed as I want it to be. For instance, the Speed attribute was meant to balance things out a bit. Having a bot act first would give you the edge when the moves are equal (Attack vs Attack, for example). But unfortunately, I started a bit late, and for now I'm busy with character design, so I don't know if I have enough time to address this issue... :(
  6. So it's a cross between capture the flag and king of the hill. Nice one!
  7. Truerror

    An idea, finally!

      The player would be able to see the opponent's bot before starting. I'm trying to come up with unique look for each component, so that players can instantly recognize what that component is capable of just by looking at it. Kinda like playing WoW: If you see a winged paladin (meaning he has Avenging Wrath active) coming at you at full speed, you flee.   I mentioned in my post that this will be like rock-paper-scissors, so Attack > Defend > Wild Attack > Attack. Defend cuts the damage from Attack by half, and counters Wild Attack, thus nullifying it. A player might think that it's good to defend all the time and choose a configuration with one big shield. The opponent would look at said big shield and then guess that he's playing defensively. So instead of Wild Attack, the opponent could just Attack all the time. It is slower, but he's still going to take damage and not give much in return (or none at all), since all he does is Defend. Things like that.
  8. Truerror

    End of Day Two

    Hmm... blurry...
  9. Truerror

    An idea, finally!

      Well, thanks. But Things are going to be slow, as I failed to find a willing artist, and thus will have to make the art assets myself.   Plus, it's kinda unfair that you get to hide your idea. Can we see some sneak peek at least? The picture on your journal is blurry, but it looks detailed...
  10. 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.
  11. Truerror

    Advertising Through YouTubers

    So in another words, this is the game marketing equal of forex/stock trading. If you gain, you gain a lot, if you fail, you fail hard.
  12. Truerror

    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]
  13. Truerror

    Move, <player>!

      Can you elaborate more on that?   Edit: Nevermind. I think I understand. And now I feel stupid.   Yes, you're right. The width and height of each tiles are fixed, so I shouln't have any problems getting the tile coordinate from the mouse position. Thanks for the suggestion.
  14. Truerror

    The tiled beginning of my journey

      Indeed :)   I realized it almost as soon as I finished writing that code (I had been browsing the net while writing code) that the string class has a method to convert it to a char array. If I had done that, not only would it shorten the code, it would also simplify map making (right now, I'm doing it by hand, haven't build a tool for that yet). I've put it in my To-Do list, and I'll do it when the game is feature-complete. Then would be the time of major overhaul. Thanks for your suggestion, appreciate it. :)
  15. Truerror

    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.X + 20) { if (mousePos.Y >= tile.position.Y && mousePos.Y < tile.position.Y + 20) { Console.WriteLine(tile.coordinate.X.ToString() + " " + tile.coordinate.Y.ToString()); // For debugging only. return tile.coordinate; } } } return new Point(0, 0); } 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 < (int)destinationTile.position.X) { gameObject.Position = new Vector2(gameObject.Position.X + 1, gameObject.Position.Y); } else gameObject.Position = new Vector2(gameObject.Position.X - 1, gameObject.Position.Y); if ((int)gameObject.Position.X == (int)destinationTile.position.X) { if ((int)gameObject.Position.Y < (int)destinationTile.position.Y) { gameObject.Position = new Vector2(gameObject.Position.X, gameObject.Position.Y + 1); } else gameObject.Position = new Vector2(gameObject.Position.X, gameObject.Position.Y - 1); } if (gameObject.Position == destinationTile.position) gameObject.isMoving = false; } } 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: [media][/media]
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!