Jump to content

Project: YORG.io

YORG.io v2.1 release

tobspr

1226 views

Here is a new update for YORG.io! Some small changes here and there and overall just improving the game.

Increased Map Size

The map is now four times as big as before (200×200 instead of 100×100). This means a lot more space to expand since previously players already had covered the whole map.

However, this also means that old savegames are not compatible anymore – Sorry for that!

Detailed Minimap View

You can now also hold “M” to show a bigger version of the minimap:

Screenshot_1.png

Invisible Transporters Earlier

The skill tree has been changed so that invisible transporters are now available earlier. This was made to encourage expansion. With the previous skill tree layout, the invisible transporters were only unlockable after most of the map was covered.

Skill Tree

Up To 12 Crystal Mines Per Resource

There are now skills to place up to 12 crystal mines per resource:

Skill Tree

More Mines

Destroyed Building Indicators

When a building gets destroyed, it’s icon is now shown so you can see which type of building got destroyed:

Screenshot_4

 

Multiple Smaller Fixes

  • Fixed crash when selling invisible transporters
  • Fixed exploit when loading savegames multiple times
  • Bigger numbers (E.g. “5.6b”) are now better formatted
  • Made easy mode easier
  • Increased difficulty of the challenge mode (New modes coming soon!)
  • Minor Fixes & Performance improvements

 

Thanks to everyone who is continuing to support Yorg! If you are interested in streaming Yorg.io or playing it on Youtube, be sure to post links to this in Discord! I really want you all to succeed and so we can work together in Discord to make that a reality. Link to Discord here: https://discord.gg/UdXda9Q




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 triplewoofer
      Hello friends!
      I've been working on some pretty simplistic pixel art lately, so I put together a picture of the parts of a tile set I'm making. In the picture, you can see grass (one patch with a lighter shade), a stone path, and some cliffs/hills. I've uploaded it to the post.
      I'm hoping to get a little bit of feedback on it - is it too simplistic that it doesn't do a good job of portraying what it's supposed to be? Is there anything you would recommend changing to make it look a little more realistic?
      Thanks so much, have a great rest of your day!

    • 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 dandoherty94
      Hi all,
      I'm looking for a career change as the job that i currently do is neither a passion or something that i really want to be doing for the rest of my life. I would ideally like to begin a career in the gaming industry as like most others i have a strong passion for gaming and all things related. I have been looking into a junior test analyst QA job and was wondering if this is the correct place to start. I'm a dedicated worker so don't mind working my way up and I love being hands on with things. I was wondering if anyone had any advice regarding this or how i can go about gaining experience in this field to give myself the best chance. I'm more than willing to do either weekend work or free work to get my foot in the door so if there is any advice or help anyone could give me that would be great. 
      Thanks for reading,
      Dan 
    • 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.
×

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!