Jump to content
  • entries
    36
  • comments
    7
  • views
    4889

[Poject SpaceVille] Devlog #6 - Ramping up the Art

RedOtter

727 views

Hello, everyone! :) 

As you may know, last week we went to Game Dev Meet @Porto. It was our first presence at a Game Dev Meet as FAXIME, and it was just awesome! We had the chance know a lot of new developers and their projects from around our area (North of Portugal). We even got to test some!

We also had the chance to talk to a director of an acclaimed video game developer from Portugal, and he gave us some great advice on how to start a startup and launch our first game. Thank you for that! :)

Unfortunately, we weren’t able to show off “Project SpaceVille” (sad!!). We were fixing some last minute bugs before we left, but everything else was fine. And then… we decided to change some assets 2 hours before the meet started and it was chaos! Bugs everywhere! Problems with the animations! Crashes here and there! ... So, I guess we’ll have to go again next month! (laughs)

In other matters, we have a nice announcement to make. We’re basically done with the functional (programming) prototype phase! So, these past few weeks, we’ve been starting to ramp up the art department. This is basically to start switching placeholders and make the game beautiful! Our team member, “Midday-Mayhem”, is of course on the lead. We haven’t quite settled in a concrete art-style yet, but we’re confident in “Midday”’s abilities! Stay tuned for that!

Meanwhile, for the past 3 days we’ve be sending a couple of emails to some really talented folks on DeviantArt. Since we’re ramping up art production, we’re currently in the process trying to find an artist to join our team! I won’t lie to you, we’ve been trying to have someone join the team for quite some time now… but I think we are finally getting somewhere! (fingers crossed) But boy, let me tell you, DeviantArt can be a weird place sometimes! (laughs)

 

Game Developments

Want to see what your character’s base mesh will look like? Here is a screenshot! (haven’t done those in a long time now) (laughs)

 

731331_fbf2042fdb6d4bc89373175b748d5440~

 

We’ve also been messing around with the player input. We want to make sure that it feels as natural as possible. So, for example, when you click on a tree close by, with an axe equipped, the player starts chopping it down.

We’re also working on the “Drop Item” feature, in case something that you don’t want is taking up too much space on your inventory or you just don’t want an item. Now you’ll be able to drop it, either by dragging it out of the inventory or by just clicking a button.

Unfortunately, to do something as simple as that, we needed to change a lot of the code we had. There were a lot of mistakes we made in the past when it comes to how we coded the “Project SpaceVille” prototype. The previous code was basically juggled to work on the university presentations we had. (laughs) But now, we’re in the process of refactoring most of the game’s systems to allow them to grow sustainably in the future.

 

In The Near Future...

About Indie Dome we talked about on the previous post: the deadline to apply was extended to the 15th of August. Thank god! (laughs) We’ll have time to improve the small experience that we have fix all bugs (we hope) until then!

 

And that’s it for today.

In the coming weeks, I have a feeling you’ll be seeing some awesome art-related stuff from “Project SpaceVille”.

Please stay tuned for more news!

 

See you soon,

The FAXIME Team

 

Follow us and keep updated at:

Facebook: https://www.facebook.com/FaximeGames
Instagram: https://www.instagram.com/faximegames/
Twitter: https://twitter.com/FaximeGames
Pintrest: https://www.pinterest.pt/faximegames/



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 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
    • By Anri
      I'm working on a small arcade-style Android game for phones and tablets( using Android Studio and Java ) and I'm not 100% satisfied with the touch screen controls.  The game has five buttons for control;  left and right, and three buttons for firing three different bullet types( essential to the main mechanic of the game itself ).
      The irony is that they respond very well even with scaling on different devices and the coding is bullet-proof( zero crashes or bugs since extensive testing ),  but as the game is as fast paced as Space Invaders or Columns it kinda falls apart as I switch between pressing buttons in the heat of the action.  I am now at the point where I'm having to slow the game down to make it easier to cope with the touch-screen buttons, or adopt a harsh attitude that the player will need an Android-compatible gamepad for the best possible experience...
      Quality controls with standard input is something I take very seriously, but in this case I feel action games are not suited for tablets without a gamepad.  Would this be a correct assumption or could I do better?
      Any thoughts would be most welcome - even if you are just a gamer.
       
      Cheers.
    • By nxrighthere
      BenchmarkNet is a console application for testing the reliable UDP networking solutions.
      Features:
      Asynchronous simulation of a large number of clients Stable under high loads Simple and flexible simulation setup Detailed session information Multi-process instances Supported networking libraries:
      ENet UNet LiteNetLib Lidgren MiniUDP Hazel Photon Neutrino DarkRift More information and source code on GitHub.
      You can find the latest benchmark results on the wiki page.
       
    • By ggenije
      Important: I am trying to realize in scrtach which is performance very low due to it's "virutal level" scrtach->flashplayer->java...
      Also i'm new to this forum so i'm sorry if I missed group (like last time)
      Like a title is saying:
      I have project ,and I get negative feedback on it because some people need 30 min to complete it (what is the planned time)
      but problem is that some people need EVEN 5 hours…(game is incremental/idle/upgrade type so it's important to keep same time ...)
      ———————————————————————————————————————-
      Of course people with slower computer will have less fps so game will be slower for them,
      so I have created TimeDelta system for each frame to calculate something to do per second
      for example
        Update(){move(TimeDelta*speed)}  so that mean it will be moving speed number of pixels(or units) per second so it will be same for almost each user.

      But problem is next:
      I have to change ySpeed by jumpPower (#PlayerJump in my project)
      when any jump button is pressed
      then in each frame decrease ySpeed by gravity it is(-10 * TimeDelta)
      but when someone have lower fps it will have higher TimeDelta and will fall faster but with same jump it turns out to jump significantly lower that changes core of game
      BUT even worse if fps suddenly in moment of jump then timeDelta would be 1 so player will jump much much MUCH higher , then fall much slower because timeDelta changed in meanwhile…(and the point of my game is about upgrading jump not complete game in first fps drop)


      —————————————————————————————————————————————————————

      Then I got an idea to fix TimeDelta (like in unity for rigibody) so it will be rounded like
      if calculated TimeDelta is 0.01834 it will be 0.02 fixed
      if weaker computer is using it the TImeDelta will be 0.143 so runded to 0.14 and so on…

      I did not manage to realize it… i tried to calculate it before main initialization of game objects
      but I'm afraid to fps will drop in moment that is calculating so it will be much diffirent…
      I was trying with empty loop(400)(in scrtach even this is taking time) to calculate it but i'm not sure is it right

      So is there good way to realize this fixed TimeDelta
      I only have timer function to use and time difference between frames
       
      This_is_the_link_for_the_game
    • By trapazza
      I'm trying to add some details like grass, rocks, trees, etc. to my little procedurally-generated planet. The meshes for the terrain are created from a spherified cube which is split in chunks (chunked LOD).
      To do this I've wrote a geometry shader that takes a mesh as input and uses its vertex positions as locations where the patches of grass will be placed (as textured quads).
      For an infinite flat world (not spherical) I'd use the terrain mesh as input to the geometry shader, but I've found that this won't work well on a sphere, since the vertex density is not homogeneous across the surface.
      So the main question would be: How to create a point cloud for each terrain chunk whose points were equally distributed across the chunk?
      Note: I've seen some examples where these points are calculated from intersecting a massive rain of totally random perpendicular rays from above... but I found this solution overkill, to say the least.
      Another related question would be: Is there something better/faster than the geometry shader approach, maybe using compute shaders and instancing?
×

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!