Jump to content
  • Advertisement

Dev Blog #06 – Art Evolution of SAMA

Sign in to follow this  
RoKabium Games

1206 views

Art Evolution of SAMA

As the solo and lead artist for the indie studio RoKabium Games and working on the first game of the studio called “Something Ate My Alien”, the amount of different images I’ve created and modified for this game goes well into the many thousands.  As I’m writing this blog my file number of different assets, concepts, backgrounds, logos and promotional artworks is just over 6000 files. For anyone that does not know what goes into making a game it is easy enough to not fully grasp the amount of content needed to make even a smaller but full, visually pleasing and fun to play game that has all the mechanics needed to function properly and look good.

We have been developing this game for the last 2 years and have finally come to the stage where we’ve let a few people try out the game and give us feedback during a private alpha release. At this stage of development most of the game is finished and we are tweaking, adding and changing things to make for clearer and smoother game play before releasing it as general alpha where more players are needed to test the game. Since we have reached this point I thought it would make for an interesting read to visually see the development of the game up until this point.

The overall art style

Menu old and new

I was so in love with the art style of games such as “No Man’s Sky” and “Firewatch” and wanted to create something similar for this game with a retro-feel to the palette and style. This game was to be a reminder of the early classics such as “Boulder Dash” and “Spelunky” but with some more exploration/adventure  tossed into it slightly reminiscent of the first Zelda games. We wanted  future players of SAMA to feel a connection to these earlier classics but with a smooth, painted, beautiful style that had a “hand painted stroke by stroke” look. Very early on we knew we wanted to create a game with keywords such as fun, classic, hand painted, quality, beautiful.

The GUI and HUD

GUI teleporter old and new

Despite the brush painted style on the different worlds, I did want to keep the retro palette and clean interface without too many fillers or decorations that could cause distraction on the GUI. You as the player are the main AI running the mining ship that in turn sends down the Aliens to dig on the planets, so the AI part of the game play needed to have a distinct and more simplistic look than the dynamic, living world the Aliens would move around in.

At some point we did add a bit more of the painted backgrounds used for the Menu and loading screens into the back of the GUI since the difference between the very bare GUI and the planet game play seemed too different and the merged result from combining the two extremes is what made the most visual sense.

The main concern with the HUD was to display all the info you need while mining, such as health, oxygen levels, inventory, messages that the AI need to relay to you, mini-map etc without interfering or covering too much of the game play area of the screen. This itself proved tricky and we made lots of changes to this, testing out different ideas during the last 2 years. Finally the layout we have currently is the one we find the most pleasing but even so we’ve made it re-sizable so that players who want more or less game play area outside the HUD can set that.

GUI teleporter final

The Aliens

In the beginning as the game idea was merely some sentences and points on a few pieces of paper I started sketching what we thought would be the main character which was the Alien. The first concepts were made to decide which idea to build on.


Aliens early concepts

As you can see below the first idea was an actual retro style human-like astronaut and it was not until a bit into development once the story was fleshed out properly that we wanted a more unfamiliar and not too realistic (since the Alien would be the second character and be disposable) look. We wanted something unknown but appealing, something more simplified that would speak to people of all ages but that you as a player wouldn’t get too attached to.

This is when the current Alien was born.


Alien evolution SAMA

The Levels

Tiles old and new

The ground on each planet in SAMA is supposed to be bedrock that can be mined by the Aliens, and early on we decided we wanted seamless tiles to build up this bedrock rather than individual blocks that was more prominent in the early classics. The first tiles were extremely simple, but we decided to move towards more of a hand painted style for the whole game quite quickly and looking back I’m really glad we did that. This style makes the game feel so much more immersive and gives a sense of quality in my opinion.

The cave backgrounds

Each planet has a specific colour theme and environment and these were set quite early on in development. The far backgrounds behind all the front tiles were to set a nice, ambient parallax look to the underground, and the very first and rough paintings of the back is very different from the final, meticulously painted ones we have today.

Resources - artefacts and fossils

The resources and puzzle chambers were the only things I designed that would not be unique to any one world. These things needed to be uniform all over the game play areas since as a player you need to recognize these things across the planets. The look for the various resources was developed very early on and has more or less stayed the same throughout development and pretty much the same goes for the puzzle blocks.

Level development old and new

The Wildlife

We wanted to use the environment itself against the player such as the need for filling up oxygen, emptying the backpack when full, falls or ending up in liquids etc. But we also needed dangerous wildlife that would be more interactive and seek the player out.

Some of the first concepts of animals were a bit wild, but after realizing the amount of animations needed for each animal and for me to make those animations without having much experience at all in animation work before this, we had to settle for creatures that had somewhat easier or easily referenced movements. Based on that I came up with a range of wildlife (enemies) that has been added to more recently to get between 8-10 different ones for each planet.

Arrog old and new

Each planet would also be guarded by something huge, a part of the wildlife that would be so dangerous it would possibly be able to eat the Alien whole. Something that would appear from time to time and then inevitably lead to some kind of confrontation/battle and so the “Somethings” or monsters/dragons/terrators/bosses were born.

Early Something concept

The evolution of the Something has been pretty significant as you can see in these images. We had some problems coming up with how these big things would move on the screen. At one point the idea was that the big bosses would come out from the back wall and eat the Alien that way, but it just looked terrible. We weren’t sure how something going across the screen would look since really there is bedrock in the way, but in the end the visually pleasing and game play aspect of that kind of movement won over “realism”. Hey, it is a fantasy game set in a fantasy world with the bedrock depicted in a 2D platform style on the screen, who says a huge creature can’t move through it all as it pleases?

Something old and new

Hope you have enjoyed this look at how the art within the game SAMA has developed over the last 2 years.

 

View the full article

 

Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Ruben Torres
      [The original post with its original format can be found here]
      Players want to play, they don't want to wait. Help them buying your game: reduce your game's download size with Unity Addressables Hosting. And a year later? Offer them a DLC based on, guess what? Addressables.

      Picture your potential player on a Friday afternoon.
      Your player has just left behind a hard week with long working hours. Their wife or husband is gone to their family's country house for the weekend along with the kids. The perfect time to go home, order pizza and browse through Steam with the wallet at hand.
      With or without kids, with or without partner, we all had these awesome weekends.
      Just videogames, please.

      So your player comes across your newly released game in the Steam shop. They see all the effort you put into creating polished content.
      No need for convincing, they hand in their credit card details and buy two copies of your game. One for theirself, another for their friend / brother / sister.
      You get your 19.95 bucks, twice. Both users happily start installing the game.
      But wait...
      A wild Steam installation pop-up appears.

      The remaining installation time suddenly exploded to 12 hours
      What, 12 hours for over 30GB? What the #*@! is in this game?
      I'm not wasting my weekend on this shit, I'm out!
      What happens afterward is not uncommon.
      Your ex-player requests a full refund and purchase instead the next game in their wish-list.
      One of the pain points for players is the waiting time wasted on downloading all the bytes of the whole game and start playing. People do not have that much time. Nothing will burn a hole in your wallet faster than an angry player.
      Do you need to include in your installation package all these assets that are spawned in the level 5 of your game? Chances are, you don't.
      Players will need a couple of hours to play through the initial content of your game. Use that to your advantage
      The idea is simple.
      Provide the minimum content possible in your game installation package and download the rest while playing the initial levels of your game.
      Can you picture your player ready to play in a mere minute after purchasing your game? How different would the reviews be compared to the ones commonly found with huge games?




      Ideally, your game's download size should be below 100MB.
      But how?
      This is what you will get by the time you're done implementing the information of this article:
      Ridiculously tiny installation sizes A new Amazon S3 bucket to host your content online Upload Unity Addressable Assets to S3 through the Unity Editor Download the Unity Addressable Assets from the S3 bucket in your player builds A high-five from your happy players
      Fox / Via mashable.com
      Level 1 Developer: "Storage is cheap, anyway"
      We started developing our game a few months ago and we have big plans for it.
      You and I worked endless hours into creating highly polished content.
      Not only that, we saw some great offers in the Unity Asset Store, so we bought several asset packs at heavily discounted prices.
      Now our game is full of content our players will love to play through. Those Sci-Fi modular parts, the exploding particle systems, the punchy soundtrack.
      It's all gorgeous. 
      And heavy.
      And slow to download.
      Now your Android APK is well over 2GB, so you need to start messing with expansion files, which adds another good week to your efforts. But it's fine, we all have time here.
      Or maybe you're publishing on Steam, so you can be at 30 GB, no problem. You just need a few hours for uploading it. And players? It's ok, people have a fast connection nowadays.
      So we released our game. Some players reported some bugs, so we make a 5-minute fix and we go through all the long process again. Build, wait for hours, upload to stores, wait for hours.
      And our players? They just re-download the whole thing again. Wait for hours, then start playing.
      It's not a big deal.
      Only that you are not recovering all the time you wasted on this previously. And a great deal of your players will stop downloading your game once they see how many hours they have to wait. That only gets worse with each update. Did I mention refunds?
      We can do better than this, now that we have the tools.
      Let's upgrade our skills to Level-2.

      Level 2 Developer: Unity Addressables Hosting
      Welcome to Unity Addressables.
      This package will allow you to efficiently manage your game assets. That, my friend, includes online distribution. For an introduction on this topic, visit my previous article on Unity Addressables Benefits for your game.
      These are the steps you and I will be following in the article:
      Set up an Amazon S3 Bucket for online distribution Mark our content as Unity Addressable Assets for online distribution Upload our content to the cloud Profit from tiny installation sizes (and others) Like granny said, a 2D sprite is worth a thousand times:

      Unity Addressables Hosting with Amazon S3 - Steps
      Let's start with...
      1. Setting Up a Free Amazon S3 Bucket
      It's our lucky day. Amazon offers a free tier for their S3 service.
      That means, we're going to host our content for free. The limitations for their free tier is mostly storage space and the number data transfers. At the moment of writing this, you can store for free up 5GB and perform 20,000 GET and 2,000 PUT requests, but do double check it in the official site of AWS Free Tiers.
      What we are going to do here is to create an account for AWS so we are ready to upload our game content for further distribution.
      You and I will do this as fast as possible. No need to waste time in detail. No BS.
      Setting up Amazon S3 Hosting for Unity Addressables
      1.1. Create AWS account
      Navigate to the AWS Management Console and click on Create a Free Account.

      Enter your e-mail and bla bla bla. That will take you roughly a minute.
      Be aware that you'll need to give them your credit card info to verify your identity.
      1.2. Choose AWS Plan
      Unless you're going pro right from the start, we want to evaluate this in our game first.
      So, after confirming your account, choose the basic plan.

      1.3. Create your first S3 bucket
      After a few minutes, your account will be activated (you'll get an e-mail). Then, sign in to your new console and open the S3 service panel:

      You are now located at the S3 control panel.
       
      Now we are ready to create the bucket like shown below (change your bucket name and region!):



      Leave the permissions set to public for now, you'll have the chance to tweak them in the future.
      Your S3 bucket for Unity Addressables is now ready, congratulations!
      That was the most tedious step.
      The next step is a piece of cake: time to get your Unity Project to produce downloadable assets.
      Summary:
      Use the AWS Management Console to create a Free Tier S3 Bucket For starting, assign public permissions to your S3 Bucket Alternatively, use another storage service based on the spreadsheet in the Resources Pack
      2. Unity Addressable Assets for Distribution
      Finally, we made it to Unity. That whole S3 process was getting old.
      I will assume you have some content marked as Addressable in your game. If that's not the case because you are new to this, don't worry, I have you covered with the previous Unity Addressables Tutorial I wrote.
      I'll show you the steps to get content uploaded in your newly created AWS S3 Bucket. We will do so based on a project I created for this purpose.
      Instead of following the whole story, you can also skip the line, get access to the code now and read later.

      Unity Addressables - Profile Settings
      A. Addressables Profile Configuration
      The way to start is to tell Unity where to load remote assets from.
      That we achieve by tweaking our Addressables Profile Configuration. In the Addressables main window, click on:
       Profile: Default → Inspect Profile Settings.
      This will redirect you to the settings we need to tweak.
      Here is a collection of funny toys you can play with, but for our purposes we just need to focus on the Profiles section.
      We want to make sure we set the Addressables RemoteLoadPath field to the correct URL.
      We form the RemoteLoadPath URL by concatenating our S3 Bucket URL with the Unity variable [BuildTarget], like below:
      https://YOUR-BUCKET-NAME.s3.YOUR-REGION-NAME.amazonaws.com/[BuildTarget] E.g. https://thegamedevguru.s3.eu-central-1.amazonaws.com/[BuildTarget] The [BuildTarget] variable is left on purpose so Unity fetches in run-time the right assets for each of the platforms we build for. Android assets will be packed differently from Standalone, so each of these platforms will require a different directory.
      The way I found my S3 Bucket URL is by uploading a random file; if you then navigate to its details, you'll see the base URL of your file and hence your bucket.
      B. Addressable Asset Groups Configuration
      So, we just told Unity where to load the remote assets from through the RemoteLoadPath variable.
      Great. What is left is to tell which assets should be loaded remotely. Easy.
      Go over the heavy assets you want to be downloaded remotely and mark these Assets as Addressable. In our case, it's the skybox materials. Open the Unity Addressables Window and assign these assets to Addressable Asset Groups. If you are just starting with Addressables, assign them to a single group for now; e.g. Skyboxes. Eventually, you'll want them to be grouped in a way that makes sense (check my Level-3 guide on Unity Addressables Tutorial for more info). Navigate to the Addressables Group inspector settings by clicking on the group and make the following adjustments: BuildPath is set to RemoteBuildPath LoadPath is set to RemoteLoadPath You can see a graphical breakdown of this entire process below.

      Asset Groups for Unity Addressables Hosting

      Unity Addressable Asset Group Settings for Network Delivery
      We now have our skybox content assigned to a group that will be downloaded by your players in run-time.
       Summary 
      Set RemoteLoadPath to the base URL of your web hosting provider Append the [BuildTarget] variable into RemoteLoadPath  to differentiate multiple platforms Assign your Unity Addressable Assets to a group and tweak its settings to use the remote paths so it'll be downloaded from your web hosting provider  

      3. Uploading Content to Amazon S3
      All our settings are now in place. What about uploading our content to S3?
      This is a simple two-step process:
      Build player content. Upload it to S3. Building Addressables Player Content is straightforward. Open the Addressables main window and press the button that does just that. This will cook the assets for the current platform your editor is in. 

      Unity Addressables: Build Player Content
      The output content will be stored in the path dictated by the RemoteBuildPath variable you happened to see early in the Unity Addressables Profile Settings. If you didn't modify it, it's likely to be in a subfolder of your project called ServerData.
      The second step involves navigating to that directory and dropping its contents into the website of your S3 bucket, as you can see just below:

      Unity-Addressable Assets - Upload to S3
      There you have it, it's that simple.
      However, this can quickly become tedious. It's a very manual task that could easily be automated. I did just that so now uploading all my assets takes the press of a button inside Unity Editor.
      To upload your Unity Addressable Assets directly from the Unity Editor, check my Unity Addressables Hosting Resource Pack at the end of the article.

      4. Downloading Assets from Amazon S3
      This is the part we all were waiting for. You now have a game you can distribute that is significantly smaller. The remaining part is launching it and watching it download the assets on demand!
      If you want to make sure these assets are being effectively downloaded, delete the data from your S3 Bucket, disable the caching option in your Addressable Asset Group Settings, rebuild the content and your player. If you launch it, you should see a few error messages pop up, as you can see below.

      Unity Addressable Assets Download Error
      If you followed this tutorial on Unity Addressables Hosting, chances are, you will be totally alright
      By now, the asset groups you marked to be remotely downloaded are hosted in S3 and Unity knows how to fetch them.
       

      The Gamedev Guru's S3 Upload Tool
      Level 3 Developer: Unity Addressables Hosting Resource Pack
      By now you should have your first Unity Addressables Hosting experiment up and running.
      You learned how to build player content specifically to target downloadable content.
      That's great, but there's more than just the basics. To help you further, I prepared a Free Unity Addressables Hosting Resource Pack just for you.  This bundle contains:
      A spreadsheet comparing different hosting alternatives to the pricey S3 An extension to upload your Unity Addressable Asset to Amazon S3 directly from the Editor The source code of this project; see it for yourself Newsletter access with exclusive free content Level up your skills. Download your free Resource Pack now.

       
    • By ToeBeans The Brave
      Hello everyone!
      I'm new to programming and pixel art, and I would greatly appreciate hearing some feedback on my Idle and Running animations. I'm looking for constructive criticism so that I can become better at making sprites in the future, so don't hold back!


    • By ThinkSmall98
      Hi, 
      I used the 3D shortest distance between two line segments algorithm at this website: http://geomalgorithms.com/a07-_distance.html#dist3D_Segment_to_Segment
      This function in Python is checking if two capsules intersect. I checked the algorithm from the website and it seems to work. I tried implementing an epsilon to help with floating point error, but I don't think I did it correctly. Help would be much appreciated. 
      def check_intersection(particle1,particle2): decimal.getcontext().prec = 100 epsilon = 2**-52 #implement epsilon small_num = 0.00000001 #number to check if they're closely parallel u = particle1.get_s() #s1 v = particle2.get_s() #s2 p0 = particle1.get_p1_position() #P0 q0 = particle2.get_p1_position() #Q0 w = np.array([p0[0]-q0[0], p0[1]-q0[1], p0[2]-q0[2]]) #distance from 2 particles from their p1's a = u[0]**2 + u[1]**2 + u[2]**2 #dot product of u*u. Always >=0 b = u[0]*v[0] + u[1]*v[1] + u[2]*v[2] #dot product of u*v. c = v[0]**2 + v[1]**2 + v[2]**2 #dot product of v*v. Always >=0 d = u[0]*w[0] + u[1]*w[1] + u[2]*w[2] #dot product of u*w e = v[0]*w[0] + v[1]*w[1] + v[2]*w[2] #dot product of v*w D = (a*c)-b**2 #always >=0 #Set all to defaults sc = sN = sD = D #sc = sN / sD, default sD = D >= 0 tc = tN = tD = D #tc = tN / tD, default tD = D >= 0 if D**2 < small_num: # checks if SCs are parallel sN = 0.0 # force using point P0 on segment S1 sD = 1.0 # to prevent possible division by 0.0 later tN = e tD = c else: # get the closest points on the infinite lines sN = (b * e) - (c * d) tN = (a * e) -(b * d) if sN < 0.0: sN = 0.0 tN = e tD = c elif sN > sD: # sc > 1 => the s=1 edge is visible sN = sD tN = (e + b) tD = c if tN < 0.0: # tc < 0 => the t=0 edge is visible tN = 0.0 # recompute sc for this edge if -d < 0.0: sN = 0.0 elif -d > a: sN = sD else: sN = -d sD = a elif tN > tD: # tc > 1 => the t=1 edge is visible tN = tD # recompute sc for this edge if (-d + b) < 0.0: sN = 0.0 elif (-d + b) > a: sN = sD else: sN = (-d + b) sD = a # division to get sc and tc if abs(sN) < small_num: sc = 0.0 else: sc = sN / sD if abs(tN) < small_num: tc = 0.0 else: tc = tN / tD # difference of 2 closest points dP = np.array( [w[0] + (sc * u[0]) - (tc * v[0]), w[1] + (sc * u[1]) - (tc * v[1]), w[2] + (sc * u[2]) - (tc * v[2])] ) # dP = w + np.multiply(sc,u) - np.multiply(tc,v) #S1(sc) - S2(tc) close_d = (math.sqrt(dP[0] ** 2 + dP[1] ** 2 + dP[2] ** 2) ) # closest distance b/w 2 lines # check if distance <= radius * 2, if so, INTERSECTION! diff = abs( close_d - (2*S_RADIUS) ) if(diff <= epsilon): return True else: return False
    • By Florian Gionnane
      Our team at Darkstar Games is looking for some motivated developers to join our new TCG MMORPG game called "Greater Powers".

      We are previewing KS for Q1 2020 and are set to create a unique and epic videogame !
      Our team members work for corporate equity (corporate shares). 
      Every team member who has shown active participation is granted stock option in the corporation. And Department directors will be distributing cash bonuses to team members who contribute significantly to the project during development.

      Skillset especially needed:
      -> Concept artist
      -> Rigger
      -> Animator
      -> C# programming 
      -> Graphic design
      -> 3D modeling (especially for structures, creatures and skyships)
      -> Good knowledges level in Unity3D

      If you're looking to join in on an up and coming original game company send me your Portfolio to: flosambora123@gmail.com
      Hope to hear from you soon ! 
      https://www.facebook.com/DarkstarGamesCorp/



  • 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!