Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Blizzard

1
It's kinda weird that nobody has posted this information anywhere on the Internet because there actually IS a way to disable Windows Update completely. Why would you do that? While keeping your PC up to date is recommended, some people experience huge issues with updates. Windows Update has broken various PCs I have worked on (home PCs/laptops, PCs at work, work servers, etc.) numerous times. This is why I prefer to update Windows only when I do have the time to also reinstall Windows in case it breaks something I really need (which is almost always). I dislike forced updates that I have no controls over because they break shit way too often.

So, how is it done? Windows Update depends on 2 services on your PC to function. If you simply delete these two services, Windows Update will stop. Why both? Because these services attempt to restore each other, hence both must be removed.

1. Press Windows+R.
2. Type in "regedit" and press ENTER.
3. Find and delete the entire the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wuauserv
4. Find and delete the entire the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WaaSMedicSvc
5. Restart your PC.
6. Make SURE you actually DO restart your PC! The services will be running even though you deleted them from registry until you restart your PC. That means that they have a chance to restore each other. For extra safety you can first stop those 2 services before deleting them. While technically you may not need to restart your PC if you go this route, safe is safe and you should restart it anyway.

Optional: Export the two keys from the registry so you can restore Windows Update if necessary.

Notes: There are other ways to delete services via command line, but even in admin mode, Windows will actually refuse to delete WaaSMedicSvc because of permission limitations. Microsoft is trying really hard to keep pushing those (essentially beta) updates on you.
2
Lexima Legends - Paths of Strife


INTRODUCTION

This game is a strategic RPG inspired by the games Ogre Battle: March of the Black Queen for the SNES and Ogre Battle 64: Person of Lordly Caliber for the N64.

The core game mechanic revolves around moving and placing units on a map in semi-real-time (it's possible to pause the game). Units are comprised of several characters. When one of your units meets an enemy unit, they engage into a short and mostly automated RPG-style turn-based battle.

You can create and organize units from a wide variety of characters as you see fit. The characters themselves have RPG-style stats and grow stronger as they attain more experience.

The game is planned as a commercial release. The first release will be on Steam and possibly itch.io. Android and iOS versions are planned later on as some GUI changes will be required in order to make the game work better on the small screens of mobile devices and touch interfaces.

SCREENSHOTS

Spoiler: ShowHide






























THE STATE OF THIS TECH DEMO

This playable tech demo is meant to show off a majority of the features that will be present in the final game.

The game was designed to be played with mouse and keyboard.

  • You can move the map either with arrow keys, WASD or by moving the mouse cursor to the edge of the screen. You can rotate the camera by holding the middle mouse button (usually scroll wheel button).
  • In the Move unit menu where you place waypoints, you can remove the last waypoint with the right mouse click.
  • Certain menus also have hotkeys (currently only the game speed menu) and certain menus have default confirm and/or cancel actions that can be triggered using the Enter or ESC keys.

Most menus are done or require only minor changes. Some menus are bare-bones and will be redesigned entirely.

The gameplay includes the most important features such as map movement, battles, handling of units and characters, classes, etc., but there are still some finer features missing such as a day and night system, a weather system, etc.

A good deal of the graphics are also final (menus, character art, map tiles, etc.), but there are obviously still many placeholders. Please keep in mind that the placeholders are not bare-bones! That means that you are free to give feedback on any graphics you want even if it is potentially a placeholder.

Some of the music and sounds are final. Others won't be used where they are now in the game.

The demo features one simple mission on a large map with basic enemy AI in place. The mission takes 30-90 minutes to complete, depending on your playstyle and how far "off course" you want to explore the map with your units.

For simplicity's sake, there is a single Quick Save slot that can be accessed from the in-game menu in order to save. To load your game, select the Continue from the title screen.

As this tech demo does not include any tutorials whatsoever, you are encouraged to experiment and explore the menus at your own convenience. There are a lot of minor details and features that will not be explained here.

IMPORTANT GAMEPLAY MECHANICS

Again, as this demo has no tutorials, the most relevant gameplay mechanics are explained here.

Information about the map:

  • Units can be moved around the map via a waypoint system.
  • The map is comprised of various terrains and units will have movement speed penalties if they don't have the proper terrain affinity. Grassland and roads have no penalty.
  • The game can be paused at any time on the map. It's also possible to fast-forward time. While navigating menus on the map, the game is automatically paused separate from your game speed setting.
  • Units have a view range (which is larger in front than in the back) and enemy units are only visible if they are within view range of any of your units. (Through some playtesting it was determined that this is confusing without visual feedback so a feature similar to Fog of War is planned in the future, but it's not available in the game right now.)


Information about units:

  • Units are organized in a 3x3 grid that can be populated by characters. Positioning of characters their classes are important as they influence how battles play out (number of attacks, possible targets, etc.). It's possible to engage enemies from the side or from the back which throws their formation out of balance and gives you an advantage in battle. Though the same goes for enemies as they can flank or back-attack your units as well.
  • Terrain affinity depends on character composition of the unit. e.g. Hound-type monsters are good in forests and your unit won't get any penalty in forests if you have enough Hound-type characters in it.
  • Units have their own limited item inventories. Their size is determined by the characters in the unit. A larger number of characters and higher class characters contribute to more inventory slots.
  • Character decision making in battle is mostly automated, but it's possible to change the Unit Tactic so characters prioritize different targets in accordance to the Unit Tactic setting.


Information about characters:

  • Each character belongs to one of multiple class trees ranging from humans (male and female) over humanoid entities (mermaids, birdmen, etc.) to various types of monsters (dragons, golems, chimeras, etc.). The player can change a character's class to get access to better attacks and stat growth, but most classes have certain requirements that need to be met before a character can change into that class.
  • Characters have multiple stats and characters themselves are generally separated into physical and magical fighters. Physical fighters take less damage from other physical fighters while they take more damage from magical ones and vice versa. The same system applies to magical ones.
  • Characters have equipment. (The weapon is mandatory and cannot be removed.) Certain equipment has so-called Soul Rage abilities. Please see further below for more information.
  • Depending on their class, characters have certain attacks available. The attack they use and the number of time they will use that attack during a battle is determined by the row (front, middle, back) in the 3x3 unit grid. Keep in mind that getting attacked from the side or back does influence which actual row the character will belong to during a specific battle instance.
  • Characters have a special stat called SR percentage. When a character wears equipment with SR abilities and receives damage, their SR percentage will increase. This stat can be consumed to use special attacks during battle (accessible via the Soul Rage option in the battle interrupt menu). It's planned to allow characters to increase their SR percentage in other ways as well.

Information about battles:

  • Battles are mostly automated.
  • During the battle, actions done by the characters increase the battle score of the unit. Certain conditions and actions provide a bonus (which is already integrated into the displayed score). e.g. Normal attacks increase the battle score by a flat value, healing also incurs a penalty percentage, units under 5 characters get a bonus for every missing character, etc.
  • The player can open an interrupt menu which pauses the battle. (This menu can opened by simply clicking anywhere on the screen during battle.)


OTHER INFORMATION

As this tech demo is intended to showcase gameplay only, I will refrain from going into detail for the planned story and keep things more on a conceptual level.

The core idea is to explore the concept of choice and consequences. I have crafted a dynamic story with multiple paths and multiple endings. Your behavior as a player and the choices you make during both missions and cutscenes will influence how the story progresses, what events take place and how it ultimately concludes. In the story I am also exploring other interesting concepts and opposing perspectives and morals between protagonists and antagonists.

There are a number of main characters (including you, the player character) that carry the story itself. But there is also a high number of recruitable side-characters (I expect at least 30) with their own backstories and side-quests that you can do during missions. IMO the original Ogre Battle games had a lackluster mechanic of this and I wanted to iterated and improve upon this.

Sounds too ambitious? Not really. As the game will have a mission-like structure, it's easy to contain individual side-stories. It's also not much of a problem to include certain characters in events or cutscenes later on. Obviously the number of paths the player can take is limited and so is the number of endings. But compositing all the player's actions, all the side-quests they did and characters they recruited into a satisfying epilogue is not that hard. A quality delivery of the story in itself is much harder.

How did it all even start?

A few years ago I realized that a game like this wouldn't require too many graphical resources and a lot less maps than my previous project, yet it could have a lot more playtime. This first realization gave me the initial idea to make a game like this. I first experimented with RPG Maker MV to see if some things were even feasible. After a few months of experimenting, I realized that I basically already started working on a new game. As time passed by, I actually decided to invest some money into custom graphics and licensing some music. From what I can personally say, I think it was a very worthwhile investment.

DOWNLOAD LINK

You can download the game from here:
DOWNLOAD
Simply unzip and run Game.exe.

As the credits are a bit lengthy, they will not be posted here. You can be access them from the title screen and they will be displayed upon demo completion.

MISSING FEATURES

  • day and night cycle (that also affects certain characters and attacks)
  • weather (that also affects certain characters and attacks)
  • Quick Battle functionality
  • tutorials
  • optional perma-death mode for units and characters
  • adaptive enemy level scaling
  • interactive minimap
  • proper save-game system with save slots, auto-saves, manual saves, etc.
  • gamepad support
  • decision-based story progression and cutscenes
  • more hotkeys in menus (e.g. unit selection)
  • various notifications relevant to gameplay (e.g. when a unit has finished moving, when a base has been lost, etc.)
  • more useful options for gameplay flow (pausing after battle, pausing after taking a base, pausing after a unit stops moving, etc.)

PLANNED IMPROVEMENTS

  • Options menu will have sliders for audio volumes.
  • There will be more options (such as battle BGM).
  • Shop menus will be completely redesigned.
  • Characters screen in Army scene will be redesigned completely (it's very basic currently).
  • A lot more character classes will be unlocked and available.
  • The entire class menu will be improved.
  • Battle GUI is currently very basic.
  • Improvements in battle animation timings.
  • Mission screen will be completely redesigned (it will include a side-quest section as well).
  • The current title screen and title audio are placeholders.
  • Overworld mission maps will be reduced in size so that the map overview is better.
  • Improved rendering on higher resolutions than the base resolution of 1280x720.
  • The are some issues with game balance which will be fixed later (e.g. characters with level 3 classes have very high stats while level 1 classes are a lot weaker).
  • Fog of War on the map or an equivalent solution for visual view range info for the player.
  • Improvements to enemy AI.
  • Map AI can currently cause performance spikes.

EXPECTED / POSSIBLE BUGS

  • possible issues with class change menu
  • ESC / Enter might not work as hotkeys in certain menus
  • when switching between windows, audio volume transition might get stuck (can be fixed by switching windows again)
  • some menus might appear / disappear from the wrong direction of the screen
  • possibly getting stuck in battle
  • not all menu items have icons
  • possible short stutters on the map
  • some enemy unit AI behavior on the map may be broken
  • when selecting / hovering over a menu item that's already "selected", no cursor sound is played

REPORTED BUGS

  • Screen remains black after battle.
  • Enemy unit map sprites sometimes disappear.

Critical feedback is much appreciated!
3
I am looking for an artist that can create several autotiles and slightly rework a few small tilesets. This is for use in RPG Maker MV, but the format used is RPG Maker XP! I have reference material in form of battlebacks and already created autotiles.

Important Info

I have reference material in form of the previous autotiles and in form of battle backgrounds (for color reference mostly).

To clarify the terminology I will use first:

  • base - This is the base terrain that is used as the lower layer of the autotile.
  • overlay - This is the terrain that goes above and is used as the upper layer of the autotile.
  • terrain - The actual graphic of the autotile. It can be used either as base or as overlay.

As an example, this autotile uses a sand base and a water overlay:

"sand-water autotile": ShowHide




Note the diagonal corners! This is very important: The autotiles must have diagonal corners!

There are a few additional requirements. Here's a list of all of them:

  • XP-styled autotiles
  • tile resolution is 48x48px like in MV (not 32x32px like in XP default RTP!)
  • diagonal corners
  • unlike in XP, the top left tile is used for the end of single-tile-width "channels" (I can show you an example, incidentally the one example from above actually has a broken tile for that)

List of terrains

  • grass
  • barren land (bright brown with cracks)
  • dirt land (dark brown with lesser visible cracks)
  • snow
  • sand (basically desert, but also used for beaches)
  • swamp
  • shallow water
  • medium water
  • deep water
  • road (should be somewhat thinner than normal autotile setups)
  • snow road (basically the same as road, but colored white-ish, probably best as a darker shade than the snow terrain)
  • sand road (basically the same as road, but colored brighter, probably best as a darker shade than the sand terrain)
  • normal trees
  • pine trees
  • snowy pine trees
  • palms

List of autotiles (as final products)

This is a list of all autotiles that only use base:

  • grass
  • shallow water
  • medium water

This is a list of all autotiles that use base + overlay:

  • grass + barren
  • grass + dirt
  • grass + snow
  • grass + sand
  • grass + swamp
  • barren + dirt
  • barren + snow
  • barren + sand
  • barren + swamp
  • dirt + snow
  • dirt + sand
  • dirt + swamp
  • shallow water + medium water
  • medium water + deep water
  • transparent + road
  • transparent + snow road
  • transparent + sand road
  • transparent + shallow water
  • transparent + normal trees
  • transparent + pine trees
  • transparent + snowy pine trees
  • transparent + palms

List of tilesets that need reworking

These mostly need some color corrections to fit with the autotiles you create and with the battle backgrounds.

  • 4 mountain tilesets in different colors
  • 2 cliff tilesets in different colors

Artist Requirements

  • some experience in drawing tiles and tilesets
  • this is for commercial use so the artist needs to be ok with that

Payment

  • Paypal
  • Transferwise

Offers

Please send any offers directly to my email boris.blizzard[at]gmail.com. Include a price for every graphic (category-wise or otherwise) and the time required to make all the graphics. Please also include links to a portfolio so I can check out previous work that you have done. I'll be looking forward to your messages. :)

Other Notes

It probably makes sense that the road autotiles have slightly rounded corners instead of diagonal ones because of how mapping works. Though, it would be great if diagonal roads could somehow be made to work without having to use a normal tileset.
4
News / Suggestions / Feedback / Upgrade to SMF 2.1 RC2
August 25, 2019, 09:25:10 am
Due to issues with PHP 5.3 on our host, we had to upgrade SMF to v2.1 RC2. Because of this we'll be using a different theme until our old theme is restored. I slightly edited the current theme so that the colors fit our original color scheme. There will likely be issues around so feel free to post them here if you find them.
15
News / Suggestions / Feedback / HTTPS and SSL
April 15, 2018, 12:16:15 pm
The forum has been reconfigured to require an SSL connection over HTTP (also known as HTTPS) in order to improve security. Everything should work as before, but if you have issues, let me know.
16
RMMV Script Database / [MV] Ultra Mode 7
April 15, 2018, 08:23:32 am
Ultra Mode 7
Authors: Blizzard
Version: 1.7.6
Type: Environment Add-on
Key Term: Environment Add-on

Introduction

Ultra Mode 7 simulates the Mode 7 rendering mode from the SNES by using 3D rendering (hence the "Ultra"). Sprites are scaled appropriately and use additional code to determine whether they are visible, because of cut-off distance. The view of a Mode 7 map is defined by the following parameters:

  • camera distance
  • camera Y position
  • field of view
  • pitch rotation angle
  • yaw rotation angle
  • maximum Z coordinate

This work is licensed under BSD License 2.0:
Quote from: undefinedCopyright (c) Boris "Blizzard" Mikić
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1.  Redistributions of source code must retain the above copyright notice,
    this list of conditions and the following disclaimer.

2.  Redistributions in binary form must reproduce the above copyright notice,
    this list of conditions and the following disclaimer in the documentation
    and/or other materials provided with the distribution.

3.  Neither the name of the copyright holder nor the names of its contributors
    may be used to endorse or promote products derived from this software
    without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

You may use this script for both non-commercial and commercial products without limitations as long as you fulfill the conditions presented by the above license. The "complete" way to give credit is to include the license somewhere in your product (e.g. in the credits screen), but a "simple" way is also acceptable. The "simple" way to give credit is as follows:
Quote from: undefinedUltra Mode 7 licensed under BSD License 2.0, Copyright (c) Boris "Blizzard" Mikić

Alternatively, if your font doesn't support diacritic characters, you may use this variant:
Quote from: undefinedUltra Mode 7 licensed under BSD License 2.0, Copyright (c) Boris "Blizzard" Mikic

In general other similar variants are allowed as long as it is clear who the creator is (e.g. "Ultra Mode 7 created by Blizzard" is acceptable). But if possible, prefer to use one of the two variants listed above.

If you fail to give credit and/or claim that this work was created by you, this may result in legal action and/or payment of damages even though this work is free of charge to use normally.


Features

  • render map in 3D
  • control rendering with various parameters and even change them on the fly
  • supports white fading of horizon
  • supports auto-scaling for sprites depending on distance from camera
  • high performance
  • easy to use

v1.1.0
  • added animation function for parameters
  • renamed RENDER_PIXELATED option to TILEMAP_PIXELATED
  • added CHARACTERS_PIXELATED option
  • fixed issue with floating characters
  • fixed issue with normal maps not working anymore
  • added some code to prevent compatibility issues with some map scripts

v1.2.0
  • fixed FPS drop problem while moving

v1.2.1
  • fixed save data issue

v1.2.2
  • fixed a syntax error that was caused by code cleanup

v1.2.3
  • added parallax distance parameter in maps for parallax movement with yaw and pitch
  • renamed "Camera" functions to "CameraDistance"
  • fixed bug with parallax scrolling on non-Mode 7 maps
  • fixed bug with shaking the screen
  • removed FOV limit and implemented orthogonal projection with FOV of 0°

v1.2.4
  • fixed accidental removal of animateCameraDistance function

v1.3.0
  • implemented map looping functionality
  • added workaround for PIXI bug where a lag spike would occur about every 10 seconds
  • fixed issue where sprite direction didn't display properly at certain yaw angles
  • fixed issue where movement controls didn't adjust to yaw angle
  • added CHARACTERS_ADJUST_SPRITE_DIRECTION option
  • fixed coordinate offset when using yaw angle

v1.3.1
  • fixed a crash with event testing

v1.3.2
  • added coordinate rounding for X and Y coordinates
  • improved code that handles sprite visibility when outside of the view frustum
  • removed some leftover debug prints

v1.3.3
  • fixed issue with event visibility on map borders when using looping maps

v1.3.4
  • added compatibility code for KhasUltraLighting
  • added compatibility instructions for Terrax Plugins - Lighting system

v1.3.5
  • corrected some minor positioning and scaling calculation errors
  • improved compatibility code for KhasUltraLighting

v1.3.6
  • added experimental compatibility for BattleLighting plugin

v1.3.8
  • added script call to enable/disable pixelated rendering during runtime
  • reduced WEBGL_MAX_VERTICES to reduce possibility of glitched rendering

v1.4.0
  • added new license
  • added usage and crediting instructions

v1.4.1
  • added compatibility with Yanfly's Grid-Free Doodads
  • added compatibility with MOG's Character Motion

v1.4.2
  • added new parameter FADE_Z_COLOR
  • added option to setup custom fade colors for specific maps
  • added option to change fade color at any time

v1.4.3
  • changed NEAR_CLIP_Z from constant to plugin parameter

v1.4.4
  • added compatibility with Thomas Edison MV
  • fixed issue with fixed-coordinate parallax not working

v1.4.5
  • added compatibility with Quasi Simple Shadows

v1.4.6
  • added compatibility for newer pixi-tilemap versions

v1.5.0
  • added map parameters for map borders

v1.5.1
  • added color fade begin to map parameters
  • added color fade end to map parameters

v1.5.2
  • added camera Y position

v1.5.3
  • improved compatibility code for KhasUltraLighting

v1.5.4
  • fixed bug with screen-to-map calculations when using orthogonal projection

v1.6.0
  • implemented improved scaling of sprites on map which doesn't get messed up by near and far clipping planes
  • changed some of the default parameters to accommodate the fixed scaling issues
  • added LEGACY_SCALING parameter for backwards compatibility

v1.6.1
  • improved code that handles sprite positioning in looped maps

v1.6.2
  • attempted fix in Yanfly's Grid-Free Doodads for sprite positioning in looped maps

v1.6.3
  • refactored positioning in looped maps
  • fixed sprite positioning in looped maps for Yanfly's Grid-Free Doodads
  • added CHARACTERS_USE_FADE_Z option
  • removed some left-over debug code

v1.6.4
  • fixed a const assignment errors

v1.6.5
  • updated some instructions

v1.7.0
  • added compatibility code for OcRam_Lights
  • improved compatibility code for KhasUltraLighting

v1.7.1
  • fixed some issues in compatibility code for OcRam_Lights

v1.7.2
  • fixed issues with Yanfly's Grid-Free Doodads in deployed builds
  • fixed issues with terrain tag lights in OcRam_Lights
  • added safeguards to prevent faulty compatibility code to affect other compatibility code
  • limited NEAR_CLIP_Z to a minimum of 1 due to issues with rendering for values of 0 or less
  • disabled CHARACTERS_USE_FADE_Z by default due to performance issues

v1.7.3
  • fixed loading issues with OcRam_Lights

v1.7.4
  • added compatbility for SAN_AnalogMove when PLAYER_ADJUST_MOVE_DIRECTION is turned on
  • added roll angle support

v1.7.5
  • added compatbility for Galv Map Projectiles

v1.7.6
  • fixed a minor issues with compatbility for Galv Map Projectiles

Screenshots

Spoiler: ShowHide

Spoiler: ShowHide

https://i.gyazo.com/9c7d3250509a967665e978ea608f46af

Demo

Ultra Mode 7 Demo

Script

Script Download

Instructions

Inside the script in the first comment.

Compatibility

  • Requires WebGL. Does not work with canvas and due to how canvas works, it can never support canvas.
  • If you update from an earlier version, after replacing the actual file, you should open up the plugin settings and confirm/close them again. Sometimes new features and options are added and this ensures that the newer version of the plugin doesn't crash by adding the new options to your project's system settings.
  • Because the tilemap is rendered entirely flat, tile priority isn't used.
  • Scaling has been optimized for usage of an FOV of 60°. Using different values will cause some weird scales being used for characters.
  • Due to yaw rotation requiring turning of characters, 8-directional characters sprites might have only limited support.

Credits and Thanks

  • Boris "Blizzard" Mikić

Author's Notes

Make sure to read the instructions and study the demo before asking questions.

If you find any bugs, please report them here:
http://forum.chaos-project.com

That's it! N-Joy! =D
19
Lexima Legends - Paths of Strife / What is this?
January 12, 2018, 04:08:11 pm
Since it appears that I will enlist some help for this game, I decided that the best way to handle all this is to use the obvious tool I have at my disposal: The forum.

For those who don't know yet: I am working on a new Lexima Legends title and I'm using RPG Maker MV. This game will be commercial and I will most likely be paying for some external helpers. My plan is a release on Steam, Google Play and iTunes App Store. Since my budget is limited, I might even try a Kickstarter (but don't count on it).




The game's premise is simple and takes place long before anything of the original trilogy happened:

The Chaos Wielder Regulus has obtained massive power through unknown means and commands an army to take the planet the player grew up on. Leximus and Rivy get involved in the conflict. The player is misled to believe they fight for a rebellion against an unjust system, but in reality they serve Regulus. After joining Leximus and Rivy, the player discovers that the rebellion is a setup. Leximus tasks the player with defeating a battalion while he investigates.




The game will play somewhat similar to Ogre Battle: March of the Black Queen and Ogre Battle 64: Person of Lordly Calibur. The game takes place on a huge map RTS-style. Once two units are close enough, they engage into RPG-style turn-based battle which is automated. The loser retreats (depending on a battle score system). Standard terrain and weather affects units and characters.

On top of these base mechanics there will be additional mechanics such as Soul Rage abilities that can be used during battles to manipulate the outcome. Players will face many choices and decisions which will affect the missions they play, they story they experience and the ending they get. The plan is about 40 missions with 3 different paths, altogether about 100 missions to play.




Some interesting features include a lot of custom scripts, barely anything resembling the originals and probably most prominently: Mode 7!
20
Chat / Quick Start Guide to Cryptocurrencies
December 19, 2017, 01:28:00 pm
So, I've been doing some stuff with cryptocurrencies for the past 6 months and I decided it would be a nice idea to share some of my experiences. But first 2 disclaimers:




1. This is not financial advice. It is merely my opinion and experience so far. You are responsible for any trading you decide to do, regardless of the outcome.

2. Cryptocurrency trading is highly volatile and very risky. There is a realistic chance that you will lose all your investment.





Blockchain technology

Before I go into any detail, I want to explain what a blockchain is. It's basically a huge log file with the history of all transactions. What miners actually do is solve mathematical puzzles (with a hashing algorithm) in order to confirm the legitimacy of these transactions and then they are reward with a certain amount Bitcoins for their work. You also put aside some of the currency you send that is then awarded to the miner as well which basically means you pay a fee for transactions (you will see soon why this is important). This is also why it's called "proof of work algorithm" since it's assumed that you did the work to solve the puzzles if you have the solution. The key here is that miners all have copies of the entire blockchain (which is currently 170GB I think) and they sync each other up all the time so it's not really possible to do something like a 51%-attack to confirm fake transactions, because other miners will not confirm them if you try to fake it.




Mining

The two most important currencies are the well-known Bitcoin (XBT/BTC) and Ether (ETH). About 5-6 months ago 2 friends and I decided to take up Ether mining. So far it has paid off the 2 rigs (5 ATI RX580 8GB on each), but mainly due to the massive price surge of Ether. When we started, the price was slightly under $300. Mining is a bit less risky probably since you do have some sort of value in the PCs you put together. If nothing else, you can sell the GPUs for a decent price. Though right now the GPU prices have spiked due to mining demand. We literally got the last 10 GPUs in the entire city at a normal price back in July. Bitcoin mining is useless, because you need ASICs which is basically dedicate hardware and it's very expensive. It's true that one unit can do the work of 5-6 GPUs easily, but it's not worth it. It's too late to take up Bitcoin mining.




Trading / Investing

Now comes the fun part. First I want to suggest a simple rule to follow: Only invest what you are prepare to lose. Never invest any money that you need for living or eating or paying your rent. And please, for the love of god / science / flying spaghetti monster / whatever you believe in, do not, and I repeat DO NOT take out a loan to buy Bitcoin or any other cryptocurrency. This is all very risky and could fuck up your life.

What kind of risk am I taking? Due to my current financial situation, I could probably save money for the next 10 years and buy an apartment without having to take out a loan. Now, with Bitcoin and other currencies I am attempting to invest savings from (I guess) 8 months in order to cut down the entire process to 2 years or even less. If I lose all my money, I lose 8 months which is very little compared to the 10 years I would conventionally need to save up money. But if it succeeds, I might cut down 80%-90% of the time, down to 1-2 years only. This calculated risk for me is acceptable as the potential gain outweighs the risk of losing everything. Of course, this is my personal situation. You need to decide for yourself. My simplest advice is that you take some spare money you have and put it into Ether (ETH). Keep reading for more info on that.

Bitcoin (XBT/BTC)

As of writing Bitcoin spiked at over $20,000 and is currently dancing above the $18,000 limit. Bitcoin is problematic due to many reasons. Since it's the most known cryptocurrency, people will immediately think of Bitcoin when you mention digital currencies. This kind of hype usually pumps up the price as more people buy Bitcoin. The problem is that Bitcoin is highly unpractical as currency. It should rather be viewed as an asset or as investment. And as with all assets and investments, the value can go up and like crazy. I've seen drops of 20% and then recovery by 10%-15% within a single day. It's definitely not for the faint of heart. Another problem with Bitcoin are the transfer fees. 2-3 weeks ago fees were usually at the $10 mark, but now I've seen people post fees like $28 on Twitter. Since the value is pumped right now, it will go down quite a bit at some point. It's hard to say when. Maybe next week, maybe next month, maybe in the next hour. But since it's so well known, Bitcoin's price will go up again after a while. This kind of ups and downs have been happening over its entire history in the past years and each cycle left more people in the user base that actually do believe that Bitcoin is the future. Fun thing is that Bitcoin is lagging behind heavily as far as technology goes which you can already see from the high fees. The transaction times are also very high right now, mostly due to increased demand. Remember this part, it will be important later.

Ether (ETH)

Ether is much better than Bitcoin. Why? Disregarding the low fees and transaction times in comparison, the Ethererum blockchain actually has something called "Smart Contracts". Those are basically small programs and applications that are integrated into the blockchain directly, usually in form of conditional behavior. e.g. You can create a website that automatically sends a confirmation email on purchase from a website. The beauty here is that it's all within the blockchain and nobody can hack your website to mess you up. Because of this single distinction, I think that the Ethereum blockchain is superior and will surpass Bitcoin at some point in the future in price. Whether Bitcoin will crash down or whether Ether will rise to Bitcoin levels, I do not know. Either way, ETH is a good investment IMO.

Bitcoin Cash (BCC/BCH), Litecoin (LTC), Dash (DASH), Ripple (XRP), Monero

These are all so-called alt-coins which have seen quite some boosts in the past months. As far as I can tell, people who are losing their faith, usually turn to these coins. Most of them solve the issue of high transaction fees and long transactions times, but I'm unsure how they would really handle the same load that BTC has right now since a lot more people are trading BTC than they are with the other currencies. It's hard to say. All of these will probably grow as Bitcoin grows, but they all use outdated tech and their scalability issues will catch up to them most likely.

Tronix Token (TRX)

Eh, this is an obscure one. I've started investing a bit of money into it recently since it's very cheap right now (only $0.04 per coin) and it has some potential for growth as it's supposed to help something with content creators, blablabla, didn't listen too much. It's an experiment that has already paid of (I bought some at $0.03). Honestly, you can just ignore it if you're not interested into going deeper. I'm just listing it, because I put some money into it.

Cardano (ADA)

This is another somewhat obscure one. The only reason why I invested in it is because it seems to be more advanced than ETH, but the idea behind it is similar. There's also the interesting fact that it was created to fulfill a vision rather than a functionality and high-profile scientist groups are working on it. Also feel free to ignore it if you're not going any deeper. I don't think it will boom within the next 6 months.

IOTA

I saved the best for last. If any "digital currency" has the potential to actually be used globally within a few years, it's IOTA. It actually doesn't use a blockchain for transactions, but something else entirely called "Tangle". Look it up if you're interested further, but I can tell you right now, this is the only currency that not only doesn't clutter and get slower the more people use it, it gets faster! I'm not shitting you, the math behind it checks out. The idea is basically that each new transaction added into the system requires to confirm two previous transactions. That way the more devices join in, the faster the network gets. This also means no transaction fees at all. And I said "devices" on purpose since the idea is that the simplest IOT devices could handle these kind of transactions so each device would kind of become a consumer and miner at the same time. One possible application of this technology could be autonomous self-driving cars. The car would charge you some IOTA for getting you to your destination and then use the currency to pay for gas and maintenance. They don't have a contract with Microsoft, as was falsely reported recently, but they do work together with them and some other high-profile companies to come up with possible usages and implementations of the whole thing. The only drawback is that it requires a critical mass of users to be able to become fully self-sustained so it might be a miss in the end. Either way, I'm convinced that IOTA will be the world's first widely adopted real digital currency. If not IOTA, then something that tops it.




To sum things up, most of these currencies are probably already in the top 20 as far as market cap goes. I think TRX is the only that's not. If you think of all this as long term investment, the only thing that might be shaky is Bitcoin. Though some believe that Bitcoin will become the new digital gold, mostly due to its high adoption rate so far. Technically it's possible since I don't think the miners that are currently holding the majority of hashing power will easily give up their millions and billions of Dollars. There will always be people supporting it. The question is only when it will stabilize and whether it will fall before that. IMO Bitcoin won't experience as big boosts as other currencies anymore. I'm talking about stuff like 80% (LTC the other day) or 1300% in a month (IOTA) or something like that.

A few last advices I can give you:

1. Don't buy high. Buy when the price drops. You can't predict an increase in price, but if it's already going up, the chances are high that it's too late and the price will come down again. Of course this isn't a rule, but be aware of the risks.

2. Best you just buy some coins and forget about it for 1-2 or 5 years.

3. Don't think in terms of coins, think in terms of your fiat currency. Don't think "I can't buy one Bitcoin, it's too expensive", think "I will invest $1000 into Bitcoin". This makes things much, much simpler.

4. If you want to invest into alt-coins, DO RESEARCH! Don't invest in stuff you don't believe in. e.g. There's this coin called Potcoin. It has something to do with marihuana and payment, but I don't see it go mainstream or have any growth potential or any kind of value besides being a currency so I don't want to invest in it. In comparison to that, IOTA might also be only a currency, but it has the potential to change the world.

5. If anything, put some money into ETH and some into IOTA (50-50 or 60-40 or something like that). Those two have a future. I think that IOTA will go up somewhere during 2018. They are in their beta phase after all.
22
General Discussion / Image upscaling
November 09, 2017, 03:54:53 am
FINALLY! A good solution for upscaling images!

https://letsenhance.io/

CP 2.0 HD coming! :D
23
RPG Maker Scripts / MV Mode 7
November 08, 2017, 01:46:11 am
Some may already know that I started working on a new game in RMMV. It was all shakey until I wrote my first lines of code. xD I am definitely going to continue working on it and I will release some of my scripts to the public. The one most notable would be a Mode 7 script. Now, I'm wondering what kind of extra features you would like to see in this script, what kind of parameters, what kind of configurations.
26
Sea of Code / Randomness and distribution
June 14, 2017, 02:06:33 pm
Those of you who worked with C or C++ probably know that on Win32 systems that the macro RAND_MAX is only 32,767 (0x7FFF). This causes problems if you want random values higher than that since due to the distribution, there are values that you will never get.

e.g. You want 1,000,000. 1,000,000 / 32,767 ~= 30.52. That means that you can get a 0 or a 31, but never anything between these two numbers.

Now, you could take two numbers and sum them up or multiply them, but that breaks the equal distribution of numbers and some values will happen more often than others. It's easiest illustrated with a few small values. Let's take a range from 0 to 2 inclusive. All possible combinations:

0+0, 0+1, 0+2
1+0, 1+1, 1+2
2+0, 2+1, 2+2

If you take a close look at all possible combinations, you will notice that the results are not equally probable. 0 and 4 appear only once, 1 and 3 appear both twice and 2 appears 3 times as a result.

The only way to really handle this issue is to combine the values in a way that preserves the equal distribution. If we simplify the entire thing and say it's only possible to generate 1 bit randomly, we can get the values 0 or 1. Now if we do this procedure N times, we can get a number that consists of N bits and all numbers generated in such a way will always be equally likely to appear and the distribution will be preserved. Since we already have 15 bits (32,767) at our disposal to be generated, we can just generate this value twice and then just combine them by shifting one of the numbers to have a 30 bit value.

I implemented this in our foundation library, you can take a look here at line 46 and 47 (or just find "#define HRAND()" if the code has changed since this post was made): https://github.com/AprilAndFriends/hltypes/blob/master/src/hltypesUtil.cpp
I do casting to int64_t, because I have multiplication and division with another 32-bit int so nothing breaks. Incidentally I think this is the same reason why Microsoft limited RAND_MAX to 32,767 in the first place.
28
Sea of Code / Another reason why WinRT is shit
May 11, 2017, 05:13:20 am
So today I had to work with WinRT again. It was with sockets and WinRT has their own socket implementation. So no c-style sockets are allowed.

The main first issue is the problem that WinRT can't handle reading an "endless" stream from a socket. The problem point is the IInputStream::ReadAsync() method (because everything in WinRT MUST be async). Once you run the method, you can a special AsyncOperation object. You can assign a "Completed" delegate to that object and once WinRT reads at least one byte from the socket, that delegate will be called. Now, the issue here is that if there are no bytes available for reading, WinRT will wait an undefined period of time. This can be a timeout of apparently 180 seconds (somebody mentioned that information somewhere on Stack Overflow, I don't know if it's correct) or basically indefinitely. The catch is that there is no way to ask WinRT whether there are any bytes available for reading. So if you want to keep reading for a while or are wrapping sockets into a higher level system, you are fucked.

Now hold on. Yes, this is nasty, but this is only the introduction into the probably biggest async API design flaw I've seen in my entire life. Prepare yourself for a next-level fuck-up of multi-threaded programming.

So I kept thinking about this issue and an effective way to circumvent it. And I came up with something. I decided to use a buffer which I would then check for data in my main thread method call where I want to receive the data while I just keep calling ReadAsync() and let it do its thing.
Since we're working with async calls here and shared data between what appears to be separate threads (waaaaaait for it...), obviously this data needs to be protected with a mutex (this is a locking mechanism that prevents threads accessing the same data at the same time since threads are undeterministic). So I did that. But suddenly I would keep getting deadlocks sometimes (this is when an already locked mutex is locked in the same thread again and basically means freezing of the thread). I was surprised how this was possible. And then it hit me. I did some testing to confirm my theory and I was right.

You see, usually that "Completed" delegate callback should be called from a different thread. So using a mutex to protect data is absolutely necessary. There is no other way. And most of the time that's exactly what WinRT does. Except when it doesn't. It's possible that ReadAsync() actually finishes before you assign the "Completed" delegate. And you know happens when you finally do assign it? The callback gets called immediately IN THE SAME THREAD WHERE "Completed" WAS ASSIGNED! So if you locked a mutex before assigning "Completed" and then you have to lock that mutex withing the delegate that was assigned to "Completed", you will get a fucking deadlock! Fuck you, Microsoft! Fuck you!

The good news is that I was able to resolve the deadlock by unlocking the mutex before assigning "Completed". But fuck Microsoft and their asynchronous-but-sometimes-it-isn't API. >:(

Here's the final code so you have an easier understanding what I've been struggling with. I added a few comments to make it easier to understand


// this workaround is required due to the fact that IAsyncOperationWithProgress::Completed could be fire upon assignment and then a mutex deadlock would occur
hmutex::ScopeLock _lockAsync(&this->_mutexReceiveAsyncOperation); // ScopeLock makes sure the mutex is unlocked when this method finishes (very useful when throwing exceptions, etc.)
bool asyncOperationRunning = (this->_receiveAsyncOperation != nullptr);
_lockAsync.release(); // has to unlock that mutex again...
if (!asyncOperationRunning)
{
try
{
this->_receiveBuffer = ref new Buffer(this->bufferSize);
this->_receiveAsyncOperation = inputStream->ReadAsync(this->_receiveBuffer, this->bufferSize, InputStreamOptions::Partial);
this->_receiveAsyncOperation->Completed = ref new AsyncOperationWithProgressCompletedHandler<IBuffer^, unsigned int>(
[this](IAsyncOperationWithProgress<IBuffer^, unsigned int>^ operation, AsyncStatus status)
{
if (status == AsyncStatus::Completed)
{
IBuffer^ _buffer = operation->GetResults();
Platform::Array<unsigned char>^ _data = ref new Platform::Array<unsigned char>(_buffer->Length);
DataReader^ reader = DataReader::FromBuffer(_buffer);
try
{
reader->ReadBytes(_data);
hmutex::ScopeLock _lock(&this->_mutexReceiveStream);
this->_receiveStream.writeRaw(_data->Data, _data->Length);
hlog::errorf("OK", "async data: %d", _data->Length);
}
catch (Platform::OutOfBoundsException^ e)
{
}
reader->DetachBuffer();
hmutex::ScopeLock _lock(&this->_mutexReceiveAsyncOperation); // ... because this lock here might as well happen in the same thread as the one at the beginning of this code and cause a deadlock
this->_receiveAsyncOperation = nullptr;
this->_receiveBuffer = nullptr;
}
});
}
catch (Platform::Exception^ e)
{
PlatformSocket::_printLastError(_HL_PSTR_TO_HSTR(e->Message));
return false;
}
}
... // down here I lock this->_mutexReceiveStream and read from this->_receiveStream, but it's not relevant to this issue

29
Tim Cain from Obsidian Entertainment talked about RPGs this year at Croatia's Reboot Develop. It was a pretty great talk. And you're lucky! They recorded it. xD

http://www.rpgcodex.net/article.php?id=10609

There are some really good points for everybody who wants to develop RPGs. One of the points that really resonated with me was avoiding numbers which seems counterintuitive since numbers are kind of a core thing in RPGs. But the thing is: they are not. I haven't watched the video so I hope you can see the slides properly since there are some important visual things that he shows.

BTW, the actual talk is less than an hour even though the video is 2 hours long.

EDIT: Quickly glanced through the video and yes, the slides are properly visible. Have fun!