Jump to content
  • entries
    13
  • comments
    2
  • views
    1353

Kat's progress blog about our game SAMA

RoKabium Games

833 views

A 2D digging, adventure puzzle game with some retro feel reminding us of the amazing first digger games such as BoulderDash that we knew when we were younger. That is the type of game me and my partner wanted to create as our very first joint project for our studio “RoKabium Games”. Both being avid gamers we hadn’t seen many games in that genre that focused more on the actual digging being the main element rather than being an action plat former or survival and crafting sandbox with the occasional digging part. So last year we started working and planning for our game “Something Ate My Alien”.

We knew early on that for a 2-person team to pull of creating a whole video game we had to have a planning structure for a game that wasn’t too large or complicated. So early ideas of making a full blown 3D, interactive, huge sandbox with multiplayer alternatives was just not gonna be a good starting point. We scaled down the idea of a huge concept and decided to rely more on our existing skill set in the game industry. We decided to focus on a more manageable core of that we ourselves would like to play and what we believed other people would also enjoy to play. A finite game story of about 6-10 hours game play from start to finish, something fun and charming with just the right amount of action/digging/puzzles ratio.

Kat-Logo-for-blog.jpg.98658dd085cb4bb995d658460c6540a3.jpg

We also knew that our game would show quality and engaging graphics being hand painted by myself and it would all be done in a style that would ooze retro, hand painted, uniform and a beautiful game with easy to navigate and clear game mechanics and graphics. We wanted it to be a lighthearted but a addictive little gem suitable for a both younger and a more adult audience. Our game would be exactly how we envisioned it since it would be the labor of our own vision, not working for anybody else.

Kat-Icon-examples.thumb.jpg.60254fc1528162ecc3ac8ac20a1a397b.jpg

As a digital artist with several years experience in working for game studios and painting game assets, backgrounds, icons, characters etc and being part a team of other game developers, I did have some much needed experience in understanding just how much art is needed for a complete game. Even the smallest game contains more art pieces than you might think. For example, for every animation you do in 2D graphics you have to paint a new image and each animation can have anything from a very basic 5 frames up to 30-40 frames. So for each enemy you draw for example you need to also draw that enemy having an idle position, a walking cycle, a running cycle, an attack cycle, a dying cycle, a jumping cycle etc. So for one single enemy in a game you might have to produce up to around 100 images. Add to that, our game would have at least 10 different enemies for each level and we have designed our game to have a total of 4 levels.

Each game level or planet as it is represented in SAMA is built up with a set of ground tiles that has seamless tiling for a smooth and more realistic look. For each tile-set I’m designing 6 variants so the illusion of random and unique ground that looks like it is not repeating. Each world has 4 unique tile types to add variation for the digging mechanics and giving the player more varied game play. On top of normal ground tiles we have variants of 20 unique decals and edges created to blend different types of ground together better and adding even more realism. Inside the ground tiles you can as a player find all kinds of loot. So far I’ve designed 25 unique minerals, 9 different type of gemstones, 8 different kind of gases (each with animation cycles), 28 types of artefacts, 12 different types of complete fossilized animals which consists of 62 separate type of bones to find. There are teleporters, oxygen stations, health hearts, energy boosts, lamps to light up the dark caves, secret doors with puzzle areas to solve to get rare loot or upgrades. There are icons for every item and enemy you can find. All of these visual elements are hand painted by myself and still this is just the bare base of each planet level.

Kat-UI-customization.thumb.jpg.a24c1e092566233eacd623dc62cc8040.jpg

When designing the UI for the game we both wanted it very neat and tidy look, using our main colour scheme of blue-green-warm yellow that I first came up with during the conceptual art at the beginning of the project. I also wanted some elements to have somewhat of a computer screen/electronic look with glowing outlines to emphasize that you as the player are the actual AI of the ship and the UI you see is the computer interior.

While continuing painting and designing the artwork for SAMA we are getting closer to a first Alpha of the game and we are hoping that with the help of feedback from gamers around us and people interested in our game we can develop a game that is incredibly fun and beautiful to play.

See more over at our web site: http://www.somethingatemyalien.com/



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 sausagejohnson
      Last week, support was added to Orx for gamepad controller mapping as well as half-axes, analog thresholds and stick/button/trigger controls remapping.
      This is made possible by utilizing the SDL Game Controller Database initiative in order to standardize controller sticks and buttons.
      What this means for games is that no matter what type of controller you plug in, JOY_LX_1 means the X axis on the Left Stick of the first controller. This is much better than the previous JOY_X_1 which meant the same thing, but no guarantee which stick on your controller this would be. This greatly removes the need for creating a re-mapper screen to your games (though still good for convenience).
      An example of use would look like the following. Firstly the config:
      [MainInput] JOY_LX_1 = LeftRight Then in code:
      if (orxInput_IsActive("LeftRight")) {     orxFLOAT x = orxInput_GetValue("LeftRight");     //do something } There are a number of joystick tutorials that cover the new features.
    • By Masterbuiler64
      Good Morning, Afternoon, or Evening,
      My name is Dalton Potter and I am a budding game developer looking to learn skills and develop a beautiful project me and my friend came up with a year ago or so and have refined ever since. The idea is a basically a mix of Final Fantasy and Zelda in terms of exploration and battle, but will throw in its own unique features to switch things up a bit. What we have in place so far is the main story and many connecting character back stories, a map of the over world (still not 100% confirmed however), how some of the main characters look (also not 100% confirmed), a few battle and puzzle mechanic ideas, general story progression, locations, a few beta music tracks, and lore. What we lack however is any solid assets or work done on it as neither of us have any expertise in game development, but have both unanimously agreed that this idea is too good to forget and pass up.
      We are currently looking for people to help us work on the project as time goes on and maybe, just maybe, it may grow into a full blown team of people working on a game and eventually sell it on Steam or other client services. Any replies to this topic will be read as soon as possible depending on my schedule. I have also attached a couple photos and sound files of some design concepts we have. I also have a Pastebin made of the entire story and main character back stories, as well as history into how the idea came to be, though I'll let the Pastebin be requested as needed in the future.
      Hopefully this project turns from being just an idea into something amazingly beautiful and playable......it just needs to be created that's all.....
      Thank you in advance,
      Dalton Potter
      P.S. The sound file, "Power and Prestige" is a song that sounds as though it could be used as a trailer theme, and "Curiosity" sounds as though it could be used on a farm at sunrise.
      Source of music was from YouTube, but the groups official site is as follows: http://floatingcloud.net/
       
      EDIT: I am adding in a link to the pastebin so those that view this can get look at the story for the game. Link: https://pastebin.com/U7dKp8PS

      Floating Cloud - Power and Prestige.mp3

      Floating Cloud - Curiosity.mp3

    • By BlackSpoon
      Hi guys, let me introduce my new project - Just Smash It! It's all about destruction! Break your way smashing objects with aimed shots!
      * Realistic physics of destruction
      * Smooth game flow
      * Pleasant graphic and sound design
      * Infinite mode after passing the basic set of levels
      * Small size, great time-killer!
      Play Market: https://play.google.com/store/apps/details?id=com.blackspoongames.smashworld
      Feedback are welcome!
    • By Seer
      I have programmed an implementation of the Separating Axis Theorem to handle collisions between 2D convex polygons. It is written in Processing and can be viewed on Github here. There are a couple of issues with it that I would like some help in resolving.
      In the construction of Polygon objects, you specify the width and height of the polygon and the initial rotation offset by which the vertices will be placed around the polygon. If the rotation offset is 0, the first vertex is placed directly to the right of the object. If higher or lower, the first vertex is placed clockwise or counter-clockwise, respectively, around the circumference of the object by the rotation amount. The rest of the vertices follow by a consistent offset of TWO_PI / number of vertices. While this places the vertices at the correct angle around the polygon, the problem is that if the rotation is anything other than 0, the width and height of the polygon are no longer the values specified. They are reduced because the vertices are placed around the polygon using the sin and cos functions, which often return values other than 1 or -1. Of course, when the half width and half height are multiplied by a sin or cos value other than 1 or -1, they are reduced. This is my issue. How can I place an arbitrary number of vertices at an arbitrary rotation around the polygon, while maintaining both the intended shape specified by the number of vertices (triangle, hexagon, octagon), and the intended width and height of the polygon as specified by the parameter values in the constructor?
      The Polygon code:
      class Polygon { PVector position; PShape shape; int w, h, halfW, halfH; color c; ArrayList<PVector> vertexOffsets; Polygon(PVector position, int numVertices, int w, int h, float rotation) { this.position = position; this.w = w; this.h = h; this.halfW = w / 2; this.halfH = h / 2; this.c = color(255); vertexOffsets = new ArrayList<PVector>(); if(numVertices < 3) numVertices = 3; shape = createShape(); shape.beginShape(); shape.fill(255); shape.stroke(255); for(int i = 0; i < numVertices; ++i) { PVector vertex = new PVector(position.x + cos(rotation) * halfW, position.y + sin(rotation) * halfH); shape.vertex(vertex.x, vertex.y); rotation += TWO_PI / numVertices; PVector vertexOffset = vertex.sub(position); vertexOffsets.add(vertexOffset); } shape.endShape(CLOSE); } void move(float x, float y) { position.set(x, y); for(int i = 0; i < shape.getVertexCount(); ++i) { PVector vertexOffset = vertexOffsets.get(i); shape.setVertex(i, position.x + vertexOffset.x, position.y + vertexOffset.y); } } void rotate(float angle) { for(int i = 0; i < shape.getVertexCount(); ++i) { PVector vertexOffset = vertexOffsets.get(i); vertexOffset.rotate(angle); shape.setVertex(i, position.x + vertexOffset.x, position.y + vertexOffset.y); } } void setColour(color c) { this.c = c; } void render() { shape.setFill(c); shape(shape); } }  
      My other issue is that when two polygons with three vertices each collide, they are not always moved out of collision smoothly by the Minimum Translation Vector returned by the SAT algorithm. The polygon moved out of collision by the MTV does not rest against the other polygon as it should, it instead jumps back a small distance. I find this very strange as I have been unable to replicate this behaviour when resolving collisions between polygons of other vertex quantities and I cannot find the flaw in the implementation, though it must be there. What could be causing this incorrect collision resolution, which from my testing appears to only occur between polygons of three vertices?
      Any help you can provide on these issues would be greatly appreciated. Thank you.
    • By Rio Lloyd
      Hey all!
      we are a team of 3 looking for more members, 
      we are making an isometrical Survival RPG.
      we are looking For Members who can make low poly 3D artists who can do character models, environments, tools and more.
       
      if interested and want to know more email me at rioishere14@gmail.com
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!