Jump to content
  • Advertisement

Search the Community

Showing results for tags 'Sprites'.

The search index is currently processing. Current results may not be complete.


More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Audio
    • Music and Sound FX
  • Business
    • Business and Law
    • Career Development
    • Production and Management
  • Game Design
    • Game Design and Theory
    • Writing for Games
    • UX for Games
  • Industry
    • Interviews
    • Event Coverage
  • Programming
    • Artificial Intelligence
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Engines and Middleware
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
  • Archive

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • Game Dev Loadout
  • Game Dev Unchained

Categories

  • Game Developers Conference
    • GDC 2017
    • GDC 2018
  • Power-Up Digital Games Conference
    • PDGC I: Words of Wisdom
    • PDGC II: The Devs Strike Back
    • PDGC III: Syntax Error

Forums

  • Audio
    • Music and Sound FX
  • Business
    • Games Career Development
    • Production and Management
    • Games Business and Law
  • Game Design
    • Game Design and Theory
    • Writing for Games
  • Programming
    • Artificial Intelligence
    • Engines and Middleware
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
    • 2D and 3D Art
    • Art Critique and Feedback
  • Community
    • GameDev Challenges
    • GDNet+ Member Forum
    • GDNet Lounge
    • GDNet Comments, Suggestions, and Ideas
    • Coding Horrors
    • Your Announcements
    • Hobby Project Classifieds
    • Indie Showcase
    • Article Writing
  • Affiliates
    • NeHe Productions
    • AngelCode
  • Topical
    • Virtual and Augmented Reality
    • News
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical
  • GameDev Challenges's Topics
  • For Beginners's Forum
  • Unreal Engine Users's Unreal Engine Group Forum
  • Unity Developers's Forum
  • Unity Developers's Asset Share

Calendars

  • Community Calendar
  • Games Industry Events
  • Game Jams
  • GameDev Challenges's Schedule

Blogs

There are no results to display.

There are no results to display.

Product Groups

  • Advertisements
  • GameDev Gear

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Website


Role


Twitter


Github


Twitch


Steam

Found 67 results

  1. dyl_pickle

    Art Dump

  2. [This article was originally posted at The Gamedev Guru's Blog] I normally do not share my past struggles, but this topic deserves it. What to do when you lose hope with Unity UI? I still remember that weekend, about five years ago... I spent the entire weekend worried about all the technical debt I was accumulating over the months in one of my projects. I had done things too quickly, without really understanding them. Clearly enough, that had to stop working at some point. The thing is, I owed my clients results but I had no idea how to bring them. That morning though, I said to myself: Rubén, this is enough. Stop the excuses. You are becoming a professional today. So, I decided to gather every single resource I could find about user interfaces in Unity, because that was the biggest hurdle I was dealing with for several weeks. I read forums, best practices, Unite videos, read all blogs I could find on that topic and did my own research. Did you ever experience this feeling of slowly getting overwhelmed by technical debt? It accumulates over time and someday you either give up or decide to crush it. In my case, it was the later. You probably heard that optimizing UI in Unity is challenging. Or, if lucky, you know it from first-hand experience. Yes, Unity UI is a powerful tool and I love it. However, its mightiness can quickly transform into a deadly weapon if it falls into inexperienced hands. And so were my hands back then. If I had to confess anything to you today, it would be this: I wished I had had a solid foundation on Unity UI before I designed the UI of several games. It is SO easy to do it wrong, SO easy to get frustrated. In my opinion, there's something even easier than that. That is, for your client to ask you to do over-hours to get your shit together. In my experience in the professional sector, companies do not want developers who design poorly optimizable interfaces and leave the tuning task to experienced programmers. They rather want developers who create visually stunning interfaces, but also performant. And even in the indie development scene, where would you choose to spend your time on? Bringing fun to your players, or spending hours clicking through the profiler to find bottlenecks? In my opinion: no matter your role, you should understand basic Unity UI design principles. But this takes time and project experience. You might not have any of these. Hopefully, I can help you there. Today, I will give you one of my most powerful tools: The Guru's UI Development Diagram As usual, I'd like to start with the Level 1 Developer construct Level 1 Unity UI Developer: UpdateBatches & Layout Spikes in Unity UI Level 1 Unity UI Developer: free-style UI This is where we all start: free-style design, free-style results. I used to import sprites with whatever settings. Then, I would add them as images everywhere with no predefined criteria. And so I ended up with an unstructured hierarchy full of components that I didn't need. I used the wrong systems for the wrong reasons. Overlapping UI elements, a motherload of batches, profiler spikes. Those are all common. Do I have anything against this? Partially. I think it is great to play around and to make mistakes. Breaking and repairing help learning. But if you want to do this for a living, at some point you might want to level up your skills and embrace professionalism. This becomes unacceptable in the games industry, especially in Virtual Reality. If you do this in VR you will turn players into patients. Such a chaotic Canvas hierarchy structure could look like this: Level 1 Unity UI Developer: Unstructured Unity UI Hierarchy You do a lot of nesting, you use auto-layout components everywhere and there is a lack of rules. At some point, someone will ask you to optimize your UI. That could be your players, your boss or even your own pride. But you might not be ready for this. You might be caught off-guard having other tasks on your plate. And UI development is daunting at the beginning. The reason for its complexity lies in the amount of factors it involves. Leaving the visual appeal aside, you can say that the way you work with Unity UI will have a big impact in three critical hardware pieces: the CPU, the GPU and the developer theirself. If you are lost, it's good, because... I am about to show you something cool Let's level up as a developer! Level 2 Unity UI Developer: The Guru's UI Development Diagram Level 2 Unity UI Developer: The Guru's UI Development Diagram Here we are with a Venn Diagram. I decided to call it The Guru's UI Development Diagram. There we see three big chunks related to Unity UI Optimization: CPU, GPU, and Developer. Those are the main resources you will have to spare when developing UI. I want to give you a short overview before we start digging into the topics. You pay the CPU toll mainly when generating and submitting batches of UI. You can think of them as UI components, such as images. The more of those you have, the more strain you will put in your processor. The turn for the GPU. You pay the GPU resources mostly in concept of overdraw. This means, stacking layers of graphics on top of each other. Lastly, the developer's pain is paid in time. You spend time every time you design or maintain your UI. Unity offers you some tools to make it easier for you, e.g. auto-layout helpers. The cost of the three components rely mostly on you, but they sometimes counteract each other. It's very challenging to perform in every aspect, unless you are very experienced and you have the right tools. Eventually, you will get there. I would like you to have a closer look at the attached Guru's UI Development Diagram. You might be confused. That's alright because we are going to cover each section separately. You will get to understand all of it. For now, you only have to understand one thing: in the end, it will be up to you to find the balance between the three variables in your game. Before we start with each component, have a look at these general rules: The easier you want the UI design workflow to be, the less performant your UI will be. If you want more GPU performance, you will have to focus on finely tweaking graphical elements and avoid element stacking. For more CPU performance, you will need to reduce the amount of graphical elements present in the hierarchy. Let's move on, I can't wait to show you the CPU side of Unity UI Optimization! Level 2 Unity UI Developer: The CPU Level 2 Unity UI Developer: The CPU In my opinion, this is very simple. The golden rule is: Every time you add a UI component in your scene, you are adding CPU overhead Each component increases the CPU cost for the following reasons: RectTransform calculation: this is pretty much free in simple canvas hierarchies. However, your CPU will have a harder time if you are using auto-layout components to ease your UI design workflow, such as vertical layout groups and such. The issue with those is that most RectTransforms present in the hierarchy will now depend on each other, so the calculation becomes more complex. Vertex generation: the GPU understands vertices, thus those must be provided by the CPU. Vertices must be generated based on the entire canvas hierarchy of the involved RectTransform elements. The vertices depend as well on the specific type of UI element you added (images, texts). Under this category, we also include the cost for the CPU to add other per-vertex attributes such as colors and UVs. Dynamic batching: because draw calls are expensive, Unity does its best to dynamically batch as many of them as possible. Think of this as combining a large number of small groups of vertices into a single, huge group of vertices. Because... would you rather go to the supermarket ten times to bring an apple each, or go just once and grab them all together? Batching is, however, an expensive operation for the CPU which increases with the amount of UI elements you have. Draw call emission: finally, the generated batches must be sent to the GPU. These graphical processing units are very picky with the data formats they accept, so the CPU has to make extra work to pack them in a way that they like. This is expensive, yes. But luckily for us, Unity is kind of smart and caches the canvas so these expensive processes do not happen in every frame. Just as I brought you good news, I will give you the bad ones: this cache is super easy to break. Changing almost any attribute of any UI element will break the cache of your canvas. If that happens, we go through most of the process again. These changes, by the way, trigger what is called a canvas rebuild. I'll give you some examples of the breaking changes: scaling, positioning, rotation, color, image swapping, animations and more. After exposing the basics, I want to conclude with three practical observations: The more elements you have in your Unity Canvas, the more CPU overhead you will have on each canvas rebuild. Avoid any kind of changes in UI to avoid canvas rebuilds. If needed, then put dynamic elements in different canvases. Canvases are either static or dynamic. Design accordingly. Level 2 Unity UI Developer: The GPU Level 2 Unity UI Developer: The GPU Now is the turn for the friendly Graphical Processing Unit, don't you think? The GPU is the piece of hardware that makes us fall in love with games. We owe them so much. What about showing it some affection? Well, we can... By treating it well. But guess what? UI can make the GPU pretty upset. Especially mobile GPUs, where it is relatively easy to be memory-bound. To put it simply: In mobile, there is a massive reason UI is expensive: overdraw! Overdraw happens when we render the same pixel multiple times per frame. And this is soooo easy to achieve with Unity. Every time to add a Unity UI Image, you are commanding your GPU to draw a full rectangle, rendering every single pixel inside that rectangle. And it does not matter if the pixel you are drawing is transparent, it will cost you still. That means, I advise you to be careful with the transparent regions of your sprites! This has some implications for you. If you add 10 full-screen images, then you get 10x overdraw. As my grandmother used to say, WTAIWYG! (What You Add Is What You Get). Stacking of layers on top of each other will slowly enrage your GPU. It will add milliseconds to it, which is a crime in VR games where your budget could very well be under 13ms. I do not want to get too technical in this post... but I can't just help it! Some day you will be having a delicious coffee break conversation with your colleagues and you might feel tempted to drop a few intellectual lines. If that's the case, say this one aloud: UI Overdraw is expensive in mobile because you devour the precious memory bandwidth of the device and this is further worsened by the alpha blending happening internally You'll make some jaws drop. The key lesson is easy: avoid stacking UI elements on top of each other and you will be fine GPU cost mainly comes from stacking graphical layers on top of each other. Avoid these. Reduce the space UI takes in screen to reduce GPU cost. Implement sprite atlasing to improve CPU and GPU performance. PRO TIP #1: Sprite Atlasing (opens in a new tab) PRO TIP #2: Opaque UI Shading (opens in a new tab; Advanced) Level 2 Unity UI Developer: The Developer Level 2 Unity UI Developer: The Developer! I am afraid we often under-estimate the effort required to design, implement and especially maintain optimized user interfaces in Unity. Surely, Unity improved in this area during the last few years and now it is easier and faster than ever to create those. But this comes at a cost. In general, the more Unity UI extras you use, the worse your game will perform. The auto-layout helpers are especially expensive. Unfortunately, they are the most helpful. For instance, I find Vertical Layout Groups especially handy when designing responsive UI. These neat scripts help you organize your elements in a manner that is structured and therefore visually appealing. The problem I see with those is that they incur on a big CPU cost whenever there are canvas rebuilds! You might be able to get away with UI helpers if your UI is static 99% of the time, but the frame it isn't, you will notice it. We love working with helpers, but we don't want to ruin our performance. Here's one trick you can try: keep the auto-layout helpers around while designing but disable them all just before saving your scene. By doing this, they will be deactivated for run-time players, but they already did their work for you! I don't want to disappoint you, so just remember that this auto-layout disabling secret will not work if your UI content is dynamic. At the end of the day, the more tasks you delegate to Unity, the more work your hardware will have to do. Find your own balance here! You can start using those helpers but be ready to remove them if you have to. While optimizing, do the biggest gains for the buck first. Only advance in the ladder of diminishing returns if the profiler tells you that you have to. For instance, creating sprite atlases is easy and will bring you good fortune. Tweaking graphics to avoid transparent regions, however, is more time-consuming. Lastly, creating your own UI shaders might bring you big gains but at a big cost. Remember, saving a few microseconds in your game might not be worth if it costs you weeks of your life-time and your application does not need it. This should not be taken as an excuse to never care; optimizations in the future are more expensive than in the present. Profile before you optimize Keep profiling Go for the biggest gains for the buck first Level 3 Unity UI Developer: The Guru's UI Development Diagram Level 3 Developer: The Sweet Spots From the Venn Diagram, you might see several sweet spots where you could find yourself in: Fine-Grained UI Development, Coarse-Grained UI Development, Massive PP and Balance. They sounded quite obscure to me at the beginning, but then, with time, it all started to make sense to me. Experience brought understanding. What I still hold true is that, the more tools you know, the better. This is the main way I am able to recognize the subtle patterns in all problems. And, when you recognize the heart of the challenge, you know which tool to take out of your toolbox. Nothing will help your team more than having a developer possessing both a high-level overview of UI and an eye for detail. A Level 3 developer would confidently answer important practical questions that only come through experience. I can think of a few that any client could ask you: Here's a UI architecture for you. How performant is it? What are 3 alternatives I have to optimize this user interface? Can you show me numerical proof? You see, I prepared a few Unity examples for you. The examples you will have access to illustrate each of the UI optimization methods I propose. Not only that, I analyzed them all so you can feel safe the information is accurate. Because... do you know what comes after speaking out of our gut feelings? Speaking with certainty, based on real experience. So, are you serious about becoming a Level 3 Unity UI Developer? ---> Grab Now the Level 3 Guide from my Blog Post.
  3. Project Name: Condors Vs. Ocelots Team Size: 15ish Genre: Strategy RPG Engine: Unity Roles Available: Game Designer 3D Artists - generalist or hardsurface w/textures 2D Artists - Characters, World, and UI Social Media/Marketing/Community Manager If you feel as if you can offer the team something more that isn’t listed, we are always open to making an exception, just send your resume/portfolio to us! Project Length: Currently planning on release Q1 2020. Compensation: Rev-share Project Status: Dev is in Full Swing and our Kickstarter reached 100% http://kck.st/2JNCiFn Send emails to careers@titanomachystudios.com Must speak English and have access to a Mic. Our store page can be found here, https://play.google.com/store/apps/developer?id=Titanomachy+Studios Our website here, http://titanomachystudios.com/#/ Project Story: Condors and Ocelots have been at war for generations. Battles have left some settlements in ruins. Others teem with refugees. Even away from the fighting, towns and villages suffer from having their fighting-age citizens lured away or conscripted by one faction or the other. Players control their armies and try to wipe out their opponents! Use terrain, abilities and pure cowardice if need be to achieve victory for your faction!
  4. This is a very straight forward method to achieve this effect. The area behind the rock is walk-able and will hide the player in the render order and the front will show the player on-top. I've been very happy with the way the tilemaps are working in unity, once you get used to it they really make sense. Getting your character to appear in front of and behind objects is done with splitting the sprite in half and putting them on different layers. The important part is adjusting your box collider on your player so they never clip through these objects, this is what we're using for ours: Our player sprite is 16x32 and I typically split all of my tilemaps into 16x16. The sprite renderer on the player is important too, the "player" sorting layer is in front of the default layer. Our bottom layer just needs to be on the default layer and have a collider; just stamp that bottom layer in there. Our top layer just needs to be a higher value than our player. If you're using tilemaps and you're going for this top-down RPG aesthetic I think you'll get a lot of mileage out of this method to really bring out depth.
  5. Hi we are a team looking for a sprite artist for a game project. we need someone to assist in maing the sprites for the player character as well as the bosses for the game. after some discussion it will be a 2d game in common with castlevanai or metroid. we want to go with a more comic over the top feel of the story we got a concept artist so we got sketches and images to work from in terms of what we want. pixel sprites will work for us. also this is a revenue share project as we intend one way or another to get this published in in that regard share the revenues we get between the ones on the team
  6. Hi we are two people working on a 2d beat em up game called hot chick and cool girl. We are looking for a sprite artist to create our key characters for the game. Here is some concept art for two of the characters and we will have more in time. Let me know if interested We got a rough outline and a intention o something close to 15 stages for the game.
  7. Unnamed Item Shop first month In this devlog we'll be discussing the various aspects of what we did in our first month of development. We'll cover important things like what we accomplished and how we set our expectations and processes to get the most out of the time we had. One of the first things we did to give ourselves a very vague direction was to make a few statement about what the game was. We first came up with the very baseline statement: "You run a fantasy item shop". As long as the game meets those expectations, we were on the right track. Instead of trying to rigidly force the game to be something, we are creating the systems one by one to enhance our first main idea. Things We Accomplished: Art: One of our big challenges was coming up with an art style we liked while also keeping a resolution and feel that would be easy enough to do within our time limit. We were initially thinking about doing a 32 pixel base size, but ended up going with a 16 base pixel size because we were able to get plenty of detail and style. Not to mention the characters came out looking absolutely cute. We're doing very well on the amount of sprite sheets we have already created with enough assets to make the entire player's shop, most of the exterior scenes and a few of the other interior scenes in the game. Since the pixel art represents basically every aspect of the game, this section can be summarized as: Everything you can see, is the art we've accomplished. Systems: We started creating systems for the game by layering various managers over each other as well as other independent systems such as character movement, pause functions and camera movement. Keeping these systems completely separate proved to be incredibly useful earlier this week. We were faced with a major refactor of the inventory system, it was the first thing I started working on with the game and since it's my first unity project it had several issues. A refactor was in order and because the systems were so independent, after I ripped out the entire inventory system all other systems were functioning fine. The shop system was also working pretty well, customers will walk around the player's store visiting a random amount of points of interest before deciding if anything in the shop is worth them buying. The user is also able to set custom prices on each item in their store, which works really well both in the fantasy of the game and as a mechanic (Also note the placeholder icons 👍) . All of our UI components are also broken out into prefabs, which makes it incredibly easy for our UI manager to perform all CRUD operations on them. Guilds, a fairly major feature in the game, are also implemented (although I only have 2 coded at this point). Each one can consume or produce resources and each interact with each other based on those resource production/consumption. It's currently in the air if we're going to do guild reputation at this point. Summary Overall I think we were able to get a lot accomplished, especially considering the fact that this is our first month of development time. We had a lot less direction and far fewer goals in the beginning, but now that we're under way we really are just blasting along. I think one of the most important things for us was to set an impossible development time, while keeping the focus of the game razor thin. If we get to the end of that development time and there's something missing or the requirement to add more systems we can easily add additional development or testing time. Also since we're beholden only to us and what we want to get out of this game we're not burdened with meeting other people's expectations. The first month has been very eye opening. Learning new software, learning a process that works for us (as a two person team) has all been really cool and we're looking forward to the next month of development.
  8. jbadams

    Free art assets

    The older version of this topic is getting quite dated, with some broken links and notable omissions, so after 8 years it's high time for an update. This is a list of free graphics for games but aims to avoid sprites ripped from existing games in favour of ones that may be legally used in your work. Please feel free to submit your own suggestions, but note that any off-topic posts and all spam may be removed from this topic. Be sure to check the licensing terms before using any of the linked graphics. Free Airplane Sprite Pack A free .zip package right here on GameDev.net containing various aircraft from different (mostly side or top down) angles. Includes fighter jets, bombers and cargo planes. Provided by our very own (but recently inactive) @Prinz Eugn (Mark Simpson). Free for any use with attribution to the author. Kenney Assets A huge collection of freely available assets (both 2d and 3d) for many different styles of games, available under CC0 1.0 Universal licensing terms. In addition to the free assets, Kenney's work is supported by the sale of cheaply available asset packs which you'll find linked at the top of the page, and the fantastic Asset Forge which allows the easy creation of customised game assets. SpriteLib GPL A free .zip package of 2d games sprites by Ari Feldman, now available under a Common Public License Version 1.0. Unfortunately, the original website is no longer online, the source website is back online HERE, but the sprite package is attached to this post for you to download: spritelib_gpl.zip Contains sprites for a platform game, Pong/Breakout/Arkanoid style games, overhead shooter in the style of 1943, and a maze combat game in the style of Tank Force. Lost Garden Freely provided graphics from Daniel Cook of Lost Garden & Spry Fox, under licensing terms explained on this page. Danc's Miraculously Flexible Game Prototyping Tiles Danc's Miraculously Flexible Game Prototyping Graphics for Small Worlds 250 free hand-drawn textures Tyrian ships and tiles Tiles for Zelda-like RPG Complete set of 8-bit Sinistar clone graphics Unreleased RTS Postmortem: 'Hard Vacuum' (graphics near end of post) In addition to the above, Daniel also has a couple of 'Game Prototyping Challenges' where he provides the basic outline of a game design and challenges people to implement and iterate on the design to hopefully create a fun game. A couple of these challenges come with freely provided graphics, although in this case the assets are intended for use if undertaking the challenge (a fantastic learning exercise!) in question rather than for general use: Prototyping Challenge: Play With Your Peas Prototyping Challenge: Fishing Girl Glitch - Public Domain Art (and code) All assets from a defunct web-based MMO game, made freely available under CC0 1.0 Universal licensing terms. Get it HERE. Most of the graphics are available in .fla and .swf formats. Quaternius Quaternius offers a large range of basic low-poly models with CC0 licensing. You can also support his efforts by purchasing all of his sets in a single file for $1. OpenGameArt.org OpenGameArt have a huge collection of different art, constantly added to by new and existing contributors. Quality and style vary, but there is some really good material available if you're willing to spend some time looking. Note that licensing terms vary, so be sure to check each item's license before use. Game-Icons.net At the time of writing, Game-Icons.net offers 3044 free icons in SVG and PNG formats with CC BY 3.0 licensing (which requires attribution). The built in editor on the site will allow you to alter the icon size and apply some simple properties (such as background type and colour). AI War 2.0 graphics library Graphics from the space RTS game AI War: Fleet Command. Free for use by indie developers. Get it HERE. Reiner's Tilesets 2d and 3d graphics (use the menu at the top of the site to view categories) available under these licensing terms. MakeHuman MakeHuman is an open source (AGPL licenced) tool for creating 3d characters. Output characters can be used under a permissive CC0 license under certain conditions. GameDev.Market There are some free assets available via the GameDev Marketplace (our very own asset store!). Looking to hire an artist for custom work? Check out our Contractors section, or advertise your project in our Game Jobs board (for paid commercial projects) or Hobby Classifieds forum (for free hobbyist projects). Looking to purchase pre-made assets? Try the GameDev Marketplace, or other asset stores such as GameDev Market (not affiliated with us!), the Unity Asset Store, the Unreal Marketplace, or others.
  9. Project Name: Condors Vs. Ocelots Team Size: 15ish Genre: Strategy RPG Engine: Unity Roles Available: 3D Artists - generalist or hardsurface w/textures 2D Artists - Characters, World, and UI C# developer/engineer(s) Social Media/Marketing/Community Manager If you feel as if you can offer the team something more that isn’t listed, we are always open to making an exception, just send your resume/portfolio to us! Project Length: Currently planning on release Q1 2020. Compensation: Rev-share Project Status: Vertical slice is done and iteration development has begun. Send emails to careers@titanomachystudios.com Must speak English and have access to a Mic. Our store page can be found here, https://play.google.com/store/apps/developer?id=Titanomachy+Studios Our website here, http://titanomachystudios.com/#/ Project Story: Condors and Ocelots have been at war for generations. Battles have left some settlements in ruins. Others teem with refugees. Even away from the fighting, towns and villages suffer from having their fighting-age citizens lured away or conscripted by one faction or the other. Players control their armies and try to wipe out their opponents! Use terrain, abilities and pure cowardice if need be to achieve victory for your faction!
  10. In my game I have multiple sprites and I want to apply my shader to them. I do things by this sequence: Create Shader -> Create Material -> Add the shader to the Material -> Add the material to my sprite(s). But when I add my shader to the material, images get started looking like below. What I do wrong and which way is right? P.S. I create Unlit shader and do not change nothing inside it. Before applying shader After applying shader
  11. Hello everyone! I'm an artist from Transylvania creating artwork for video games for a few years now, with a passion for dark fantasy and old school RPG's like Diablo, Gothic, Arx Fatalis etc. In the past few weeks, I've decided to try this idea of a mobile pixelart RPG , and started to develop some practical workflows for creating artwork and content fast. It's a story driven RPG with tons of loot and a world to explore. Very similar to Diablo II. I already have a lot of lore and items from the past project set in the same universe, and i'm using some already 3d models as render reference, for a realistic look. Environment concept: (Click for best quality) Character Animations: UI early concept: (Click for best quality) The approach is a practical one, with focus on building something playable fast and launch it to see the user feedback, and keep adding more content and mechanics. All the content shown has been made in less than 2 weeks of work. The level design workflow is tile based that seam together. The file size is also small, with 1 tile being 32x32 pixels. I decided to skip walls which saved a lot of time for more items, objects and animations. With this workflow I can create huge maps relatively fast. All the sprites are done on minimum size then scaled, so the original images are very small, thus allowing for more memory in other areas like special effects or simply more content on the screen. The simplest start is adding a combat and inventory system and go from there. I have some inventory system packs from the Asset Store and a dialogue pack from a friend who's a programmer. I'm looking for a programmer with experience with Unity to make a team and build a prototype quickly and see how it goes from there. If it has good reception we can keep adding more content. The plan is to make the game a free mobile app with ads and in the future experiment with other revenue systems such as cosmetics, but not pay to win features. Hit me up if you're interested, for more details. Discord handle: Hermit#8917 Skype: andyblahblah1 Email: andy.austin.johanse@gmail.com
  12. Hello friends! I've got a new blog posting for my upcoming 2D pixel-art samurai fighting game 13 RONIN. This time I'm talking about back