FatPugStudio

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About FatPugStudio

  • Rank
    Member

Personal Information

Social

  • Twitter
    @FatPugStudio

Recent Profile Visitors

216 profile views
  1. www.hacknplan.com I don't how come it isn't more popular amongst Trello gamedev users.
  2. Rough estimate for how much 2d animators charge

    Afaik, spritesheets are 30-50 bucks per hour, for a non-oustanding artist. It's hard to give an estimate per frame with unknown sheet size, drawing style and details involved. The guy working on my game (you can see the art in the signature) charges 30 for hour, animated or not, it's all work.
  3. I'm sure you'll encounter some of the Unity quirks as that one as you delve deeper into it, unfortunately. But every engine has its problems.
  4. How to protect yourself and your game?

    Don't waste your time with an NDA, strip the project so it contains enough for them to work on it and not enough for them to gain anything by stealing it.
  5. How to protect yourself and your game?

    I hired a lot of freelancers for some of my stuff and i protected myself dead simple. If you're afraid someone will steal your art - give them a project (or a part of the project) with only placeholder art to work on, then copy the things they did to the original project. If you're afraid someone will steal your code - give them as little as needed for them to work on it, a scene with placeholder art, basic functionality needed for them to have a grasp of the concept. If you're afraid some will steal your idea - don't worry, they need to start working on the game from the beginning, and you're probably far off already. But the best way is to precisely define what exactly do you need and have them to that only, without accessing your project. It may take a bit more time and be more expensive since you'll probably need to revise the work done a few times, but it's the ultimate in protecting yourself and your project.
  6. Sure, that's what i did in the beginning. Unfortunately, Unity does not support more than level of nested prefabs in the editor, only on runtime (unless you are using some of the suspicious quality third party assets) so i wouldn't be able to make squadron > ship > thruster hierarchy which speeds up the process of creating enemy waves significantly.
  7. I’ve been contemplating on design of the weapon system and upgrades for a lot of time. I wanted the game to be based on skill but have a variety which would add to the replayability of the game at the same time. Here are the basic definitions i have decided on: Game will contain about 30 weapons Every weapon can be upgraded 4 times (levels 1-5) Ship has two weapon slots available, you can freely switch between weapons in game You can’t have same two weapons equipped You eject the currently active weapon by picking up a new one that’s different For example, you have Pulse Gun Level 1 equipped as active weapon and Biter Level 1 equipped as inactive. After blasting the enemy transport you come across Ripper and pick it up. Since you don’t have it equipped in any of slots, it will replace the active weapon and eject Pulse Gun Level 1. If you wanted to replace Biter, you could simply switch weapons to make Biter active and replace it by picking up Ripper. This will be a common occurence for adapting to the enemy types because of their vulnerability or resistance to certain type of damage (ballistic/explosive/energy/special against normal/armored/shielded types of enemies). I could make things simpler in design and coding by simply omitting the part where the replaced weapon is ejected since there’s a small chance of picking it up by accident since it involves pressing a key while you hover over the weapon. However, two player mode requires that feature for the weapons to be interchangeable between players and that is a great way to improve cooperation, gameplay and combined firepower. Due to some design limitations i had to make a hard choice that can affect the future gameplay on upgrading the equipped weapon and few solutions came to my mind. 1. You can only upgrade the weapon if you pick up the exact same weapon. That way, either equipped or not, the weapon in players possession is upgraded to the next level without any ejection which only happens when you are picking up a weapon you don’t have equipped on any of the slots. While challenging with high long-term impact on decision-making, you only have 6% chance of getting the same weapon from the transport which is slim to none and could severely hamper the player experience. If weapons had only one level the approach would be viable, but with total of 150 weapon levels it would only be frustrating. 2. Whenever you equip a weapon that is not equipped it is always at level 1, but when you upgrade any of the weapons on ship to level 2, the weapon you replace the level 2 weapon with will also be level 2. Basically, if we modify the first example a bit so the active weapon (Pulse Gun) is level 2 and inactive weapon (Biter) is level 1, when we pickup a Ripper instead of Pulse Gun it will automatically be upgraded to level 2. Opposite to first approach, it is less challenging and encourages experimentation, but it comes with a design problem which i’ll explain thoroughly. When we picked up Biter it is upgraded to level 2 on the ship and Pulse Gun level 2 is ejected. This enables us to switch Biter to active weapon, pickup the level 2 Pulse Gun, eject the Biter, and then pick up the Biter again which will automatically be upgraded to level 2 now. While requiring a bit more speed to do it in a chaotic environment i would considering it cheating since you’re upgrading both weapons that way and that is certainly not something i plan to implement. As i noted in the introduction, i could simply disable the weapon previously equipped to be ejected, but that beats the idea of switching weapons between players which i find to be a great gameplay feature of a co-op mode. Maybe i’ll disable the feature of ejecting only for single player mode for now. 3. Make weapons upgradeable only by picking up the same weapon as equipped, but increase the chance of spawning a weapon you already have The maths on this one are simple, though a bit tedious to code. You have 25% of transport spawning active weapon, 25% of spawning inactive weapon and 50% chance of spawning a new weapon. This comes with a different kind of trade-of. Though 25% is a lot it may happen that you rarely run into a weapon you want to upgrade. On the other hand, you may always run into a weapon you already maxed out. This discourages experimentation since you will always want to hold on to your maxed out weapons, no matter how good or bad they are. There are no bad weapons per se, but holding on to weapons of the same type greatly decreases success. 4. Weapon upgrade pickups Though not originally meant to be implemented, this could pose a good solution combined with approach 1 or 2. It is simply a kind of a joker card which levels up your active weapon without worrying if it’s the same one. If you pick it up, the active weapon gets upgraded and you just keep on blasting. Which solution would YOU like to see implemented? The post Weapon upgrade system designs and limitations appeared first on Fat Pug Studio. View the full article
  8. Earnings and Statistics from my 3rd Android Game - Stickman RPG

    First of all, it's a great success to finish a game, especially at such a young age, wow! It proves you have the determination and skills required to do it. Just keep on making them, you've got a bright future!
  9. The Grid Wow, it’s been a while, but things are moving forward slowly but surely! I’ve been busy with lots of coding and programming enemies and i encountered some difficulties in proper positioning. On the image below you can find how the spawn points looked (5 spheres on each side) and how they look now (the red X signs) Obviously, 12 times more spawning points offer much more flexibilityObviously, it offers much more in terms of positioning. More than a year ago, when i first started working on a spawn system i wasn’t apt enough to make it the way i wanted to (grid system) so i had to be satisfied with only a few spawn points and additional repositioning upon instantiating. Needless to say, it adds much more work to simple spawning and positioning of those enemies. By using this handy tool from the asset store (https://www.assetstore.unity3d.com/en/#!/content/20502) i created a grid made out of objects completely automatic. A fine tool indeed. After that, i simply added those to the hash table and now i can simply reference the object whose position i want the enemy to use as spawn point and voila. Besides using it to spawn enemies already in a pattern, i can use them to actually create random patterns on runtime by referencing a different object from the hash table upon predefined parameters to avoid completely random clutter. Not only that, a finer grid enables me to avoid spawning the enemies too close to each other or overlap. Since i’m using Core Game Kit for spawning, i’m waiting for the developers to implement the feature based on sphere raycasting, i.e. if there’s an object of certain tag or layer (enemy) in a defined range, the system won’t spawn any more to avoid the overlapping. It will work great with the system i made and described few devlogs earlies which is based on enemy pool values and enemy quantities. Also, Easy Save 3 Beta will soon get a full release (i hope VERY SOON) which will enable IMPORTING variables from a .csv file. It will be of an immense help for tweaking the gameplay. Enemy Pattern Making (Squadrons) I must admit, though i am passionate about making a game, some things are quite tedious. I’m having problems with making enemy squadrons, and the way i make them is so boring and uninspiring it really halts my progress. Before i was well into Unity engine limitations on nested prefabs (only one child per object, i.e. child cannot have it’s own child as a prefab, only when instantiated on runtime due to way serialization works) i thought it was going to be a breeze, i just drag and drop enemies in a formation, put them under a parent prefab and voila! Except it doesn’t work like that. All of my enemy prefabs typically have two children, Gunpoint and Thruster. Gunpoint hold the shooting logic and muzzle flash animation, while Thruster has the, well, thruster animation. It is on a separate object to avoid being colored with the rest of the enemy ship when it changes color on hit by a player weapon. So i guess i’ll keep my work and make an empty squadron prefab which will spawn and then spawn the enemies in a desired pattern coded into it. That’s all nice and dandy until you actually start working that way. No more cosy drag and drop, just selecting what to spawn, input coordinates and hit play too see what you’ve done. If something’s not positioned correctly (it usually isn’t), reposition the enemy, copy the coordinates, stop, and paste them. Repeat 10 times for 10 enemy objects in a squadron, and i should have hundreds of them! Horrible! Prefab with multiple children with position setting on runtimeSo i decided to change my ways. I need to make a reverse approach. Instead of creating an enemy prefab with all the children attached, i’ll attach the Gunpoint and Thruster on instantiation, which is only a two step process compared to setting the position of multiple enemies inside the squadron. This way, i have a clean enemy prefabs without children which i can joyfully drag and drop into positions i want and simply save them under a prefab which will be used for spawning. Prefab with multiple children instantiating on runtimeThough it is a bit more work initially, it provides an immense saving of time later and makes it more visual, fun and intuitive to work with. The post Spawning System Overhaul and overcoming the obstacle of enemy pattern making appeared first on Fat Pug Studio. View the full article
  10. Backgrounds work

    I bought this little fella (http://www.wacom.com/en-br/products/pen-tablets/one-wacom-m) a while ago but i never found time to play around with it. This weekend was very hot so i was mostly home and i’ve drawn a background for the game, hope you dig it. Took me a few hours. The post Backgrounds work appeared first on Fat Pug Studio. View the full article
  11. Burn-out, in shortest possible, is a state of physical and mental exhaustion. Is is caused by too much work and stress, and not enough rest and sleep. It can lead to severe health problems, with the smallest one being clinical depression. Apparently, it is very common in game development professions. I started working on Rick Henderson And The Artifact Of Gods a year and a half ago. First, everything was going fine. Fueled by passion and motivation, i stayed late many nights and used weekends to recover from that maniacal tempo. Then the weekends weren’t enough. I started barely waking up and functioning very lousy. Eating too much to get energy, drinking too much coffee. Quality of work started to fall, and it took me more and more time to finish stuff. My concentration was going down. I got frustrated when i simply couldn’t stay up anymore because i lacked energy. When i did stay up, it was a torture of mind and body with work quality falling down even more. Depression started to creep in. A vicious circle of guilt and exhaustion that ultimately led to a month pause during which i couldn’t even look at my game. After one big and one smaller burnout (the other one was a reminder) i experienced, i learned a good lesson. Making a game is not a 100 meters sprint of passion, it is a 42 kilometer marathon that requires perseverance, determination and motivation. To stay determined and motivated we need to take care of our bodies and minds. Typical, a bit satirized, representation of a programmer is a skinny or a fat bold guy with glasses and a generally neglected appearance (stubble, lousy wardrobe and so on). Turns out, there’s a grain of truth in every joke. This type of work takes an enormous amount of time and while not physically demanding it DOES impact the body, and with it the mind enormously. I am determined to avoid burnouts in the future, and here is what i can recommend to you to avoid them too. Sleep Well Developing games can be addictive, especially when you get into The Flow (or in the zone, as it is sometimes referred to). As i already have a full-time job and family, the flow usually comes late at night, when family is asleep and after an hour or two already in the works. I get completely immersed and have a distorted feeling of time and space, hyperfocus and increased productivity. If you think you can use this time well, make sure you can be absent from the work tomorrow so you can regenerate and have a good night of sleep. However, i wouldn’t recommend doing this often. It’s better to save that energy when you’re close to some goal that requires a large amount of work that you feel you must do in one push or you will lose focus if you split it in chunks. Sleeping less than 6 hours increases obesity (you feel like eating more to compensate for lack of energy), chance of stroke, heart diseases and diabetes. Not to mention that you will be forgetful, need lots of coffee or caffeine drinks to make it through the day and be irritable as hell. Depression also creeps in. Make sure you sleep at least 7 hours and try sleeping in on weekends if you can. Eat healthy I know it sounds obvious and like a cliché, but if you are mid thirties like i am, this fact needs to be repeated all the time. Make time to prepare a healthy, balanced meal. Eat vegetables, fruits, fish and meat. Besides making your own meals is the healthiest choice of all, it helps rest the mind by physically and mentally distancing you from computer. I find cooking relaxing and sometimes similar to long bicycle rides when my mind wanders off. Drink water and tea, not sodas full of sugar. Avoid too much caffeine, it actually makes you harder to concentrate if you overdo it, makes your brain foggy, causes caffeine crash and messes up your sleep quality when taken too late (if you manage to fall asleep). While we all love coffee as a stimulant, don’t forget that it is addicting and withdrawal symptoms can last very long, so it’s best to consume it in reasonable amounts. Exercise Besides sleeping enough and eating healthy, exercise is one of the most important things in whole thing of staying mentally stable when working on a game. Get your juices flowing, ride a bike, pump some iron, run, cross fit, whatever makes you sweat. You will feel better, happier, healthier, have more energy to work, need less sleep, wake more rested and most important of all, have your brain functioning better due to improved blood flow. If you are like me, sitting in the office for 8 hours staring at a screen (like most of us actually) and then doing that again in the afternoon, be realistic, it does horrible things to your body and mind and you must be fit to endure it. Don’t forget friends and family Life doesn’t just stop because you are working on something that takes an enormous chunk of your spare time. You’ve got a family to spend time with and take care off and friendships you have to cherish. Socializing helps to take the mind off of your work, relax or perhaps vocalize the things that worry you or you are having problems with in your development. Even if someone is not into that, a fresh and naive look at your problem can be an eye opener. After all, friends and family is all that matters in the end. Take days off No matter how great your passion and motivation are, being involved in anything 24/7 is just not good. You will get saturated, lose objectivity of your work and ultimately repelled by the sole sight of computer. Make goals on which you are working on, and say to yourself “when i finish this boss design, i’m going to treat myself with 3 days off”. And do it, feel satisfied with the work you’ve done and enjoy in your days off without guilt because you deserved them. Relax (away from screen if possible) Since you are probably already a full-time screen starer and you stare some more when you get home, i recommend you get some relaxation that doesn’t include staring at any type of screen. Cooking is a great way to relax, walk your dog without your smartphone, pet your cat for hours, read a book or a magazine, make a bubble bath, lay on the floor and stare at ceiling thinking about nothing, ride a bike out of town. It’s all relaxing and helps soothe your exhausted and work saturated mind. Work on something different If you really feel the need for working on your project, switching between the things you do often helps to avoid saturation. When i got bored of working on enemy waves, i switched to searching for sound effects and making some music. This development blog is also part of my avoiding burnout by doing something different. When you get sick of coding you can do some drawing if you’re apt at it, making music, writing a storyline, whatever jingles your bells. Just make sure you track your goals and don’t spread yourself too thin as it lowers the productivity and quality of work. Managing it all That’s all nice and dandy, taking care of yourself, but when you will find the time to work on the game with all this relaxing, exercising and cooking? It’s up to you to figure it out and integrate it into your lifestyle. It’s probably not going to translate into a lot of work hours, but what matters is the quality of those work hours. Most helpful thing if you are not able to work regularly on your game (i.e. have a family and a job) is to run a development log. Not just any, but a very tight one, with clear goals cut into smaller chunks you can handle and work on whenever you can grab some spare time. Besides knowing where to continue with your work after a few days of AFK, it will be motivating to track your progress. I’ll probably write more about it next time. Stay healthy and take it easy! The post 7 ways to avoid burnout appeared first on Fat Pug Studio. View the full article
  12. Beginner stuck with programming Java

    I've been learning Java for almost 4 years before things "clicked". Start making a small game to learn what actually comes out of your code, it is much more understandable and less abstract when you actually see code doing something.
  13. Cost of Game Making

    Excuse me if i am bumping the thread since it is inactive since April, but i was astonished by the figures mentioned here. I live in a country where average monthly salary is about 300-400 EUR, and i am making a game on a budget of around 3000-5000 EUR. It is a relatively small game (for me and my experience level it is huge) and you inspired me for my next devlog, a sort of "pre-mortem". I'll share it with you when i finish it, hope my 2 cents will help someone.
  14. Dev Log #4

    The Anatomy Of A Roguelike Endless Mode Endless Mode, for now, will be the backbone of the game. I don’t much like the term, but let’s call it Roguelike. For those not unacquainted with the term, it’s pretty simple. The basics of roguelike games are permadeath (which means you start all over when you die) and procedurally generated levels. Procedural is basically a fancy catch-phrase for controlled random. It means that the levels are made by parametrized procedures that keep the random factor under control by defining the aforementioned procedures, certain value ranges and all sorts of parameters you want randomized. Anyone ever trying to make a completely random piece of any sort of art, be it visual or sound, knows that it usually turns out horrible. With the assistance of parameters like harmonies and scales in music, or color palettes, fractals and similar stuff you can get bettes results, but without the human input it’s usually a meaningless chaos with only glimps of something human-like. Then what is it good for you ask? Well, with proper parametrization, you can get a gameplay experience that is different every time you play the game, yet it has the same essence and feeling. How does that work in my game, more precisely, in the endless mode? The most obvious thing that can be parametrized is the appearance of enemies on screen, so how do we do that? Triggered Spawners For spawning enemies, we need spawners, predefined locations on the screen where the enemy ships appear. Since we want the illusion of ships flying IN the visible part of the screen, spawners are set OUTSIDE the visible part of the screen, just a little bit beyond camera frustum. There are a total of 20 spawners, 5 for each side of the screen, and each of them spawns enemies by the command sent to them. That command, in the form of a triggered custom event (hence the name Triggered Spawners), is chosen randomly by a set of rules. Rules are not made to be broken In opposite of the old saying, rules in roguelike game must be well designed and not broken, unless you want your whole game to be broken. A tight set of rules need to be implemented to the enemy spawning system for it to be challenging enough, but not too hard and various enough, but not too random. So besides the variety, by making the rules for a procedurally generated Endless Mode i came up with something i call the Adaptive Difficulty System. Here’s how the whole thing works: You start the game with 0 Experience Points (the first variable), empty Enemy Value Pool (the second variable) and empty Enemy Array (the third variable, let’s call it Enemy Counter from now on). Experience points are the core to the system and a lot of stuff depends on them: You earn them by destroying enemies. Enemy Value Pool is the value of all enemies present on screen. When they appear, their value (based on their characteristics, HP, weapons, etc.) is added to the pool. When they are destroyed or they leave screen, their value is subtracted to the pool. The Enemy Array is simply a counter of the enemies present on the screen, when the enemy appears, it’s added to the array, when it disappears by means of leaving screen or death in flames, it is removed from the array. The thing is, Enemy Value Pool has a limit that is based on your experience level and it is raised higher as you earn more experience by destroying enemies. Trigger for unlocking more complex and harder waves, new types of enemies and upgrading already unlocked enemies. Trigger for bosses appearing, and transports with pickups appearing (that means no level is of the same length). Enemy Value Pool works in conjunction with both experience points and the Enemy Counter and it is crucial for the difficulty level adaptation. The game will never spawn more enemies than the pool can hold, so it ensures a gradual progression in difficulty based on your skill. If you’re not such a good shot, experience will rise slowly, and with it the pool size. If you are a hotshot and hit ’em dead on the spot, you will progress much faster, get upgrades much faster and get to the bosses faster. So what’s the Enemy Counter for? Тhe Enemy Pool Value has a certain limitations without it. You can have a pool half empty, but a lots of small enemies on screen that already pose a challenge by sheer numbers. Based by Enemy Pool Value only, the system will start an event of filling it up by spawning more enemies. The Enemy Counter serves as a fail-safe system against this. Instead of spawning more enemies, it will either delay further spawning if the number of enemies it too large, or perhaps launch one big enemy to add some variety to the situation. Simplified Schematic of Adaptive Difficulty SystemEnemy Waves As stated before, enemy waves are spawned in a controlled random manner, featuring procedural and hand-crafted elements. Procedural elements would be random number of single enemies moving on their predefined agenda or via paths with their numbers and type defined by experience points, while hand-crafter ones are squadrons. Squadrons They have the largest number of variety, but they can be painstaking to make if a large number of ships is involved. For example, this is a basic one, Marine Carrier in the escort of five Provokers, six ships total. A typical representation of hand-crafted squadronDue to Unitys limitation of nested prefabs, i can’t just pop them into scene view and save the whole squadron as a prefab (which would be really awesome and speed things up), instead i have a prefab which instantiates ships on defined coordinates in local space. That needs a lot of tweaking, entering values manually then pressing play to see where they are actually positioned. In the whole process, waiting for Unity to start the game to see where the ships are spawned takes the most time. Obviously, the time spent is the largest con, but the pro is that i can simply replace prefabs in the squadron in a blink of an eye. That means i can change those Provokers escorting the Marine Carrier with another ships in only a few seconds, or even set each position to spawn a random ship, thus making the ships following the carrier different each time and even spawn different ones according to the players experience level. When you take into account around 40-50 ships made until now, you get the idea how tiresome can sometimes be to make all these squadrons, but it keeps the game away from being a procedural generated crap, it keeps the randomness factor but in a structured way. Random Number Range Single Enemies Now this is the actual procedural generated crap that is to be avoided, but when used properly it functions great. What does that title actually mean? There are several enemy spawn points scattered all around the screen, by utilizing this approach, depending on certain variables, they will spawn single enemies that follow their own behavior, be it the regular “move forward and shoot” or something else. There are some cool thing regarding this. For example, i can spawn 1, 2 or 10 ships in a random pattern based on the players experience level or number of ships already on screen. They act like fillers, we already have one or two squadrons on screen, so let’s drop a few more small baddies that do their own thing. It also keeps the players on toes since they don’t know what to expect. A horrible drawback is that things can get too random if not controlled by various parameters that need to be finely tuned, like mutual distance that avoids overlapping the sprites. Enemies That Move Via Paths I’m sure you’ll agree that the game would be very boring if all the enemies would just move forward towards players side of the screen, no matter how many types of them there is. Using paths to move the enemies further deepens the variety and the semi-randomness factor of the game. Obviously, paths can be used for both Single Enemies and Squadrons. They work great for single enemies since we can set a wave to spawn, let’s say, 5-7 small ships and then use a path that’s branching, like this: An example of a branching waypointIn this example, when the ships get to the first waypoint (purple square in the upper part of screen) they will do a check which will apply random branch choice, some will keep moving forward towards the left part of the screen, and some will circle around and go back right, or maybe sometimes we’ll set them all to follow the same path, so for a path like this, we actually have three outcomes: all follow path 1, all follow path 2, all branch random, which is flexible and great. Using paths in Squadrons take a bit more time to work on, but they add further variety to squadrons. The Provokers following the Marine Carrier in the first picture may spread or fall back after a while. Another important option that using paths gives is the easing of movement. Ship may start moving slow, than speed up while moving down the path. Or other way around. That can be randomized to, per ship, squadron, or a whole wave. It gives a lot more natural feeling to movement since ships moving at the same speed constantly may feel mechanical and boring. Easing types that allow for more natural movement In Out Expo Ease type in actionUtilizing all this stuff drives the game away from the classical “memorize the pattern while moving on rails” type of play. It takes a lot more time to work on but definitely keeps every game session exciting and fresh and rises replayability to a whole new level. Unfortunately for some, and in contrast to a usual Roguelike practices, not using seeds for procedural generation means you won’t ever be able to replay the game you just played, but i see it as a great thing. Further randomizations While not essential for gameplay itself, backgrounds are randomly changed with each level. But what IS essential for gameplay are the Random Events that come with some of the background. They are created in a brief moment of whiteout when ship enters the hyperspace after defeating the level boss and further improves the challenge and replayability. Some of those include meteor rains, ion storms or asteroid fields, adding up to the difficulty, variety and that juicy bonus multiplier. Weapon upgrade system overhaul Last, but not least important is the overhaul of a weapon upgrade system i spoke about in the last devlog. After a few weeks work it turned out that the weapon pickup and upgrade system is not functioning really well when handling the pickup after the first weapon switch. I refactored some array related stuff regarding the active/inactive weapon status and now it works like a charm. Weapon Upgrade System RehaulIt can be further improved by introducing a case-switch instead of all the yellow colored states which i will do in the next iteration. It will further simplify the machine, but i don’t think it can go simpler than that, at least using the state machine. The post Dev Log #4 appeared first on Fat Pug Studio. View the full article
  15. Aaarrr!!!

    Pirate faction led by mighty Thoraxx!The post Aaarrr!!! appeared first on Fat Pug Studio. View the full article