Battle World RPG

[Xilef]

Battle World RPG has now started development

Brief
So this is my final push at this project. It started in the summer of 2003 as a point-and-click game about my brother and our friends in an adventure, it then moved onto RPG Maker XP as a parody of all RPG cliches out there. In 2008 it moved to VX as a more serious game and now it will enter full development as a complete game.

I am going to need a lot of help and support to get this off the ground, I am confident I can nail the programming and the writing is now set, everything else I am still in and out of meetings over, I know this project has had a terrible reputation in the past but it has certainly matured over 10 years, as I have too.

Thank you very much HBGames.org for giving me the skills to do this and teaching me the life lessons that I have poured into the story this game is about to tell.

Your help in producing this game is invaluable to me.

- Felix Jones

The World
Earth forgotten. Wars finished. Factions disbanded. Humanity dwindling.
The last battle of this world was fought too long ago to remember. Peace under a unified government was warmly welcomed and would have been everlasting.

The ark of man-kind; this is Solitude, a construct so great that it mystifies all of the great wonders of the world.

Solitude is a Quadrantal Niven-Ring, an artificial planet. This desperate construct took hundreds of years to complete, led by the greatest mind of the 3rd millennium; Julian Ambrose. Many died to construct it as the last-hope of the species and these deaths weighted on Julian's life until he was as immortal as his name had become to the Engineers of Solitude.

Many generations passed and knowledge of Earth was lost. Slowly, the population of Solitude began to decline.
No wars were fought as there were no soldiers being born. Something else was lost and it had affected the ability of the human race on Solitude to conceive.

The focus was turned to creation and governesses of Solitude rose to help nurture the planet back into fruition.

But the peace was disturbed by a meteor strike. Great diamonds began to fall from Where-the-Sky-is-High and beasts began to awake on the surface.


Story
You take the role of Gus, the leader of a mercenary company. Joined by Felix, his brother, and their friends; they are a company of hired-hands, there to investigate, travel the deserts, fly the skies and get paid for delivering a successful job.

They receive an anonymous job with a high payment to excavate a very specific section of one of the deserts. Upon returning with the knowledge gained from the excavation, they fly straight into a battle-zone over the capital city of Quadrant 3; Hound-City.

The team fly their airship, The Argon's Past, into the battle and they begin a long journey that spirals quickly into a world-spanning disaster and brings forth knowledge that was lost to the human race. But it is the knowledge lost to the individual members of the party that begins to tear at their mental stability and the panic the world is in slowly draws into the personal sense of each character in this play.

[Airship concept design (Big image)]


The Cleft of Dimension
The space between worlds and the place where all things lost end up. It is known about by the people of Solitude and it is feared. Those who can open the Cleft of Dimension are shunned (Generally all those who utilise the Darkness element, see below).

There is more to be understood about The Cleft of Dimension, no-one has seen it but everyone believes in it's existence.

Elements of Solitude - Reb'lance
The world of Solitude is in a state of balance between the Four Humors, if you don't know what they are; the humors are the elements of Fire, Water, Air and Earth.
What binds the elements is the unseen 5th and 6th elements; Light and Darkness.

The most holy of these elements is Earth.

Between the ages of 10 and 13, a child is Reb'lanced, a process where their alignment is pulled towards an element, the reason is because the elements are useful, being able to condense Water from air can help hydrate the towns that are built in deserts, being able to change the balance of Pressure can bend the weather to your will.

You can be Reb'lanced towards more than one element, creating a fusion of two halves. Wind + Water = Ice, Water + Earth = Plant, Water + Fire = Pressure.
Light and Dark cannot be combined for an unknown reason.

And each element comes with a guardian Phantom Beast.

Ancients of Solitude - Phantom Beasts
Just as the beasts rose with the diamond meteors, Phantom Beasts rose from the ancient mythologies that the people of Solitude held.
A Phantom Beast is born from belief that is so strong that it ties itself to an element and is pulled into existence through it's own conception and birth.

There are guardian Phantom Beasts who will protect anyone who aligns with their Humor along with Phantom Beasts who can be called down at will to give ancient knowledge or to throw destruction onto the battle field.

Phantom Beasts act as both the ability-learning system and as the summoned monster system.

Spoiler: List of currently planned Phantom Beasts

Daedalus - "Jetpack" [Wind Element]
Called down from Where-the-Sky-is-High to drag their victims into the atmosphere before throwing them back down to the ground.

Gilgamesh - "Mesopotamia" [Light Element]
Summoned by piercing a hole into Where-the-Sky-is-High. The 'Ancient King' uses his strength to throw down destruction.

Golding - "Lord of the Flies" [Dark Element]
A giant anthropomorphic Sow with a necklace of thorns pulled tight around her throat. Born from a swarm of flies.

Gaia - "Absolute Hatred", "Absolute Fear" and "Absolute Destruction" [Earth Element]
This Phantom Beast has not been seen for many years, but it's spirit lives on and can slowly be summoned. Becoming more and more powerful as things become more dire...

Fenrir - Not yet named [Water + Air Element]
Ice wolf.

Hephaestus - Not yet named [Fire Element]
A guy with big cannons that shoots flaming balls of flaming fire at the flaming enemies.

Master of the Wind - Not yet named [Wind Element]
A pirate ship driven by a skeleton out of the clouds from Where-the-Sky-is-High. Might need to get extra permission for this one.

Unnamed rock thing - Not yet named [Earth Element]
A stone golem with a big fist. Punches the ground causing quakes.

Macintosh - "Memory and Judgement" [No Element]
Non-elemental damage. This Phantom Beast is born from a lost memory that first must be found.

Roc - "Thunder-bird" [No Element]
Summoned from a spark into the clouds. Roc will fly low over the enemy, trapping them in an electric mayhem.

The Argon's Past - "Not really a Phantom Beast" [No Element]
This uses the code for Phantom Beasts, but it's just the airship that can be called into battle to unleash a barrage of bullets and rocket fire at the enemy.

Yggdrasil - Not yet named [Earth]
Tree that sits on the edge of Valhalla. You will learn more about it once you get there!

Cherie - "Brown Owl" [Haven't chosen an element yet]
A giant toad with a lady on it that casts a status-alignment on the bad guys.

Dragons - "Aether Decay" [Light/Dark]
Not yet fully designed.

Brothers - "Duality" or "Gemini" [Ice/Earth]
Two stars that align and shoot a beam of Ice or Magma at the enemy.

More to come as they are further developed.

Some of these are tied to elements, some have to be bound to a character before they can be summoned. When they are bound to a character that character will have a stat shift and can start learning abilities tied to the Phantom Beast. Any character can bind Phantom Beasts and multiple characters can share the same Phantom Beast.

Characters

Gus
Gus is the party lead and the guy who keeps everyone moving. He is the character that you will become most familiar with as he will act as the main role for the player.
Town of origin: Osterly Village
Element: Earth
Equips: Heavy Blades

Felix
Felix is Gus' younger brother and is the one who keeps the business moving. Where as Gus presses everyone to keep going, Felix is the one who generally manages the company.
Town of origin: Osterly Village
Element: Ice
Equips: Skinny Blades

Andrew
Andrew was the first member of the party to be Reb'lanced as a child. Gus' confident and the clear-minded thinker of the party.
Town of origin: Osterly Village
Element: Light
Equips: Spears

Oli
Oli was never Reb'lanced, but he trained as a mechanic and then rejoined his childhood friends to form the company. He is the main pilot of The Argon's Past.
Town of origin: Osterly Village
Element: None
Equips: Shock-Stick tools

Ali
Ali was hired into the company as a sharp-shooter after Gus saw how good his aim with a specialised bow is during a job that the company was on. He hasn't spoken much about himself but he is loyal to the party.
Town of origin: ??? - Met on a mission in Holdorn
Element: Wind
Equips: Sniping Bows

Lloyd
Lloyd was picked up by the party during the commotion of the Hound City air battle.
Town of origin: ??? - Found during the battle of Hound City
Element: Darkness
Equips: Not yet set

Fred
Fred is good friends with Felix and used to join him, Gus, Oli and Andrew at an annual camping trip. Fred is very protective of his hometown and since the company was formed he had stayed at home, protecting it from the beasts that came during the diamond meteors.
Town of origin: Northfields
Element: Fire
Equips: Guns and lots of them


The Game Plan

The engine is built by myself specifically for scripting complete RPG games using 3D graphics, it is an absolute requirement that I get the engine finished by July (Otherwise I may fail my university degree) and this engine must come with a game-play demo, so you can expect a demo shortly after July next year, during this time I am looking for 3D artists to hire and composers to help me towards this demo.

I will also seek funding during this development time so the game can be completed, I'd like to dedicate my time to developing Battle World but I am a university student right now, what I am doing is developing the engine as part of university projects so I have time to deal with the game in my free-time (I also have a university module dedicated to this aspect too).

I am going to look at my funding options up until January, if I have to do a Kick-starter then so be it, but I will need something to show for that to be effective.

As part of this, I am doing weekly updates on the Battle World RPG website and will be posting development screenshots on Reddit's game development sub-reddit and YouTube videos on my personal channel, this is all to bring forward awareness so when the time comes the game will have a backing to help me convince potential investors for this game.

The engine I also plan to license out as a source of income to help get this finished, but that won't be enough.

Engine Features

Here's a feature-list:

• Network-based game engine - Uses client:server networking so the game has potential for multiplayer dungeon clearing servers or player versus player arena battles.
• 3D graphics - I've shown shots of this in the past, the game currently has 3D models, a shader system and a map loader so I can currently make lovely looking levels.
• Scripting engine - Using AngelScript, basically the entire story aspect of the game and ability to go from one map to another is relying on this scripting engine.
• Gamepad support - The Windows version will support gamepad and gamepads will hopefully come to Linux and OSX when I figure it out in the future.
• Mac and Linux support - The game already runs on Windows and Mac, Linux support needs work on but it should be easy.
• Steamworks support - I can't promise a Steam release until I have the funding and a Green Light, but I am baking the Steam API into the engine pre-emptively for if/when a Steam release is possible.

Game Features

• ATB system - Square's patent expired on it and it's very fun when you tweak the speed of things. If you find ATB a bore, don't worry, I've been thinking this through very thoroughly!
• Gameplay Settings - This is hard to explain, I am making it so you can choose between Speed-Run, Standard and Pro settings in the menu which will tweak the speed of battles and transitions and how inventory and money is managed, the Pro option makes random encounters feel like how you're used to them and the Standard settings will have some extra UI elements that will warn you of where the nearest enemy is so you can run away from the encounter. Pro will have back attacks, pincer attacks, surprise attacks, etc.
• A unique health system - Completely eliminates the scenario of "10hp, 2 steps from exit, encounter, death, load file with 10hp". You will always be at 100% *something* when you enter battle which will prevent you from dying, unless you make lots of bad choices and get hit too much, then HP will take a hit and put your party at risk.
• 4 character party - And you can switch party members when you want. Each character is unique with their weapon and element, but you can of course teach them different abilities.
• A story - I really worked hard on this one for about 5 years now from what it used to be. I had joined creative writing clubs and had developed something that seems huge, the story is very structured though, so developing a game around it (so far) has been easy.
• 3D camera - Lots of cameras to stare at the player running through fields, the world map, standing on trains and flying around showing off every angle in a battle

Here's a really old screenshot of some of the engine work.

And here's a not-so-old screenshot of the lighting system (Which is going to look awesome because it's a very unique system).

Comments, suggestions, criticism, everything below please.

 

[Xilef]

Development Week #2

So the planning phase is over, now we are working towards the first alpha build, I won’t post any dates/schedules, but it is rather soon.

The first step is to define what this build will include, and generally it is a work in progress towards the first demonstration build.

In terms of the engine, I am working towards the absolute requirements whilst keeping the ideals in mind during development, the biggest part of that requirement is having a player running around a world and a menu that can open up, so those are the first two things I’ll be working on.

Again, I don’t have anything to show besides code right now (Sorry those who love screen-shots), the network engine needs some more work, this is especially important considering that the client side needs the network calls to start rendering things. On that topic, the map format is once again loading (But not rendering) and I have drafted up a system that will optimise the maps on load, it works similar to BSP but with the ability to have overlapping partitions, this will be used to speed up the rendering time which will give some more room for the shader system to work.

On the topic of the shader system, for that I’ve written up a method of dynamically recompiling post-processing shaders with a customisable order-of-execution; the plan is to separate the 3-4 post processing passes that are currently in place with a single pass that can be dynamically changed whenever the player changes settings or the scripting engine decides some lighting needs to be changed. The idea is to be able to build up a stack of effects that can be efficiently churned through after each frame is rendered.

 

[Xilef]

Hey all, it's Friday so time for another update. Been doing a lot of university stuff the past two weeks so development hasn't been so fluid, I've got some core systems done and out of the way and when it comes together it will be very fantastic.

Development Week #3

I’ve been working to get something more visible this week, so here’s a shot of the start of the map partitioning system, I might make it an out-right BSP based map format, but we’ll have to see how things perform.

The reason for focusing on map partitioning is because the biggest performance killer was the lack of proper map culling, generating a potentially visible set would be the best culling option for the maps.

The basic idea is to divide entire chunks of the map into branches and nodes that can get discarded when they are not in view so they don’t enter the rendering path.

This system is currently running along side the new network architecture which is on the back-burner while I get the rendering system back up to speed.

EDIT:
Finished up a binary tree generation for the maps.

The yellow boxes are branches, each branch can have two branches or a set of sectors.

So if I want to know what sector a thing is within I can start at the top of the tree and say "Is it in left or right?" and discard the entire branch that the thing is not within and then repeat that for the two child branches of the branch the thing is in.
At the end of it there should a list of sectors tied to a branch (Lists can be made of 1 sector or more), we can then loop through this list and check if the thing is inside one of those sectors, this accurate check is the most expensive part of the operation.

This makes finding where that thing is very quick as we are discarding 50% of the search list in the each iteration, much faster than doing a for loop through all the sectors and testing if the thing is within it (Which is an expensive operation in itself) and then moving to the next one.

 

[Xilef]

Development Week #4

A lot of the slowdown from the older implementations of the engine came from the multiple pass rendering.
The scene would be rendered from 2 to 6 times, each time for a different shader or the skybox.

The problems were:

• It would be drawing objects that weren’t visible
• Even more time spent switching rendering buffers
• The same scene would needlessly be drawn just to copy a view
• A lot of time is spent switching shaders

The first thing I did was improve the culling, which I completed last week; the second thing is to remove as many render buffers as possible and that is what I completed this week.

Here is the test map that I use to test culling, texture rendering and the skybox system.

In this shot you can see the entire map, plus the skybox in the background (Interactive 3D skybox).

What I had before was a that would render in this order:

• Hide the map
• Show the skybox
• Switch to a camera in the skybox
• Switch to the skybox render buffer
• Draw the scene
• Hide the skybox
• Show the map
• Switch to the main camera
• Switch to the main render buffer
• Draw the scene
• Draw skybox render buffer to screen
• Draw map render buffer to screen

I have now eliminated most of these steps into a single-pass inside the scene drawing call:

• Move the rendering view port to the skybox
• Draw the skybox’s contents
• Move the rendering view port to the scene
• Clear depth buffer
• Draw the map’s contents

All of this onto the same render buffer inside a single rendering pass, complete with the new culling code, that’s a lot of time saved, plus it has completely removed the spaghetti code that was the skybox renderer.

 

[Xilef]

Development Week #5

So this week I've been back on the network engine, preparing to have objects on the server appear on the 3D world.

What I've also been doing is testing out stencil shadows, the method is documented quite well on the web, however I have been having a lot of trouble with this one.

The concept is that you first render the depth of the world from the shadow's light source point of view, however this depth is drawn to a shadow map, which is then referenced during the rendering of the world in the fragment shader, what you can do is reverse the shadow rendering process based on the world position of the fragment, so you project the world fragment back into the space of the shadow map, you can then check the depth of that fragment on the shadow map and if it's further than the shadow map then you can presume that the fragment is within the shadow.

I had some very funky graphical glitches with the shadow map appearing all over the geometry and after a full 24 hours of wrestling I gave up, which is why I'm back on the network code so I can focus on getting objects back into the world.

The network code is now separate from the engine internals. The intention is to create a game-oriented network library that can be hooked into other game engines or distributed as a library to easily add networking into applications, this was one of the biggest problems I've had with my past games, I have always found problems with existing network libraries and time and time again, writing a fresh new one has proved less stressful and less bug-prone (Especially concerning latency).

To save time, writing a one-time library sounds like the best option for me, and Battle World is a great opportunity to carry that plan through.



Some extra news; Next week I have a lot more time to work on Battle World, so a development burst is about to happen, expect some cool stuff.

 

[Xilef]

In this update I talk a small bit about XI Networking Engine (Renamed xi Network Engine), the original HBGames thread is here: viewtopic.php?f=179&t=77206

Development Week #6

I've been back on that network code this week!

So I'm going to write a bit about the plan with this part of the game engine.

The plan is for the network module of the engine to be a separate entity that can be re-used in other projects. The network module will be called XI Networking Engine; XNE as the acronym.

The story is, a couple of years ago I create a network (Online and LAN) FPS game for my second-year university project, but the game was incredibly buggy as it was my first journey into network applications and I was unfamiliar with the networking solution I had chosen; Game Networking Engine (GNE). GNE had taught me a lot and I quickly learnt that it wasn't a project that was to do what I wanted to do, I wanted an efficient UDP packet sending service with a reliable messaging system with an easy to use API behind it.

An Example XNE Packet

The above image shows an example Connection Request packet with XNE, built with 4 classes, each inheriting from the above class;

Packet - Base class with simple byte management
QPacket - Introduces Control and Game packet types and gives the ability to encode strings and byte data
Control Packet - Adds control codes that we can catch for the API
Connection Request - An example control packet, has the game's name and the game's network version ID
From this, we can read an incoming Packet from the socket, peak to read it's QPacket type code and then cast it to the relevant type for the API, calling FromBytes() to finally build the packet for reading. In the other direction, we can make a new Control Packet, give it some information, and send it as a simple Packet using ToBytes(), so there is a stack between the socket and the packet that sending and receiving needs to go through.

XNE will also provide session control, the engine itself ticks in the background managing reliable messages, sending batches of Game Packets to users and handling connected clients.

In the future I will make a dedicated section on the website for XNE where the project API will eventually be published.

 

[Xilef]

Development Week #8

This week I’ve been working on collision detection and I’ve come up with some neat stuff.

I had another collision detection system in place, a quick simple one that acted by taking the location of the next position after simulation and checking if it is within bounds before moving it into the offset area, I’d then take the simulation X, Y and Z directions and test them individually, if one were to fail I’d ignore that and only follow the simulations of the others, resulting in the ability to slide along rules, albeit a rather crude system (Where non orthogonal walls had a strange step-collision that would bump the player as they slid along it). This was fine until it failed 2 crucial test cases, at that point it was a failure and I would have to ditch this quick solution for the ‘correct’ solution.

So I’m going to detail this new system.

First of all; The UDMF systems involved in the engine are wholly 2 dimensional, this is the curse of Doom maps (Of which UDMF is derived from), they are 2-dimensional so no rooms-over-rooms and certainly no Marathon-style 5-dimensional portal spaces.

On this limitation we can eliminate any complex collision detection in the 3rd dimension, the Y axis (Up and down), we only need to check the complexity of 2 dimensions, X and Z. What is left is the sector format of UDMF, the mapping system is based on sectors so we can take advantage of this - as well as the binary space sectioning to speed things up.

Imagine that this is a map’s sector with the red large dot being the player and the outer red ring being the width of the player. The collision detection first grabs the sector that the player is within, in this case it’s the black lines representing the walls with the normals pointing into the centre of the sector.

The next stage of the collision detection is to find all the lines of the neighbouring sectors too.

So we have the search-space collected, we then check how far away where the player aims to move to is to each of the walls. The moment the search finds a wall that is within the width of the destination, it will nudge the destination along the normal of that wall until it is beyond said distance. It will repeat this for all walls, nudging the end position until it satisfies the collision rules.

The obvious limitations are;

• Thin sectors can incorrectly nudge the end location despite the movement going beyond the wall’s boundaries. The fix for this is to always add the end position’s sector’s walls to the search.
• If the movement is greater than the thickness of the player (As the checks account for behind the walls too) you can move out of boundaries. The fix for this is to include a check to see if the movement crosses any walls too.

The bonus of this method; Because the end position is nudged along normals, the player can slide along walls with the step that the original method gave, additionally, this is a 1-time check for each movement, rather than a check for each direction.

What is left to do is add the additional rules for stair-cases and non-standard wall behaviours.