Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

382 Neutral

About Zeyro

  • Rank
  1. I work with a very small team on which I am the main Programmer and Game Designer, and I can't seem to communicate effectively to the teams modelers what criteria I have for certain models for the game. We haven't been able to find anyone to do concept art for us, so we've been resorting to google image search where I try to identify major the main features of an image that I'd like to see in the model itself. But even with that, I still get models back that are borderline unusable because the design itself is flawed.   One example is a door that will be used throughout many of the games levels, in the prototype I created it as two blocks that slide apart and made sure to make it extremely wide (4 times as wide as it is tall) and the example that I gave the artists was also wider than it was tall; however the model that the artists created was more squarish. (Just as wide as it was tall). My reasoning for making to door so wide is because the player could otherwise get stuck on it very easily, so changing the design to fit the model is difficult here.   I don't blame the modelers for that kind of thing because I know we aren't giving them a whole lot to go on, but at the same time I'm not sure how to identify these possible issues before they occur (and as a programmer that drives me insane >.<). On one hand, I can't modify everything in the game to fit whatever crazy ideas the modelers come up with, but on the other I don't want to tell them that hours of their life have been wasted on a flawed design partially because I couldn't communicate the goal effectively.   I thought running through and blocking out all of the models and the basic collision for each level would be enough to relay the idea, but apparently it isn't. Another example is a mech we have in the game - the blocked version has one blaster on it with the other arm down to the side, and it only shoots from one arm. However, the modelers created one with blasters one both arms. (Which isn't that hard for them to fix, but I still am not sure where the error in communication is).   I'm currently tempted to go through the each level and model a 'concept' version of everything in blender, but I know that would almost double the estimated remaining development time. I'm just not sure what to do :/
  2. It's kinda funny how you mention the story in shooters being good. I actually won't even buy shooters anymore because multiplayer feels repetitive and I always feel that thes story is just too short and is never even that good (Not to say that it's empirically bad, it's just funny because that's my main reason for hating them XD) I also never loved the FF series for gameplay, (they are a terrible example of Turn-Based mechanics imo, though I will admit to not having played them all, I have played older ones and more recent ones.) I think FF sells based on visuals and soke story elements. However, as to what makes turn-based games so popular. There are different types: -Menu-based combat: This can be a lot of fun late-game because you end up having to think several moves ahead as well as adjust based on each turn. Usually the full compexity of these systems is not revealed until the middle of the game when move-types and such come into play. Pokemon is a great example of menu-vased combat dons right. There are a lot of complex interactions between the pokemon, items, moveset, types and even their attitudes. -Turn-based: Some games are turn based in the actions that can be performed. These games are usually popular because the user has a limited number of actions that they can perform in a set amount of time. Usually one action per one turn. They can have ridculous complexity (Nethack) or managable Complexity (FTL). Nethack has an insane number of interactions possible between different items and monster and I would highly reccomend you learn to play (mastering the controls is a skill by itself) or at least read some spoilers for it. Turn-based games just allow ghe player to think more about their next move and weigh all the possibilities, while shooters allow this to a limited extent. I think people look down on shooters because they don't require the same level of planning, though shootersdo require a high information processig speed and can achieve the same high-level play as a turn-based gsme. Though I think turn-based games tend to more complex (and again, FF is a horrible example of this imo) and thus can get a higher depth easier but at the expense of a high playerbase. I think this also needs to be clarified: Some games are about mechanics, some are about story. Chess is about mastering the mechanics with zero story, whereas point-and-click adevtures are about story with zero mechanics. Some.of your examples are mismatched in this degree: Bioshock was mostly about story with very little mechanical mastery needed (as I recall, though I did not play the entire game), while games like Half-Life have a very good mix. Other real-time games like League of Legends have little story and a LOT of mechanical depth to them. Whereas Nethack has little story and tons of mechanics, and Dragon Quest is light on mechanics but heavy on story. (To some degree at least).
  3. League is actually super balanced, the only arguably OP champ is Katarina who can reset her abilities upon getting a kill (meaning she has all the tools she needs to kill the next person and reset her abilities yet again). However, due to the team conpositions it can really feel like some games absolutely hopeless. Partvof the issue is that many champs have mechanics completely unique to them, so if you don't understand that mechanic, the champ feels waaay too powerful by normal measures. A notable example is Karthus, which can cast a massive damage spell gauranteed to hit everyone on the enemy team even while he is dead. But, several champion abilities and one item make you untargetable, negating any damage from his ability. Seems unfair until you know there is a way to avoid 100% of the time.
  4. Zeyro

    Text-based game about life

    Then I don't see much point in including them Also, I did catch one thing in the screenshots: The dollar signs goes before the numbers when talking about money. As in $5, $1000, etc.
  5. Zeyro

    Different factions or different units

    As with most things, it depends. Two examples: -Starcraft gave each faction unique units and pretty much a unique playstyle. But bear in mind that they were different races. -Supreme Commander gave each faction unique units but they also shared (in function) a lot of units and the base mechanics were almkst identical. The factions were all human but differed in recent history. Here is the point: What are you trying to highlight? Starcraft wanted to highlight how different each race was while Supreme Commander showed that they were all still human and all thought pretty much the same way at their core. If your empires are of different races and you want that emphasized, give unique units. If you don't think that difference ia relevant or don't want to highlight it then don't. As Waterlimon said, you can create different playstyles with the root node of a tech-tree alone, you don't need factions for that. However, I do disagree that a pre-selected faction system is not expandable. Spellforce 2 is my counter-example. It allowed a player to select the order in which they upgrade their central building with sub-faction addons. Allowing every race to have 3 different basic playstyles. Giving players a selection of subfactions in-game is a good expansion of the system (in my opinion, and if I understood the arguement correctly). The ideal situation would be to give each player a limited number of sub-factions they can have, but also allow them any combination in amy order. You could also randomize some of them, etc.
  6. Based on what I've heard, if you don't want the player to get attached to something, you should either give them more of that object, make it less customizable, or make.it easy to replace. I think if you encouraged players (offered some sort of bonus) to create a sizable initial pool of characters with a little less customization than they're used to, it would send the message. Rogue legacy did something similar though they made the iteration of a new family member instanateous upon death with minimal customization. And allowed only 1 character at a time (to my knowledge). I would reference Minecraft for this; it's kinda special when you get that first diamond pick in thr game - you never forget it at home. But then later when you have 20 of the things or a full stack of diamonds lying around, you're willing to peak aroundthat corner at 1 heart to see if that was indeed a creeper you saw.
  7. Zeyro

    To Sprint or Not to Sprint

    I have played a limited amount of Halo 1 and Halo 3, so I my memory might be a little rusty but here it goes:   Personally, I do think sprinting adds to the experience. As far as whether it messes with other systems or not, I can't say.   I say that it adds to the experience for a few reasons: 1.-When I'm playing an FPS I tend to want to be the 'action hero' (I think a lot of people share this sentiment, which is why I feel that it is a relevant point), but in almost every action movie there is that scene where the hero sprints down a long hallway followed by an explosion or something of that nature. It just feels really cool to be able to sprint around, it makes the player feel like they have more control and more mobility in a chaotic battlefield.   2.-There is a theory about why we play games that states that it is related to a combination of 3 reasons: Competence, Relatedness and Autonomy. While this theory is by no means absolute or necessarily correct, it does offer insight. Halo players probably play mostly for Competence in multi-player, and adding another mechanic that is straightforward but adds a world of depth like sprinting, is really good because it gives Competence-players something else to play with. A whole lot can be done with sprinting (throwing off the enemies timing when they try to lead you with their sniper rifle, allowing you to make new jumps, allowing you to get away from an enemy that just sprinted to you...etc.).   3.- It is a double-edged sword. Imagine someone sprinting at you with a energy-sword, he uses up his sprint before he reaches you. You turn and sprint away and gun him down before his sprint recharges. Now image the same scenario but where had just used your sprint to get to that position. He slices you to bits. This offers a lot of decision-making that must be done on the fly, and players can see the result of those decisions very quickly in the game, which allows them to learn quickly, which is where you find a lot of fun in games. It can be a quickly iterating game loop that can be a toy in and of itself.  I remember Blacklight:Retribution allowed players to enter a mode that allowed them to see every enemy, trap, turret, weapon etc. on the map but it was limited to about 2 seconds and you couldn't shoot while using it. Sounds a bit OP don't you think? But it wasn't. You had to know when it was safe to use it and when it was a good idea to use it. Do you use it to find a target? Do you use it to scout ahead to the next room? It recharged fairly slowly and getting caught by an enemy when you had it up was a death sentence. But it could save you for a well-place landmine or an ambush.   That's my take on it. It's really difficult to speak objectively, but I think if it has worked for several games in the series, now would be a really bad time to go and fix what clearly isn't broken. Changing the formula is fine every once in a while, but not when players aren't asking for it, imo. I think they should look at the Mods for Halo and see if players are modding the mobility in any way, if not, then clearly nobody thinks the mobility is a problem if the people who set out to literally change the game aren't changing that part of the game.
  8. Flotilla is really cool too. It's turn based in 3D space that takes ship rotation into account.
  9. Zeyro

    I need some tips please...

    You seem to be thinking of the game story-first. I've heard from a lot of people that this is generally a bad idea, unless it is the story you mainly want to focus on. (Some games such as point-and-click games and jrpgs are mostly content, not to say that there aren't 3rd-person games that are story-heavy *glances at Mass Effect and Dragon Age*).   I would recommend you decide on the core 'feel' of the gameplay and then decide on a list of mechanics that will support that feel. That usually takes care of the question 'What does X do?' because you will not ever add X to the game unless you already know how it needs to function mechanically.   Examples:   If you want the player to feel powerful for example, the suit would need more combat abilities like: -Very strong melee combat abilities -A grappling hook that can pull enemies to you or push them away -A sword that can be thrown at super-sonic speed to knock enemies back and deal massive damage -A beam that melts some enemies but not others   If you want the player to feel powerless for example, the suit could have utility/disabling abilities like: -A beam that melts enemy weapons -The ability to phase through or break through walls -The ability to pick up really heavy objects and throw them -A telekinetic beam that can be used to steal enemy weapons -A computer system that can be turned on to alert you when enemy weapon are powering up to fire (so you can dodge them or something)   It's really hard to judge a game idea without much detail on the core mechanics and core features because those things usually determine if the game is fun or not. A third-person game in 3D is really general because it doesn't tell much about the goal of the game itself. The above is based on the assumption that the player will be facing some kind of enemy humanoids, but it is entirely possible that you want the player to roam the planet and raid it for resources to help stage the retaliation you were talking about. You could also want the player to contend with the local wildlife in which case the suit could poses to whole other set of powers geared around that.   Examples of different suit powers in other games:   The Metroid suit is given abilities that help it move through the environment and help it face new enemies. This is because a lot of the game is based on exploration and environmental puzzles. A suit that can be upgraded to change size, use different door-opening weapons and weapons that have different effects on enemies is perfectly suited to a game that needs to enable the player to solve puzzles with the tools at their disposal.   The game BlackLight: Retribution has a powersuit as well equipped with a chain-gun and a rail-gun, as well as a dash. This gives the player the ability to attack enemies at long or short-range and the ability to move around the battlefield in a clunky way. It's perfect for a game in which the player will be facing tons of other enemies with guns.     That is just my experience though.
  10. My *attempt* XD   "Sheep Wars: The Mutton Awakens"   An adventure game where the player must solve story-based puzzles to help a race of super-intelligent sheep, who have created an empire in outer space, defeat the undead sheep that are coming back to life on all their planets. Each puzzle completed helps the sheep advance their technology and learn more about the the Mutton threat. The player controls 3 different sheep that can be dispersed across the empire and can unlock different puzzles, part of the challenge is finding out which sheep needs to go where before the Mutton take over.
  11. Zeyro

    Update 1 - Building Structures

    As I mentioned previously, the game engine I am using is a custom one built completely from scratch. This left me with a bit of a problem in implementing my GUI as I realized the Android code was probably not portable. I eventually settled on the idea of creating a single Display class which could pass messages to and from the Game itself, meaning that only the Display would need to be re-written when I try porting the thing to PC later. All update calls are sent to Display, which calls the Android UI, while all return messages are sent using classes and formats that the engine understands. After I got the GUI working, I decided to focus on building structures as opposed to a crafting system because I'm still unsure of how I am going to display the players inventory to them. And plus, building little pretend villages is so much more fun than crafting a bunch of random junk, that is useless given that units still con't actually hold equipment. I feel that the implementation was a bit more convoluted than it should be: All of the players input is channeled through a script called the CursorScript, when the player wishes to build a structure, they hit a button on the UI which is passed to the CursorScript. The CursorScript then calls display passing it a list of structures the player can build. On the Android system, a dialog appears with the name of the structure (material costs and descriptions are in the manual, there are only about 6 structures the player can build). When the player makes a choice, the Display class then calls the game and sends it an Evaluate command, which the is passed to the CursorScript, which then calls the scene to create an entity and finally an entity loader to load the appropriate structure. But it works and I can't see any glaring theoretical flaws (yet). I'll probably end up passing the script directly to Display, there isn't really any reason for the Game to worry about this part, but that might cause a concurrency issue, since the Display must run on the UI thread while the game runs on its own thread. Now that I a construction system working, I need to add resource costs and resource selection, and then ensure that certain structures are built only from certain resources. Then probably an inventory system, then item crafting or unit creation.
  12. I'm creating a game and I got to thinking about the tutorial today. What bugs me about most tutorials I see today is that they almost seem to try to convince you that you are playing the game while you just watch the game being played for you. (I cite a lot of browser-RTS games on this, but I will also call out warcraft3 and spellforce - while those are old, the tutorial offers very little interactivity beyond what you are told to do, thus not really any gameplay taking place, imo. More recent examples would be most of the 'Clash' genre.) I really dislike this and I'd prefer not to even waste time trying to program something I can't stand, so I've come with an alternative idea:   I'd rather have no interactive tutorial, but organize information about the game very well within the manual, as well as have a 'Tutorial' map that only provides an outline of how to do everything with very specific instructions and pictures. The goal will be to allow the player to experiment on the tutorial map without the pressures that the normal game mode provides. (Ex: Food is a limited resource normally, on this map it is infinite.) However, this map will not allow the player to access all the materials that can be used to craft items or introduce very many enemies to the player.   I plan to make a virtual manual that is accessible from a button on the main UI. Not from a 'Menu->Help->Manual' type selection, but just a normal help button that brings up the manual. I also plan for the manual to allow the player to bookmark pages that they find helpful or might want to return to.   The whole idea behind all of this is to allow the player to chose whether they want to follow step-by-step instructions or whether they want to experiment on the tutorial map or just jump right into the game and figure it out as they go along.   My question is: Does this approach sound like a good idea?  
  13. Zeyro

    Project Desciption

    The Orc and Human bases will naturally send out small attack waves against each other; they will have no interest in the player at first, but the players methods of collecting enough food to move on: 1.) Killing deer/wildlife, which threatens the food supply of the Human and Orc armies, and 2.) Raiding outposts directly, will anger the two armies. They will send units to investigate based on how angry they are, which will force the player to move on or be destroyed. (The human and orc bases never run out of resources, nor can they be destroyed.)   I really want to design the maps so that the player is forced to run through the midpoint of the human-orc battlefield, meaning that they must either pay attention to when the waves are spawned, or have a good enough military to break through. (By the time the player is able to move their civilians through, one or both sides should be just as likely to attack the player as each-other.)
  14. Zeyro

    Project Desciption

    Hello, I want to start this Dev Journal off with a description of the game I aim to create. First a little history about the development of the idea, then an overview of the story, then game itself, a list of mechanics and finally a note about the game engine. The Idea: I wanted to create a fairly complex strategy game for mobile devices, I wanted to use a turn-based model as opposed to real-time because it is fairly difficult to take real-time game seriously on a mobile device, in my opinion and in my experience the user needs to spend a decent amount of thought ensuring that their fingers are on the correct controls, as well as playing the game itself. And even further than that, the game needs to be able to start and stop on a dime. All of these things point to a turn-based game being ideal for a mobile platform. I also wanted something similar to starcraft and warcraft, which are what initially got me into games and game development. Specifically, I want aspects of unit building and base building, so I decided that the player will build structures which will allow the creation of items and units. After that, I ran into an Android game called Ramble Planet (which you should really have a look at, it is really well done), that was so unique that it made me want to throw a twist or two into this project. I eventually settled on a resource-gathering twist. Instead of controlling resource nodes like in most 4X/RTS games, the player must kill enemy units to gain the resources they need to build units and structures and craft items. The Story: The back-story of the game is that the player is given command of a clan of Goblins that is caught between the opposing fronts of a Human and Orc war. The humans and orcs have no outward aggression to the Goblins, but the troops from both sides require food, which is threatening the Goblin food supply, and the orcs have no problem eating the Goblins, should they get hungry enough, So, the Goblin clan is forced to flee their homeland in search of a safe haven to call home. The Game: The game itself is played as a series of 9-ish maps in a campaign format. Each map is a grid, units and structures take up one space on this grid. The players objective is to move all of their units from the starting zone of the map to the ending zone. The player controls two types of Goblin unit, civilian and military. Civilian units use large amounts of food when they move, but military units use a little food every turn. Food can be found on each level and only a certain percentage (50% maybe) can be carried from one level to the next. The idea is that the player must carefully think about how many military units they need/will be able to sustain. The food mechanic will hopefully create a need to move forward as well a way to hold the player back. Food can be found by killing neutral units on the map (such as deer or wolves), or by raiding Human/Orc camps or neutral camps. All of these actions anger the Humans/Orcs to varying degrees (killing deer less than raiding outposts). The Human and Orc units are also far stronger than the Goblin units as well as better equipped. This means that while killing Human and Orcs units is a good way to get equipment, it is also very dangerous and will cause the enemies to hunt the player down faster. The Humans and Orcs also have their own bases on the map, but they are mostly cosmetic and offer the the AI a place to put new units, as well as reinforce the power of the two races. (These structures cannot be destroyed by player units.) Core Mechanics: (From the GDD, with some descriptions) -Combat Player can kill units to help them gather resources. -Crafting Player crafts new equipment with a somewhat open-ended system, encouraging creativity and experimentation. -Equipment Player manages unit equipment to adapt to the situation or to improve unit stats. -Build Units/Structures Player is allowed to create structures that allow the crafting of new items/equipment, as well as new units. -Resource Management Player must manage crafting materials and food. They must ensure their units do not starve and craft better equipment as time moves on. -Base Defence Players base/civilian units are vulnerable and must be protected. The Game Engine: The game engine is a custom one that I created from scratch in Java. The renderer it uses is also my own and only works on the Android platform. However, I have tried (and hopefully succeeded) in keeping the rendering and UI completely separate from the game itself. I plan to attempt to port the game to PC later just as an exercise (I've never tried to port anything before). The engine uses the Entity-Component architecture, with Entities being their own objects instead of ID's. (Only because I had never heard of the latter system until after I started making the thing). I don't claim that it is a good engine, only that it runs at 30 fps and has minimal memory leaks. (Not true leaks, but still detrimental after long periods of time). This project was started a while ago,so more updates later this week about what part I'm actually working on. Probably the crafting system.
  15. I've been programming a simple physics engine in android for practice. I am using multiple threads to handle the graphics (1 thread inside a custom surfaceview) a physics thread that runs inside a Game class (not in the UI thread). Every time I close the application I get the error message claiming that the app has stopped working, but when I examine the LogCat in Eclipse, it only tells me that the app has died and that no errors have actually occurred. Sometimes when the app is running I get the same problem but again the LogCat only shows that the application has died and not that there were any errors causing it to force close. I then looked at the CPU usage in eclipse, and it shows that the application begins to reach 90%+ of the CPU. I am worried that Android is killing my application because it is taking up too many system resources.   My questions are:  How do I manage the threads so that they don't go crazy and consume incredible system resources?   (I am already limiting the physics and graphics threads to 30 updates per second. But I am only extending the basic java Thread class, not using Handlers or Timers, which I've heard mention of)
  • Advertisement

Important Information

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

GameDev.net 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!