Jump to content
  • entries
    13
  • comments
    5
  • views
    999

It's the Village Monsters Dev Diary Digest for July 30th, 2017

Sign in to follow this  
WarpDogsVG

879 views

It's the weekend, so that means I get to share everything I worked on last week in yet another edition of the Developer Diary Digest!

Before I begin, I wanted to quickly plug something. You might not know this, but I have a newsletter for Village Monsters, and I would absolutely love it if you signed up for it!
 
H4DtcAd.png

Newsletter Signup: https://tinyletter.com/Village-Monsters

I try to reserve the newsletter for only big ticket items, so you'll be the first to know of releases and other important news.

Anyway, back to the update!

---

I had a few really productive weeks this month, so I guess I was 'due' to have a slow one. I didn't get nearly as much done as I had hoped, and I ended up getting caught in a few technical quagmires; still, I have things to share, so let's get on with it!

Fleshing Out Hobbies
From day 1 of development I knew that hobbies were going to be a major feature of Village Monsters. When you aren't talking with villagers, improving your house or solving mysteries, you'll probably be progressing your skills (and making money) with one of the various hobbies

Critter Capturing was the first hobby I put in, followed by Fishing and Archaeology. I had a bunch of ideas for other hobbies to add to the mix, but I wasn't sure which ones would work best. Well, until now.
 
yvkSaGi.png
(icons are very much 1st draft)

Village Monsters will now contain five hobbies for you to enjoy: Cooking, Critter Capturing, Botany, Fishing, and Archaeology. This post details some new updates to two of them.

Botany Prototyping
Botany is one of the new hobbies I've been working on, and it includes everything plant related.

The reason I'm going with Botany instead of something like Gardening is that you'll be able to do way more than grow a simple garden

This week, I played around with planting & watering trees, as well as managing growth as time progresses - assuming you make sure to water and care for them each day
 
0K9keDU.gif

Like all prototypes it's a big work-in-progress. However, thanks to feedback from a user at another site I've had some intriguing ideas that I'm keeping under my hat. Stay tuned next week, yeah?

Fishing Revamp
Fishing was one of the first hobbies I implemented, but I haven't touched it since. It's in a sorry state as of the last demo, and I'm pretty embarrassed by how bad it is.

What began as a 'revamp' quickly turned into a 'refactor' which the became a total 'rewrite'. I tossed out all my old code and rewrote it from the ground up.
 
bxRwT1j.gif

It was a slow process, but fishing is in a much better state in terms of stability and mechanics. Work will continue on this system this week as well.

I've always been dissatisfied with fishing minigames in other life-sim games, so I'm going in a different direction. You can expect a system that's much more inspired by JRPGs than any existing life-sim out there.

Quality of Life
To wrap up, I also included a grab bag of bug fixes and quality of life improvements that I received from demo feedback.

Trees should behave better and no longer give you a permanent hug. Birds fly a bit slower. The keyboard control scheme was reworked. Critters should hopefully not crash the game as much. Your bit (currency) balance is now shown when you add or subtract from it

And so on.

I also got a lot of writing in this week as well. Every item - every single item - has a unique description and flavor text. Some even have detailed backstories. Pretty nuts, right? Well it's been a ton of fun, so there's no stopping me now.
 
PuDjcVg.png

Until next time!
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 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 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 sidbhati32
      There are two Entities in the game and we controlling one of them. The other entity moves in a particular direction throughout the game and I want to make the AI like the enemy shoots at my player after some duration of time. I am using Directx 10 SDK for this.
      I think I would need to calculate the distance between the two entities and shoot it towards the player.
      I would need to calculate the distance between the two vectors and direction of A towards B.
      How to calculate the direction between the two?
    • 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 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.
×

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!