Jump to content
  • Advertisement
  • entries
    13
  • comments
    5
  • views
    1038

Beaches, Ruins, and UI Improvements: It’s the VMD3 for August 13th

WarpDogsVG

681 views

It's the weekend, and that means another edition of the Village Monsters Dev Diary Digest (VMD3)

There is now less than a month to go until the version I'm working on releases for you all to play with. This'll mark the very first Alpha version that I make public, and I'm pretty excited about it.

September is shaping up to be quite the month, and it's not just the Alpha release; stay tuned for more information on that very soon

A Day at the Beach

Due to the nature of the game it's not often that I get to create a new area, so it was a real nice change of pace to work on one this week.

Introducing...the beach.

9gnZUHU.gif

The beach is just a short walk away from the village - just head south from the gate and keep going until you reach the surf.

image.png 

Though you or I would consider such a trip to be a nice day out, it seems that monsters haven't really taken to the human notion of spending the day in the sun and sand. Unless there's a special event going on you're likely to find the area to be largely empty.

Still, you'll probably enjoy the solitude. You can catch fish, work on your tan, and nosh on some whoopie pies in peace.

image.png.2f649daf92058a0ffc306681264521d3.png

Ancient Ruins of Soon

Longtime followers of the game know that I often try to slip in as many 'meta' elements as I can. After all, this is a game in which the conceit is that the NPCs have taken it over and the digital barrier between our worlds is thinner than ever - I'm hoping it gives me some artistic liberty

Alongside beaches I added another new area to visit, though this one won't make it to the final game. It's called the Ancient Ruins of Soon, and it's an area you can visit to consult stone tablets on prophecy...

image.png.e76d063049e85a598b9ce6cf9d36bdcd.png

...in other words? You can view my plans on future features and changes from the game instead of going to my website or elsewhere. 

I tried to split it up by category, so if you want to know what the future holds for hobbies or story or your house then you can view just that information.

Even More UI Changes

This marks the 2nd week in a row in which UI changes made it to the top of my priority list. Here's a sampling of what I worked on this time.

Notifications have been slightly resized and now rotate so that the newest is always displayed at the bottom

MfB4YOR.gif

Meeting villagers for the first time now produces a notification

nmmTale.gif

The inventory now has context-sensitive prompts depending on the mode or item

\f7YVnJg.gif

Finally, I did an initial pass on an in-game version of the world map. 

JSjlJ0N.png

Ok, that'll do it for this week. Hope you're enjoying these dog days of summer, because I'm definitely not. I hate the heat. Autumn can't come fast enough!

Until next time

DYpuadz.gif

 



1 Comment


Recommended Comments

The ruins of soon are an interesting approach to showing upcoming changes! :)

Share this comment


Link to comment

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 jb-dev
      This is how loading screens will look like. I still have no idea whenever or not I could show things like tips or anything alike...
    • By Tanzan
      Hello  all,
      I just finished my first Android game and published it on Google play...
      I know its not the next red dead redemption2 but it would be nice to have some comments/feedback on it if its worth it to go on with a release 2.0. or move on to the next game? (red dead redemption 3  )
      Anyway thx for your reading time and i hope on some nice reviews!
      https://play.google.com/store/apps/details?id=com.gamlex.android.games.typomania
      Regards,
       
      Tanzan
       
       
    • By Programmer One
      I'm currently writing a 2D game engine from scratch for Android. The first iteration of the engine is just going to use the Android Canvas view for drawing. At some point, I want to support OpenGL ES - but not until I finish this first project (which is a very simply game based on this engine). Right now, I'm dealing with Sprites and I've encountered a design challenge that I'm not entirely sure which direction I should go.
      For the sprite bitmaps, I've decided to go down the sprite atlas route (as opposed to individual image files). I'm using Texture Packer and I've written a custom JSON exporter. I didn't really want to limit myself too much, so I decided I'd support sprite rotation and trimming in order to save as much space I can in the atlas. I backed off from supporting polygon trimming for now. If you're unfamiliar with Texture Packer, it's essentially a tool that will allow you to import individual sprite frames, organize them into folders and then have the application generate a sprite map and corresponding coordinate data file. This application supports trimming any blank (alpha) space around the sprite images in order to pack them closer together. It also supports rotation if it makes the image fit better.
      What I'm trying to figure out now is how to deal with loading the sprite image data. Currently, I'm at the point where I can deserialize the JSON map data into "Sprite Frame" objects. These objects contain information about each frame. My format allows grouping of sprite frames in order to organize frames that correspond to the same animation. In essence, the sprite frame object has:
      The original (untrimmed) size of the sprite image. The original position of the sprite image within it's bounding box. The rect of where the image is in the sprite atlas. A flag indicating if it had been trimmed. A flag indicating if it has been rotated (CW). This will give me all the information I need to draw the image onto the Canvas. If I didn't support all the other fancy features I want (packed rotation, trimming) and pre-transformation (i.e. mirroring a sprite so I can reuse it for things like changing the walking animation without having to pack in more sprites), then drawing the image from the sprite atlas onto the canvas would be as simple as a simple Canvas.drawBitmap([Source Bitmap], [Destination Rect], [Source Rect]).
      But, since the image I'd be drawing MIGHT have been rotated, trimmed or otherwise transformed, I can't just simply blit it onto the Canvas. I'd first would need to apply some transformations in order to "undo" changes that were done during packing. This means I would need to either:
      Slice out the child image from the sprite atlas into a new bitmap, and apply the "unpacking" transformations (i.e. rotate back, realign, etc). Apply a transformation to the Canvas itself. (I don't think I want to go down this road since I've read that transforming the Canvas tends to be rather slow). So, I'm probably left with having to create smaller bitmaps from the sprite atlas and then keep those in memory for as long as I would need them. So, for a single sprite character, I'd be looking at around 36 sprite frames (9 different animations, each with 4 frames). What I'm concerned about is memory consumption. So now I'm thinking:
      I should read in all the sprite bitmaps from the sprite atlas and shove them into an LRU cache. This means all the sprite image data is now in memory, all ready to go for whatever animation sequence and frame I want. Once I'm done with the atlas, I dispose of it and just work with what I have in memory. I can perform this caching when I load levels and then clear items from the cache that I no longer need. I should just keep the sprite atlas, blit directly from that onto the canvas, and get rid of the fancy packing features so that I don't have to process any transformations. The only problem with this approach is that I will also have to shelve shearing and rotation on the sprite object itself. TL;DR: Am I being overly memory conscientious or having a couple frames of sprite data in memory not a super big deal?
       
    • By jb-dev
      Another version of the main menu. This one has a more complete skybox. I'm not sure if it'll be a good idea to use the same shade on the actual Levels skyboxes...
    • By JeremyAlessi
      Jean Simonet is an indie developer who moved away from the AAA space in 2013 after delivering Skyrim and realizing that Fallout 4 just had him doing more of the same. Jean challenged himself and succeeded. 
      In this talk, Jean runs a counterstrike on every piece of indie gaming advice you've ever been told.
       

      View full story
×

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!