Sorry your browser is not supported!

Scenes Module15/02/15 - 10:30 Wall Class

After a few weeks of sickness I continued my work on the wall class for the X-Producer's scenes module. Walls are geometry given special attributes to aid development of architectural entities in the game world or movie scene being crafted. As a game designer, I have experienced through hours of prototyping and AI testing that I need a quick way to create a game level to test the AI, the flow of player movement, establishing vantage points and all of the requirements for prototyping and exploring ways to challenge the players.

The wall tool will be a good place to start when constructing something quick for testing purposes, later to be refined into a real scene, applying textures and themes to the environments. As with most entities, the wall entity can be baked into solid geometry, stripping its attributes to pure vertex data.

Walls can be used as part of the visuals or as a functional invisible entity, such as a trigger to run a function when the players move through it.

The two videos in this update demonstrate the wall height and wall colour adjustment tools we have so far.

The wall height is adjustable by powers of 2 (2,4,16,32,64,128,512,1024,2048 etc) to match the traditional texture resolution for games, and multiples of 5 for other uses. Additionally you can set custom heights.

The wall colour feature will set the diffuse of the vertices in the wall. In future this will also be able to quickly set the wall's texture and shader.

Sports Fiction05/04/15 - 20:30 World Generator

I have had quite an interesting time toying with ways to generate our 3D world from our 2D hexagonal grid. The hexagonal grid I have been working on uses a set of random seeds to determine what kind of land spawns, and what spawns in it; which will determine the kind of activities to take place in each area of the world. Seeds are values used to pick a raffle out of our hat of land spawns; this raffle is passed onto our 3D functions which must turn these 2D tiles;



into 3D tiles:





Some of the up and coming challenges include the need to make all dimensions as seamless as possible, assigning object load calls to display all entities nearby which belong in the tile's area; and thinking of a solution to represent sky's and outer-space in a grid; but it is such challenges which make the task at hand interesting.

It is good to see some progress, the hexagonal grid looks like an interesting concept to work with. It can do more things than just using squares.

All i can say is WOW. You are damn dedicated to this project... Good for you.

Thanks guys. I think the hexagon tiles will work well in the overview layer of the game; which is basically how players navigate between sports events.

I am not as dedicated as I would like to be, with work and a few projects under development; but one has to pay the rent.

I am now working on some network code for the server/client structure of Sports Fiction; it looks like always online will be the only viable path for me, putting more on my server and less on the client seems to be working best for me now; this also means an earlier release of some prototype sports I am putting together.

Zero One World11/04/15 - 19:30 Spawning The World

I now have started to make my game world live. It is an empty place with lots of functionality to be utilised and entities to be spawned. Things will look plain and boring at first, but all the fancy shaders and geometry can come in later after we get decent prototype sports created. Hopefully some who appreciate my efforts will be able to login and play around with the prototypes and physics and have the game update itself as I develop it; but I will first need to protect my work from hackers who cannot wait to break everything or steal my work.

One of the major problems I hit in this project was the function limit imposed by the DarkBASIC compiler. It seems if you like using functions you had better not aim for more than 30,000 lines in a single DBP executable. I have had to figure out how to get over 100,000 lines reduced to 30,000; but that became impossible. Alternative solutions had to be found, such as if you program in FPSC style with the use of select-case events, you can squeeze in much more functionality. The other solution is to use scripting and XML files to store some functionality; as well as utilize an overlay or DLL driven host (a bit like Valve steam) which can be used to manage your player's profile and inventory.

Thankfully, this problem has enabled me to discover some design patterns which could prove to make the program more efficient than it ever would have been without the limit. I think that less functionality on the client means more stability, something easier me to manage.

Time saving procedures
With very little time for development, it has become necessary to reduce the amount of time it takes to accomplish programming and development tasks.


Firstly, I have implemented the ability to edit textures and shaders from outside of Sports Fiction and the X-Producer, and have the engine reload and apply the changes while the game or tool is running; without the need to reload the game world.
I recommend you do the same if you are working on any seriously large game project; if you need to change the brightness of a door, there is no need to restart your game, and most certainly no need to recompile it; the game has got to listen to changes to the files at least in its development state or mode; otherwise you will hurt your development time. You can remove such functionality in your final release to prevent misuse and cheating.


Secondly, I have attached as much functionality into existing functionality, rather than creating the functionality from scratch to stand on its own. This leads to producing 'super-classes', something which is not good for most software projects or any programming career... but I have no choice, only a handful of classes can run in hard code; otherwise most of the time would be spent compiling.
An illustration of how this works is the use of a room entity which contains door and window functionality; rather than creating a class for the room, a class for the door and a class for the window; your room describes what it contains.
What we have here is similar to the iterator design pattern in which things are defined by enumerable components, which inturn are defined by enumerable components. The iterator traverses between each components to run their functionality. This crams things in the sardine can quite nicely, reducing the amount of instance management code; that is spawning and removal of a thing which is of a certain class; so an instance can remove all of what it contains, and can spawn what it should contain much like arrays.


Thirdly, I am using more function parameters than is usual. Not pretty, and by no means a good habit; but a must if you are working in a function sardine can. What this means is more swiss army knives and less screw drivers. With more parameters, there are more modes and options that such functions can work with.
This also means code which is very difficult to read, but at this point I do not think this version of the engine's source code will need to be read by one or two people; and DLL usage will probably come into play by the time any development team is established; there is simply no other option but to make more efficient use of limited functions.

These principles can be applied to all forms of development, from texturing to sound effects. Automaticlly update parts of texture layers using linking and using the same sound effect in various areas of the game by adding slight adjustments or modulating new wave forms with the existing.

A quick word to some who have been worried about resources. Do not feel saddened if all of this makes your project seem unblessed with time, be grateful that at least you can make what you feel like making; some developers with all the time and money in the world can't create what they want because it is all up to the corporation and publishers as to how the game is to be. No amount of time or money can guarantee a fun game, since fun is a complex science broken down into many elements which deviate from logic, which is why game development is art form.

Zero One23/04/15 - 19:30 Foundation soon to be completed

The foundation of the engine is soon to be completed after 2 years of planning and development. In the earlier stages of the development, compiler crashes led to the splitting of functionality to be pieced together into a new more efficient gaming foundation. Some of the first pieces of that puzzle involved introducing the .NET framework and XML. Now, the final piece of that puzzle is almost in place which involves getting the engine to compile and loading of the content for my games using XML.

For the first time ever I have managed to get ZeroOne's DX9 based foundation to compile using DBPRO. Originally containing over 4,000 functions, the foundation of the engine could not be compiled because the limit is somewhere around 2,000 functions. It seems the line length had little impact.

Today, we now have a foundation with much more capabilities all pieced together with just 1,600 functions (in 40,000 lines), which is far less than the original, and leaves plenty of room for more. In addition to that, we have the option to drop some client side user interface functionality to reduce this down to 1,200 functions (and 32,000 lines); but this will not be required; at least it seems so far.

Thanks to the Matrix1 lookups, the nodes, the XML, scripts and trigger classes; most functionality will not have to be compiled.

Additionaly this is the first week the engine has been able to load its own 3D file format for the 3D objects. Most of the geometry for my games will now use my XML based X-Object, X-Scene or X-Entity files rather than Direct .X or .DBO files. This enables me to load content without pausing the gameplay, and it helps me to manage the assets more effectively, loading attached data from the database per object, limb, polygon or vertex.



Key Systems Included in the foundation

- 2D and 3D User Interface
- Shaders and Materials
- Point Sounds and Vertex Sounds
- XML Assets
- Terrain based AI
- X-Object / X-Scene / X-Entity file formats

New Challenges

Now that the foundation is pretty much in place, I have to get more used to working with full length compile times and many many globals in one DBP project, and some new challenges have arisen:

X-Surfaces
The XML based surface format I put together allows me to refine details, sub-divide blocky geometry and is intended produce irregular shaped (non-heightfield based) terrains; important for Sports Fiction and a strategic fighting game I currently have in its design phase.



The X-Surface uses planar based geometry intended to build terrain which extrudes along any axis instead of just up or down; for example caves and cliff sides. The resolution of the surface can be altered, and nested but this is not the issue. The surface loading function is about 80% complete, the geometry appears fine in some cases, but in other cases things do not line up as is shown below.





I have displayed the location of the vertices by using a cube object and the vertex spawn function; something to later be used for particles and interaction with verticies. As shown in this XML based test scene the surfaces do not line up as intended.



We also have some UV mapping issues with up facing normals; but I have a strong idea where this error is coming from. Because the bent polygon on the left of the image is making the constructor think the polygon is on a wall and should have its UV coordinates set to an upright wall based state.



So in this next week I will be focusing on correcting matter of irregular surfaces.

Other Problems



Other problems include a crashing lightmapper call when advanced scenes are loaded, some minor 3D UI variable conflicts, and some conflicts from various functions defined in seperate projects only recently merged into one.

There are quite a large number of functions which work really well, such as the new material system and the loading of X-Objects; and my Terrain AI seems to fit in nicely; but my focus is to correct the key problems before moving into the next phase of development, the development of game content and performance tweaks.

Zero One31/05/15 - 11:30 Project Status

Greetings all. I hope all has been well. This has not been my kind of month, working on what I want to work on, but sometimes things get a little busy at the day job, and other times it gets so busy it uses up most of my project work time. I have this software project and a secret game content pack I am working on which are all established to entertain and facilitate.

So now what?...

The alarm bells are ringing, which means it is time to find a new day job which requires me to undertake less leadership, leaving more focus on my software; promotions are all nice but not great if it is not your goal.

In all that, here are a number of things I did find time to work on.



Zero One09/05/15 - 12:30 General Research

In this progress log I will write up an overview of what I have been working on between now and the last update. It will help interested in getting into independant games development to inspire one or two ideas of how they could get their dream game created. For those interested in the actual products be it the use of the X-Producer to build their game worlds, or those who are interested in my game ideas; we will look at some of the latest low level functionality recently implemented.

Although most of my time outside of Sports Fiction and the X-Producer are spent at my day job; there have been a few other project plans in the making which have inspired new ideas for functionality in Sports Fiction and the X-Producer; building the functionality now in these products and making use of them saves me from having to build it from scratch later.

These kinds of decisions have been made because of something I learned from what Gabe Newell stated in one of his recent interviews whereby Valve's games are somewhat centred around the technology they wish to develop; a bit like settling into an area of the industry you aim to flourish in, rather than building functionality for singular use, build something that leads to facilitation in various products, advancing your technology for the future.

An example of this principle in DarkBASIC programming is to put a little more emphasis on the kinds of functions to make use of in after you have finished your product; not just the functions required to make the current product, which may or may not be the product idea to make it. This may also require you to do what I have done which is to expand the framework into other APIs and technologies because you may find that in the future, your software may depend on ancient tech and will die off with it. By making your design more abstract and portable, you have the option to port your engine to current technology if dependant on depreciated technology.

On that note, the following list shows some of the technologies I have been either experimenting with or studying, some from since the beginning of the project, others, recently:


• WebGL
• ASP.Net
• MsSQL
• PHP & MySQL
• HTML5
• TGC's AppGameKit
• JQuery
• Open GL
• DirectX 11

It seems that aspects of Sports Fiction gameplay could be enjoyed on your mobile phone or internet browser on any internet enabled device such as a TV or tablet. I will be researching this matter further so that I can do my best to allow you to enjoy some of your game experiences on most of your digital devices.




Zero One09/05/15 - 12:45 Interpolation

One of the main systems I recently implemented was the object animation system. The first aspect of this system deals with how things move from place to place, and how gaming effects transition; we will discuss the use interpolation.

Interpolation is a mathematical tool often used in the field of computer graphics and video games. It deals with inbetweening, which is the process of generating intermediate frames between two images or in many cases two numerical values.

The use of interpolation provides a means for generating smooth transitions from one value to another, a handy animation feature I have recently implemented using the following Dark BASIC vector commands:

HERMITE VECTOR3
CATMULLROM VECTOR3
LINEAR INTERPOLATE VECTOR3

the floating point smoothing command: CURVEVALUE

and some of my own interpolation commands including: LERP# and SMOOTH# which I have provided here:



These all take some kind of timespan or normalized scale, and return back a new value which leads toward a target value.



I the field of animation, a set of key moments are established to define the overall movement or alteration; these animations are measured by frames, and the key moments are called keyframes.

Interpolation can be implemented to smooth the transitions between such keyframes, and different types of interpolations can be used to create different effects which can build anticipation and tension.

Zero One 16/05/15 - 11:30 Interpolation

As highlighted in the previous update, animation has been the development focus this term, including the work on my own character animation and event based animation trigger systems. I have been toying around with the use of a single sided character mesh, characters defined with only half of their body modelled which can be attached to another, with slight differences. This should be ideal because the human body is never perfectly symmetrical, and if I can go as far as mirror imaging my meshes I even get away with less bones and vertices for more performance using less CPU and RAM; but all that stuff will kick of in full effect when I sort out my lack of spare time.

For now we will take a look at examples of the use of interpolation, the inbetweeing (or tweening) effect to be used to reduce the jittery transitions and animations caused by network lag and bottlenecks; not to mention the disk space it can save by reducing the amount of keyframes one needs to have datafiles.

To round this update quickly so that I can get back to work, we will look at the effects of some the functions I provided for you in the last update, as well as some of the 3D mathematical functions found in DarkBASIC.

So if we were to advance from 0 to 50 seconds; where during each second, a dot is plotted on the screen, where each dot represents a progression from start to finish using a tweening effect, what would the outcome be.

The first function we will look at is the easy one, a very familiar command function in the DarkBASIC community; it is the CurveValue function. If you have never used the function and have no alternative, or you do not know what it does, here is your chance to gain some understanding.


Curve Value



In layman's terms the CurveValue uses a current and destination value to determine whether the current value needs to change using a curved transition. If it does, an additional parameter, the speed; or what I like to call the smoothness parameter; determines how smooth the value should change from the current value to the destination value, affecting the arc in the curve. You will find that any smoothness value below 1 is undesirable; a value of one is pretty much instant (with no interpolation), and a value of 20 or above creates a nice curved transition. The illustration above shows how the inbetweening occurs over 50 steps, notice that the value does not just jump from start (the top left) to the finish (bottom right).

We can also play around with the smoothness parameter, supplying the maximum animation time minus the current animation time, instead of a fixed speed value; this adds some acceleration until the time is complete. Acceleration represents how fast something moves from a standstill. This change in parameter somewhat reverses the behaviour of CurveValue, whereby it accelerates to the destination instead of decelerating towards the destination from a significant velocity; now most of the dots appear towards the start instead of the end.




Smooth



The smooth function was something I uploaded for you in the last update; it is not a function supplied by the DarkBASIC language, but it is quite simply a version of CurveValue with both acceleration and deceleration. Instead of having the item you are animating advance quickly to its destination without any acceleration, this function gives eases the value in; and then when half way there, the item slows down to a halt because of the deceleration. The smooth function uses a ratio based parameter instead of a speed/smoothness parameter. I use a lot of 0.0 - 1.0 ratios in all of my programming so it sits well with my work across different programming languages. No matter how long the animation, the start is always at 0, and the end is at 1; this is the same with the next function I provided.


Lerp



The Lerp term is short for linear interpolation which attempts to create a straight transition from point A to B (no curve, no acceleration or deceleration). This should be equivalent to the Linear Interpolate Vector3 command found in the 3D Maths library of DBPRO.

Now at first glance the tweening motion looks rather boring, but if you look beyond the surface you will find this to be extremely useful in animation, and in other areas of software development. The function essentially provides a ratio between two values; and if you play around with the ratio parameter you can create additional tweening effects as demonstrated next.


Arc



The arc effect uses the linear interpolation function with a slight change in parameter; instead of interpolating from the start and finish, we instead interpolate from the current value to the finish (or the next value); similar to what is done when we use the CurveValue command, with a little hint of acceleration at the start, quite similar to the smooth function.


Catmull Rom



Without going into technical details about the subject, Catmull Rom interpolation in the DBPRO world performs a more advanced tween effect using not 3 parameters, but 6. This is a vector based function, therefore the first parameter is the target vector, the current result of the interpolation will be stored in the target vector. The command used was 'CatmullRom Vector2', but you can use the vector3 or vector4 versions if you need. One could write up a CatmullRom algorithm to create a single scalar value return function as we did with the linear interpolation, but the Catmull Rom functions is more useful for working with vectors.

The next 4 vectors can be seen as control points and coordinates; but it depends on how you intend to use the function. In the diagram, the second vector (first control point) is the previous position.

The third vector (second control point) in the illustration shows where our animation starts, and the forth shows where it ends. If you look closely you will notice that the fifth vector (or forth point in the diagram) is ahead of where the curve is pointing, and the second vector (or first in the diagram) is the point where the curve appears to come from. This is a useful tool for tweening old and new positions of entities moving from one place to another with not much detail indicating how the movement occurred; such as when limited to a few network packets transmitted over a network connection or when you want to save complex coordinate calculations by providing a guess of location between keyframes.

Like the Lerp/Smooth functions I provided, the Catmull Rom command uses a ratio of 0.0 - 1.0 to determine the phase of motion. 0.0 meaning the start, and 1.0 meaning the end.


Hermite



The final interpolation technique I used was the Hermite command 'Hermite Vector2', but you can use the vector3 or vector4 versions if you need. In the DBPro world this works quite similar to the CatmullRom technique, only the parameters represent different information. As shown in the illustration, the third vector (or second point) indicates where the curve is pointing at the start of the animation, and the last point (the fifth vector) indicates where the curve is pointing at the end; different to the Catmull Rom example where curve comes from a previous point; here the curve heads towards a given point before advancing to another point further in time or dimension. All of the motion is defined by the ratio supplied in the 6 parameter, where 0.0 is the start, and 1.0 is the end.

There are other types of interpolation such as bezier and spline; but I have chosen to save these techniques for later because I have most of what I need for my urgent tasks.

With all of these interesting ways to move something from one point to another, what you can achieve with these effects is down your imagination; be it to animate a flying spaceship along a path, smooth out button press input or to smooth out the vertices along a terrain, the choice is yours.

You are one bad a-- dude. keep it up.

Thanks sepp!!

After a few months of planning, and changing jobs, I am preparing for a new development period spanning from this moment, for at least 2 to 3 months. I have managed to schedule at least 2 days per week to work exclusively on the project, starting with what I am programming today, the ocean, terrain, clouds, shadow mapping and tree pipeline; thus providing a realistic view mode of the hexagon grid, specifically for competitive sports events.

I look forward to sharing the development experience. I will be making use of the interpolation features I introduced in the past two updates, and will be discussing shader techniques for the rendering scenery in 3rd and 1st person views and other interesting topics.

That's good!

Looking forward for updates.

Lol. 2 days per week is way better than 2 hours per week. Hopefully you will get a decent amount of time for your project as well; it just has to come first after the rent.

looking forward to it

Zero One15/08/15 - 10:25 Current activities this summer

The weather has been reasonable this summer, here in London, with a few short spells with rain here and there. The temperature has been moderate, which I love because of having to work on the development project indoors.

Gamescom
I have been following the Gamescom event, and in particular the CSGO competitive gaming scene and have noticed how incredibly hot it is in Germany at the moment. I do not think I could stand the heat while trying to concentrate on the work I am doing, which by the way has been as plentiful as ever. It is going to take some time to get back in the swing of things writing up the progress updates on this WIP series.

Observing the cool games on display at the Gamescom event has inspired some new ideas which will be tested in the near future.

Development skills
To start off after a long period of minimal spare time; I have been studying various games development skills and techniques to get myself back into 'productive mode', and I am slowly getting there.

Skill Refresh
Some of the skills have already been learned in the past, but needed refreshment; such as DBPro programming obviously, 3D modelling with Blender and my own modelling software, dotNET development so that I can continue building the DLLs for the game and the editor; and various texturing and graphic design work flows.

Additional skills
Some of the skills I have learned over the past 3 weeks are new; and I look forward to making use of them in the project. They are skills related to an important aspect of the final third of the game's development before establishing a playable alpha release server.

The skills are based on generating the game world and building short and long-term challenges for the players. They include geometry generation, bitmap texture painting, relation database design, data collections such as binary search trees, methods of designing floorplan layouts, bezier curve graphics, isometric icon production and game world typography. These are topics which well be elaborated over the next series of updates.

Requirements
All of the requirements of the end product are broken down into sub-projects so that such requirements can have solutions organised without complicating the unrelated. I have been referring to these sub-projects as modules; given the modular form of the software, and for convenience of reference they have been represented by 26 alphabetic characters (a-z). The game editor has even been seperated into sub-applications based on these modules.

Two of the modules I have been busy working on over the past 2 weeks are the Brush and Graphic modules. Here are some interesting new features I have coded.


Worlds Module - 15/08/15 - 11:00 Typefaces



The graphics editor and its game-runtime module will have a close relationship with the brush module. Most of the vector and typeface requirements will be handled by the graphics module, and the texture and bitmap requirements are to be handled by the brush module.

Current needs
I have been focusing on the requirement for the game to feature lots of sign-age on roads and space stations, graffiti on walls and designs on vehicles. I need the graphics editor in the X-Producer to be able to create such signs and text graphics and prepare them for use with DirectX (and in future Open GL and Web GL).

Typeface Templates
Most of the signage will feature typography designed to set the scene, guide the players or make pretty things, look prettier.

I built this font gallery mockup which scans through system fonts and displays them in black on a transparent surface so that I can pick the font I need to use for a given texture, and apply some colours.



Search engine
There is simply no time to be going through each font one by one until you find something you like; I want them all on screen so I can compare them, tag them, categorize them with properties and export settings and refine my search using the filters designed in the query editor, and power searches using regular expression code (remember that?)

Next
Now that all the fonts are on display in this mockup, I will step through some of the tool buttons in a future update.

Now, do you notice something interesting about these font displays in the above screenshot, besides their colour? We will elaborate on this in the next discussion about the Brush module, which has some of its functionality in action, in the screenshot.


Brush Module - 15/08/15 - 11:30 Brushed typography



Brushed typography is quite simply text treated like a texture. Those familiar with games development or have played games for quite some time will understand that games use special programs called shaders which make things look realistic, or creatively abstract.



Shaders are not just for 3D objects in a typical RPG or FPS video game, they are also for 2D objects. I'll repeat that again, shaders are not just for 3D objects, but for 2D objects in video games and other visual software; even the visualization panel on your MP3 music media player software and the minimize window animation of modern operating systems implement shaders. Therefore we are able to apply shaders to bitmaps, which can contain typography, which brings us to the concept of brushed typography.



Usage so far
The screenshot above shows how the text in the graphics module's font gallery mockup has had some brush styles applied to the typefaces. Without brush styles, the text would look flat and lifeless without 30 minutes in Photoshop; but unfortunately I have more important things to be doing each 30 minutes of a given day and will need the 'Photoshop-ing' done pronto, otherwise game over.

Importance of shader programming
The graphics programming industry has been moving away from CPU command line graphics towards shader graphics for over a decade, and the new gaming hardware and APIs are becoming less forgiving towards unwillingness to learn how to use shaders. Shaded UI and typography are just a few of the reasons I recommend learning how to write implement shaders if you want to get into games development; it is becoming a must have skillset alongside conventional game programming skills, and need not be limited to realtime effects, but design time effects also.

Brush Module - 06/09/15 - 11:30 Alpha Channels

Todays reflection
Looking at the task I am currently working on I have seen that there are a number of situations where the use of alpha channels may be used to create some interesting effects. I felt it would be an interesting short topic for those interested in learning a bit more about them.

An important feature of games development, graphics programming and an integral part of the text generator I have just created for sign based texture production; alpha channels can be used to solve a wide range of problems.

Why do we use channels in digital imaging?
In every image you look at on screen or print out onto paper using a desktop inkjet or laser printer, the resulting image, be it of text or photographic nature, you will find that in most cases, 4 components are required to produce what you see. 3 components, or channels, are composited to produce the hue (or colour) of the pixels which make up the image.

In screen based digital imaging, the three first channels represent the Red, Green & Blue channel; often abbrevaited as RGB. In inkjet and laser printing, Cyan, Magenta and Yellow are used. Without going into detail about colour theory and the relationships these colours have with each other, for now let us conclude that in screen based imaging, RGB colours are additive, as opposed to printed imaging where CMY are subtractive. So what do these colours subtract from, and to what are they added to?

The fourth channel in CMY is the key (or black) channel, hence the more familiar abbreviation of CMYK. In a subtractive process, the amount of colour outputted darkens and thus subtracts the brightness of output image. And so in screen space, additive RGB colours increase the brightness of the pixel.

The alpha channel, the fourth component, determines the amount of colour (or tone) added to the resulting image; regardless of how complete the other 3 channels are, without any alpha value, nothing is visible. With an opaque image, with no colour values added, we get black. With all colours set to their maximum, we get white. With all set half way between their minimum and maximum, we get grey.



How alpha channels are used in DarkBASIC
Alpha channels and image transparency are used with most imaging and texturing procedures in DarkBASIC; from animated sprites to shaded materials on 3D objects.

For one, image formats such as PNG or DDS can store an alpha channel which determines the transparency of a rendered image. Using the transparency mode of the image pasting functions or sprites will ensure transparent pixels remain so.

Transparency can also be overridden by manipulating the pixels defined by image files, viewport cameras or 3D object polygons. Methods of overriding such alpha channels include the implementation of shaders, memory block manipulation.



Memblock usage
As illustrated by this memblock image diagram, the 4th byte of every pixel determines the amount of opacity the pixel contains; given the depth of the image; there may not be an alpha channel included. Change the value of the 4th byte of each pixel will animate the transparency of the resulting image. The values are in the range of 0 to 255, stored as unsigned bytes.

Shader usage
In a shader program the alpha channel can be obtained from either the .a or .w field of a float4 colour variable (similar to a vector4 ). The .r or .x, .g or .y and .b or .z store the red, green and blue values respectively, where x is an alias for r, and so on.

Both of the following examples of variable declarations perform the same function: float4 newColour = float4( oldColour.xyz, 1.0 ) and
float4 newColour = float4( oldColour.rgb, 1.0 )

two examples, with the same result; a float4 called newColour, assigned with the rgb of the old colour, and a value of 1.0 assigned to the alpha channel.

In the HLSL shader programming world, colour values range from 0.0 to 1.0, instead of 0 to 255 as is the case in DarkBASIC and in the Adobe creative suite.

Animation
By animating the values of these pixels via memblock or shader, you can achieve some of the results I demonstrated in the previous update, where one image is blended with a underlying image to create the illusion of being a single material or screen rendering. And there are many other interesting effects that can be achieved which will be discussed soon.

My recent fun activities - 15/09/15 - 21:00

Browsing the AppGameKit projects
In this update post I will take a brief momemt to comment about a number of works in progress and showcases in the App Game Kit area of the forum. I often browse through some of the interesting dev blogs and WIP threads around the net, so every once and a while I will share my thoughts in this thread.

I also spend time looking at most WIP threads here in the general WIP forum within TGC, and at some point I will talk about my observations here; but I'll start off in the other WIP section because it is the busiest at the moment; and I know some of you guys who do not follow AppGameKit may forget to visit the section and so the developers are likely to welcome your sincere attention.

So let us take a look.

Rush to Adventure By Digital Awakening

The Rush to Adventure project is a 2D adventure game, developed by a popular swedish member of the TGC forums, Digital Awakening. His development page is one of the first pages I visit every morning, particularly when he is able to work on it; because, as we all know, a lot of independent or hobbyist game developers like myself have to juggle with spare time between outside work and game development. Even with my extra spare time recently, I still have to spend most of it sorting out 'stuff' outside of the project; you know, all the boring things that could possibly be performed without killing you; and so I have been following the game's development for about a year, it is a great idea; one of the best examples of retro gaming with great efficiency and clever use of anticipation in its delivery.

It may have come as a surprise for some that I would look up to a retro themed game like that, me favouring to work in 3D development for my games and my workshop for Valve's CSGO. But be it 2D or 3D, there are many forms of the same principles of gameplay.

Rush to Adventure features a set of challenges formed in great craft block by block, with not one single pixel out of place.

To keep this brief, one of the main lessons we can learn from the project, besides never loosing focus on your work and working hard to complete the tasks you set at hand; is the lesson that you do not need fancy physics engines, advanced lighting systems with dynamic shading subsystems to create an intriguing experience for the player; you just need enough to make the point you want to make, or tell the story you wish to tell, and every pixel means something.

Fight Fortress By Blendman

Now to be perfectly honest, most of the content this developer produces is of the most outstanding and well polished nature of indie games development around. I could spend hours on major development communities outside of TGC and can struggle to find any implementation of game and graphics design quite as clean and attractive as Blendman's work. It is one of the reasons I stick around because alot of the hype around larger development tools stops right at the point where one asks what great game has been developed in such tools that has not been developed with almost limitless human resources.

I picked this game because it is the one on my mobile phone, and the one which I find the most interesting; but there are other projects you can find by searching his name in the forums. Robot Tower defense is another example.

It is a typical tower defence game with projectiles being fired by turrets and special units who can be engaged into battle. Its application of 3D pre-rendered graphics is pleasant to observe, and the game has the potential to entertain. Unfortunately there has not been much development activity in recent times, but it is a decent game and I'd love to see more work like this in future. It is a shame the developer did not continue to take it to the next level; at least from my understanding because he have moved on to develop in other tools.

Insel Simulator By Jack

This project features an island exploration simulation, and is a bit of a technical framework (somewhat like mine) which is to be developed into something superior in the future; but so far it is a fully working simulation which I have installed on my phone.

Jack has been working on the project for sometime, which shows his dedication and consistency as you can observe through is regular updates. There are a number of cool snippets he has provided and is a good place to look for AppGameKit 3D inspiration.

The island features seas, islands, animals, water, buildings, furniture; I'd actually like to see some zombies and a few shotguns added to it, but that's my opinion.

I find these island simulators and open world games are coming back in fashion, there are quite a number of popular open world zombie games and survival games out there which I think stem from the Minecraft in one way or another, and are a pleasure to play and watch. It inspires me to open up some of my own ideas for world exploration.

Jack's project is still to this day being updated on a regular basis.

Kingdom Battle GroundsBy SoftMotion3D

It seems I am writing a bit too much at the moment, and the clock is ticking away, but I'll squeeze in a few comments regarding two more projects. The first one is by SoftMotion3D, a member of the community who has produced quite a number of tools and games using TGC tools.

Kingdom Battle Grounds is in early development, and looks like one of the most promising games in the forum. Whilst I do not find myself reading much of the comments in this particular thread, to be honest in this case it is the videos which draw my attention, since there isn't a great deal to read in the thread, but plenty to watch.

The game uses 3D voxels in an interesting way; the characters and the levels are composed of a number of cubes which form an animated experience. The best way to understand what I am talking about is to go see for yourself.


David's Platform Game (Working Title) by DavidAGK

Finally, David's Platform Game is somewhat of a framework project which provides some interesting development tools and gaming features for the development of David's up and coming game.

I have always loved 2D platform games and always will; no doubt one of the main reasons why I often visit his development forum thread each day to see what's new and how things are working.

I commented on his use of modular components in his framework, which is something I would have done if I were creating one. The project itself was posted a year ago and has been in continuous development since, a pleasure to follow on a daily basis.

Other projects
Now I think I will conclude this little section about current projects with the fact that I am not able to talk about the many other wonderful projects on the AppGameKit forum; but I do follow them and find them to be interesting, but these particular projects have something about them which attracts my attention on a daily basis for one reason or another, or are the games I have installed on my phone.

My taste in mobile gaming is quite partial to platform games and adventures; and it shows by my comments. Perhaps in the near future I will comment on some projects created in FPSC Reloaded and DarkBASIC. But for now, I will now focus on my own one. I hope this will encourage more developers to create projects like the ones above if not something new.





Using Alpha Channels in Animation - 15/09/15 - 20:30 Part One

Animation
As I mentioned in the previous update about alpha channels, and previous updates about animation; I feel it is time to reflect on some animated effects I have been planning to work on which make use of the alpha channel to achieve interesting results.

In some situations I will be making use of display boards and monitors inside the game world which need to look like they are actually using transistors or LEDs to display the images or footage being rendered on them, using textures. One of the simplest ways to achieve this effect is to make use of the alpha channel as a way of exaggerating or illustrating that the image is made up of pixels (although not far from the truth).

We can use the alpha channel of one image, to determine what is displayed by another. In this simple program, a few sprites are used to demonstrate how a marquee texture could work.



In the real game, such an effect could not be shown up-close, otherwise the technique it becomes too obvious, and I believe the best results come from tecniques difficult to interpret. The effect is a quick win, and is efficient for situations where the player could never get close enough to the in game monitor to see that the score or sporting message is just a texture covered by inverted dots.

Later on I will recreate this effect in a shader for use on display boards at sports arenas.

Another quick win solution for an animation using an alpha channel is the use of interpolated opacity transitions to make something look like it is moving from one point to another, by rendering a motion blur effect between the two locations. The effect is achieved with 3 images, but looks like alot more than that.

Again, the efficiency is useful for situations where 'authenticity' could never be determined; perhaps far away in a skybox, or occuring so swiftly that it looks like something moved, but all you did was playback 3 animation frames.

nice reviews, would be great to see more content like this in the newsletter

Fully agree with that!

Good point.

Development Roadmap, Thus Far - 18/09/15 - 5:00

Today I will provide brief information about the current development cycle. It is important for me to expose what kind of activities are taking place and what my goals are so that others may keep an eye on what interests them and plan for future use of the end products.
It is also quite cool to share my thoughts and methods with those who need some inspiration; as do I.

I have had an unpleasant year in my previous most undesirable 'yeah-whatever' job because of taking on too many responsibilities leading to the reduction of software development; which pretty much is all that matters to me outside of health and family; software development comes first before running some warehouse... It's about what one does, let what you do be something you want to tell stories about when you grow old.

Now that I have set aside a few months where I can spend at least 2 to 3 days each week tackling the game and tool challenges in blitzkrieg edit mode; I'll take a moment to discuss what has taken place so far this year, and what is to take place onwards from now.

2015's Development Thus Far
Primarily it has been a year of 3D file format development, you may have noticed by the earlier updates on this page of my WIP thread. I have written numerous 3D file formats, parsers and generators for the purpose of building the X-Producer's level development tools and world generators.

Reason for making on 3D file format?
Not all of the software will run on Windows, not all will run via DarkBASIC and not all 3D content is for Sports Fiction; and not all is for DirectX 9.0 (the API which DarkBASIC uses). This puts me in a situation where I need to load my stuff everywhere, be it on a Windows PC or on a mobile phone; be it in DirectX 9.0, DirectX 11 or Open GL. Things just need to work; no 'ifs' or 'buts'.

Creating my own format allows me to adapt, and more importantly, allows me to better control the end user experience; without having to rely on third parties.

I do not want to place my user's trouble shooting experience on someone's coffee break hobbyist plugin development debugging session while you stare a whole in your PC monitor waiting for that update email. I want to be able to solve my problems, not submit them to a feedback forum.

What's the file format like
At the moment there are two aspects; one is based on the traditional DirectX format with some extra features, with the option to use DarkBASIC DBO files where useful. The other is the implementation of Valve's map format, which ties into CSG (Constructive solid geometry) based modelling in the X-Producer, and a new project to be introduced in this update; and integration of Valve's facilities in the X-Producer so that it can export Source ready maps.

I need to figure out what I am going to do to get bones for 3D animation to work outside of DirectX, at the moment I can only use the DirectX or DBO formats to store bones for the DarkBASIC content; but I will need to simulate bones outside of DarkBASIC for phones and web-browsers using shaders. Something I am not yet certain how to do, hopefully somebody does out there in the world of Google.

What's the new project
It is something I have been working on for the past 10 months which I believe will be crucial for me to test out my techniques for establishing good gameplay, prior to implementation in Sports Fiction, the more expensive endeavour. It is a smaller project technically speaking; yet has great potential to quickly establish a new community. It is to run as a MOD for Counter Strike Global Offensive, which I will introduce next before I work on some texturing for Sports Fiction.


Mastery of Tactics - 18/09/15 - 05:30 Counter Strike Global Offensive MOD

A project was started last year and has been in progress for the past 10 months. Its progress will now be logged in this thread, as part of the family of products utilizing my framework.

The latest implementation of my tools is called Mastery of Tactics, a future MOD for CSGO. It will feature training programs and cooperative missions for the first person shooter. It is something I think will fill in a number of grey areas in the common CSGO player experience; I have always planned on making maps for the game, but this is something more than a couple of maps.

Tools
Besides Valve's tools, I am using my DarkBASIC and dotNET framework to provide the end user inventory and mission objective system, and most importantly my service and matchmaking server. The world module will be implemented to provide 3D visualization of map events and overlays for inventory management.

Generally speaking, the more I develop for Valve, the more I find situations where the X-Producer could make this better and that easier; so why not integrate them.

Alot of what I picked up in learning how to write shaders has ended up being used in MoT. Learning valves material system took a few days because of the years of practice working on SF. To be quite frank CSGO is mostly DirectX 9.0, so I am right at home then.

Surprisingly you get 10 times more control and power of your shaders in DarkBASIC than in Source for CSGO. (Not yet used Source 2); so why complain, what complain at all. 8 million people have no problem playing a 32bit game with couple of shaders in 2015 going on 2016; I have no problem with that.

The MoT storyline is something that will get revealed as it is released, but I will go on to write about the development and technical uses of the X-Producer, ZeroOne and valves tools. It makes sense to talk about the MOD while implementing it in ZeroOne; a lot of stuff in MOT will be used in SF, and vise versa; not one part of the buffalo is to go unused.

There are 7 campaigns in the making, which makes up 7 sets of missions and custom games.







Each campaign will feature a classic map for traditional counter strike gameplay. Some are competive, others are great for team death matches and aim matches. The cooperative missions will be the highlight; I have been collecting music and am considering hiring voice actors.









I have been playing all of the maps in progress and I am very pleased with the gameplay. It started off a bit iffy, I made about 20 maps which seemed like fun for the first 2 weeks, then got so boring it hurt like crap. Not a good feeling to spend 100 hours making a map, only having to dump it because it got boring 2 or 3 weeks later. Something I would have never have learned soon enough without making the move to work on this project.

Even a well planned and thought-out map can turn into a shamefully boring one, and an improvised thrown together array of random cubes can become so much fun like an all time masterpiece. It was suprising to see some of the most ridiculous ideas turn into the real highlights of the campaign so far.

It brings a smile to my face when I have to force myself to stop playing my own maps at 2 am in the morning; but it is important to remove bias by playing lots of third party maps and being my worst critic.

After rejecting 50% of the new maps I make myself as being too boring, I have developed my ability to establish and recognizing great gameplay, something this project is designed to have field tested before bring such tecniques into any Sports Fiction release.

Looking forward to seeing how it progresses after its first year in development; although most of everything I currently see must not be shown.




Texturing - 15/09/15 - 06:00 An introduction

I must have created about 200 textures this year; Today I will demonstrate one. Most of the textures I have done for all of my projects have been done this year. Not quite the usual year of programming for me.

The texture I will create in a moment will be based on a process I use to create rusty decayed sheets of metal. It goes like this.

Press the generate rusty metal texture button!

OK, my texture generator is not quite there yet... I am going to have to spend a few more thousands of hours in Visual Studio and DarkBASIC before things get that easy...

At the moment, we have to create textures the long and hard old fashion way. Photography and Photoshop. To be honest, Photoshop and my paint program will always be used even with the precense of generators. What I will use the manual tools for is enhancing that which is generated, not doing the generating...

Luckily, with the presence of the trusty internet, you do not need to be a photographer to create textures for games. Although the skill and resources to take your own photos has its rewards, the time it takes is not worth it for me because like most solo game developers, I have to do everything myself, so I need to compromise focus and attention here and there; and photography is no exception.

I made the decision to outsource my photos, so no need to travel to the beach or construction site to take pictures of sand.


Why am I using photos?
Well, the photos are just 25% of the task to be quite honest. Most of the best texture artists do not even use photos; but I feel that the use of photographs is best for us mortals who do not have all filters and calculations memorized; unless you are making a game like Minecraft or Super Mario World. I could get by without them, but that would mean an hour in Photoshop per texture which is a no no in this situation.

Obtaining a photo is where I start 75% of the time; photos inspire ideas and be used in interesting ways.

Common mistakes with photographic textures
Although I will never obtain seasoned texturing skills whilst also taking on the programming and every known project requirement under the sun; I have picked up some valuable experience over the past 2 years.

One thing to watch out for is the slapping the photo directly into the game and expecting it to look good without any texturing work whatsoever; I mean there must some reason why texture artists can earn more money than game designers right. Most of the time a photograph thrown right onto 3D geometry will not even look the same, let alone good, when the lighting and 3D object shading is taken into consideration.

What every photographic texture needs
For one the texture needs to be made seamless, otherwise you will see unwanted tiles, like the image below.



Secondly, the lighting on the photograph will clash with the lighting in the scene. Shadows and highlights need to either be removed or integrated. When I integrate, I build the scene and its textures so that the lighting on the textures appear to come from a light source; even though such lighting is not dynamic nor light mapped. If the sun east and is the only light source, the shadows must lead west (not south.. and most certainly not in every other direction).

Thirdly, at least with the two game projects I am working on; textures are not just a single image slapped onto a piece of geometry. Actually, most of the simplest of my objects require at least 2 images to compose decent looking material; or a composition of textures and shaders to produce a realistic or abstract looking surface.
At the bare minimum, two textures, one for the colour and one for the lighting; or one for the colour and the other for the shading. These special textures are often suffixed with the word 'map'.

The photographs or generated patterns I start most of my textures with need to be reworked into these different bitmaps.

The various bitmap texture requirements

There are limitless applications of texture, but most of the time, at least so far, these are the ones I use.

1 Colormaps

The colormap's purpose is as described. It will only indicate the base colour of each pixel drawn on the screen. Not the tones or shadows. Sometimes a colormap is not required because the hues are provided by somekind of shader or the light source.

2 Lightmaps

These tend to be automatically generated (with tools such as Dark Lights), but can also be painted. These are used to create static highlights and shadows.

3 Specularity Map (or Specularmap)

These control how much light each pixel is able to attract. Very important for reflective surfaces, and useful for adding realism to most materials; however a little bit more resource hungry than materials without. They tend to be in greyscale; can optionally provide colour bias; but pretty much does most things you do not want your colormap to be doing!

4 Bumpmaps / Normalmaps / Heightmaps / Displacementmaps

These textures are probably what most teenagers get excited about. You gotta be rockin dem crazy bumps!

These texture serve a similar purpose; to define how rough or smooth a surface is to look; and help simulate detailed surfaces; but the different variations of bumpmaps, normalmaps and heightmaps are all very different in nature and application.

In somecases a normal map is prefered over a heightmap; in others a normal map is unsupported and the bumpmap is required by a particular shader. Sometimes neither are required, yet a bumpy surface can be achieved with embossing (I did that in an early shader demo, somewhere in the thread...)

The terminology
It can get quite confusing when you try to establish the true meaning of such terms with professionals, so I will quickly outline what I mean by these terms, and go into further detail in future updates.

In terms of what I do, what I perceive and how I define them, I would refer to a normal map (without copying and pasting the description from the Wikipedia) as an image that illustrates the angularities and extents of the sub-components and details on surface using the RGB colour channels to represent the XYZ coordinates of the details; although the purpose of the channels may vary, the idea is to indicate the angle of each part of the polygons (the bit between the vertices), even though the polygons themselves contain their own angles (called normals, quite interestingly).

I refer to a heightmap as it is described, a bitmap of surface height or extents.

Displacementmaps look pretty much similar to heightmaps, but are crafted for their specific use. The displacement map deforms 3D geometry (and can in some cases generate additional surfaces like terrains).

I would consider Heightmaps and Bumpmaps to be quite similar, although bumpmaps are a more vague term for most of what I have been babbling about. I use the term bumpmap to describe a bitmap which defines the roughness of a surface, and the heightmap as a bitmap which indicates what parts of a surface are to be raised. Which makes much more sense when you write a terrain generator, or make use of a DarkBASIC terrain plugin like Blitz Terrain.

5 Reflectivity Map
This one is used in special situations. I like using textures to control how much a material effects its surroundings. I've always done this, and will continue to do it in Sports Fiction and the CSGO Mod. I sometimes use the alpha channel of the bumpmap or specularity map to control reflectivity; but a dedicated texture allows you to add character, you can do things like control what hues a certain surface attracts. For example blue spray painted aluminium should be attracting alot of, you guessed it, blue.

Another technique used in the early days of Sports Fiction shader programming is to have the heightmap affect the reflectivity, making sure the crevices and cracks remain dark and less reflective than the peaks. CSGO (and perhaps other Source games) has some issues with reflectivity, thankfully Valve's provided some options to use the alpha channels of the normalmaps to control reflectivity.

5 Cubemap
Cubemaps are a complex topic for further discussion another day; these represent the surroundings of a certain point in the 3D engine, projected onto a texture from each side of an imaginary cube. These are used for skyboxes and reflectivity shaders.

6 Detailmap / Blendmap
Detail maps are used to blend aspects of various textures onto the material. The level of tone determines the amount of each source textured added to the result.

7 Special effects
Textures can also be used to apply special effects such as glows, liquid and fur. These kind of textures are exclusive to specific shaders and techniques.

So let's get started.


Texturing - 15/09/15 - 06:00 Rusty Metal


So let us create this rusty metal I have been waffling about. To be honest there are probably 20 or so rusty metals I have done, but I need a new one for a scene I am creating which I want to look really bumpy.

What we will end up with will look rather silly to a lot of people; but one thing I have seen in games development in and outside of this project, is that the best looking runtime rendered materials consist of textures which on their own, look rather bland and lifeless. It is their combination that produces an end result in the game engine that could never been seen elsewhere.

To start off, I will render some clouds and add some noise.
I use noise to make rough surfaces look rough in my engine; you may not need to do it in yours if you are creating a game.




You have to sometimes go extreme to compensate; add a little extra light if your scene lighting tends to be too dark, blur things a little if your renderings look tend to look to rough. It is all down to your style and the application.

Next I will obtain the photograph I am interested in using.




As it stands, it features a lot of bumps and scratches, but these are not what I am after. I need to tone down the bumps because the light source needs to be in the game, not in the photograph. I will rework it into a colormap, something which lacks tone. All the tones of this material are to be computed by the engine, not Photoshop, a principle which would be silly in a graphic design situation but is vital in a 3D rendering one.


I have desaturated the image so I can use it to add some modulation.





I am aware that the darks and lights in the photograph are not necessarily bumps. But I know that what I am doing with the photograph is modulating, not lighting. The end result will look like metal, so I will not concern myself with this problem unless it turns out bad in the game. A touch of reflectivity is what will make the metal look like metal.


Here is the modulated result.







Looks Photoshop airbrush painted and features seams and undesirable looking lines; but I did not spend 30 minutes painting anything, just 2 minutes of cloning and setting blend modes. From experience with this technique I already know that those lines and seams will be undetectable after the next step.

If I did spend 30 minutes on each and every texture, I'd be probably die before ever seeing them in the engine, let alone in the game.

I quite like the rusty red look, I might use it for the next rusty metal requirement; but the intention is to go with a more washed out look.

Here is the colormap mixed with the greyscale image in color mode, along with screening and highlighting to brighten things up a bit. The seams are no longer a concern.





I try to get the texture to be medium in tone so the shadows and highlights of my shaders can do their work with minimal bias. A shadow will not look like much of a shadow on a black texture.

So that should do for the colormap. I do not mind its level of tonality, could have been a bit more flat to better work with normal mapping, but one texture can only have so much time and dedication. Going to need about 800 more.



So here is the normal map.




If I remember correctly, my shaders lookup the reds as the X axis whilst the green represents the Y. Blues represent the amount of bumpiness. I believe this is quite common and is the same in valve Source. The normal maps tend to look pigmented because of all the small amounts of green and red added a load of blue makes it look a bit on the purple side.

Finally I'll make a greyscale version of the texture to be reworked into various other aspects of the material, later on.




So that should do for now; the next step is to test in the engine and play around with shaders. We'll continue with this and other textures in a future update.

</div>

Development Update - 22/10/15 - 0:00

Hello to all following my development projects. I have been unwell for a few weeks but am recovering and getting back into the programming.

What's been going on
I was hoping to showcase the latest progress on character shading and new animations; but I have had to spend more than the expected time working in the X-Producer because I need to finish a very important feature before the end of the year, which is to generate the scenery for the planets and outer space, a set of algorithms which turn basic layouts of the game levels into a animated scenes.

I will now post a brief discussion of a few things I have been doing.



Plants

I thought I'd take you through one of the experiments I have been preparing, as it should provide some useful information for other people developing 3D gaming environments containing plants and trees with DBP.

The purpose of the following experiment is to explore a trivial number of ways of rendering foliage.

Along the fields of terrain, we will need to have placed a large quantity of plant objects. Because there is only a small number of 3D objects we will be able to render on the screen at once; we have to limit the number of plants objects without making the scenery look too bland and old fashioned. We are working with Direct X 9.0 on this occasion; perhaps in newer versions we will have more room to work with when we get round to implementing the new APIs. But for now we need to figure out how to use what we have to create the best possible experience.

A lot of the time with video game representations of foliage are rendered through the use of as few polygons as possible. Whilst a number of leaves, branches and bushes can be rendered with a complete mesh, that is a 3D object composed of polygons; 3D planes tend to get used in situations where the number of polygons are to be kept to a minimum.



So we can most certainly display a great deal of our plants, weeds and bushes with the use of 3D planes. Each 3D plane consists of two polygons, a total of 6 edges; with 2 of them sharing the same vertices.

Whilst that is correct, I am going to attempt to make things a little bit more optimal. As stated, the purpose of the this operation is to explore a trivial number of ways of rendering foliage; with not one fraction in excess of that. However, the common solution is to use two polygons, but I think we can do better than that.

I think, by reducing the complexity down by one more level; reducing the 3D planes from 2 polygons into a single triangle, using the triangle to represent the foliage, instead of 2, we will get a boost in performance. I will observe how it will look, and if I like what I see, I will use this technique in the real game.







So first, we will set up a test of using triangle object instead of planes for foliage. But there is still more we can do to reduce the complexity which could prove useful as additional option for rendering foliage.

For one, we can recall from past experiments that DBPro, and other Direct X libraries, offer superior performance with the use of limbs over objects; so we can represent multiple elements containing foliage using more than one limb.

The engine has to prepare one object for a rendering call; and within that object it we can cull the limbs based on their visibility in the camera's frustum; something which is automatically performed for you in DBP. Culling in computer graphics and video gaming refers to selecting geometry which is required for rendering from geometry to be bypassed (or clipped)

Each limb will contain the foliage and can be culled when out of view. We can set the limb's culling settings to mode zero so that the foliage can be seen regardless of which way its polygon is facing; we do not want away facing polygons to be automatically hidden by the engine.

So that sums up the option of using multiple limbs for foliage; but there are more rendering options at hand. We can display more foliage with the same amount of resources in a number of ways. What we have at this point is a texture with a single element drawn on the surface of a polygon; but what about 2 elements, or 3?

We always try not to assume what is presented is all that is made available by a system, if we take a moment to think about the limitation at hand and take the time to read the documentation, we can find solutions rather than making do with such limitations. In the case of foliage, we have two three methods we can use to have the element drawn on the surface, two of which I will consider for this time, the other, something that is a little beyond the scope of the engine in its current phase.

The first method, is the easier one to set up; which is to simply draw more than one element on each triangle like so.






Multiple triangular limbs with multiple elements drawn on them. One polygon limb is to represent a number of instances.

This approach will present a problem when viewing such images from the side, as shown by this image.




I will not be worrying about this problem because there are solutions for it which will come later; what I am interested in now is the initial options.


Now, the second option at this level is to make use of a shader to change the drawing method of the limbs. There are three general purpose drawing methods for the 3D geometry in shader models supported by DX9. These drawing modes are set by the FILLMODE effect state; the first mode in no particular order is the default setting of SOLID, which draws the object as usual with its texture sampled from and between the UV coordinates of each vertex. The second one is WIREFRAME, a mode which causes the object to have only its polygon edges rendered to the screen, an option typically set by setting the DBP objects wireframe mode on, but also available through the FILLMODE = WIREFRAME effect state setting in your shader's render pass blocks. The third one is an interesting one for use with foliage, that is the mode set to POINT.

The POINT rendering mode causes the texture to be drawn on each vertex, and is often used for particle effects, and is useful for foliage effects such as falling leaves. Setting the fill-mode to point will cause our polygon to look something like the following image (using the original picture introduced earlier):





Which would give us 3 multiplied by the number of elements on the texture to give us more foliage on the same polygon.



We can position each vertex on the branches or the ground without worrying about distortion since the triangle is invisible.



So this gives the ability to produce some interesting leaf dynamics with minimal load on the performance, however there is still more we can do to improve on performance, but before that, there are some things to consider about point shaders.

For one, the point based texture mapping will always draw the texture at its set size. Any scaling of the texture is performed in screen space and will need to be scaled manually based on its distance from the camera; something quite simple to perform by using the vertex shader and the PSIZE setting.

Another consideration is the angle; additional work is required to display the elements at their correct angles based on the perspective of the player. You will have to handle this matter within the shader or with the use of pre-rotated images through a bitmap texture or a camera texture. This is quite a similar requirement of the Dark Imposters plugin which takes snapshots of geometry and renders the geometry on planes.

With those considerations noted; I will for the time being only use this option in the distance where the detail is difficult to see. Closer to the camera I will have the foliage displayed with solid fill mode, and up real close on maximum video settings some real geometry.

One final performance boost
The last thing I will do is use not one triangle per limb, but a much larger number of triangles per limb. These extra triangles will not require additional processing on the CPU; compared to objects and the resource friendly limbs, the additional polygons have a minimal load on performance, providing additional foliage with a few number of limbs.




Now that I have a number of options for rendering the foliage, let's get started running some tests.


Surface for the triangles

I am going to need a surface to place some test triangles on. We have a number of terrain plugins in DBP to use, but for now I will use the Matrix1 multilimbed plane version of the command MAKE OBJECT PLANE. I have this setup in the engine to run custom code on each limb, so I will set up some XML to have our triangles spawned around the limbs.



So now I have a new class setup in the X-Producer for spawning random triangles along other surfaces, and here are the triangles in the viewport, which I will have shaded, animated and textured in the next phase.

never thought about using a single tris for things like grass. very clever Chris.

Thanks. I hope works; as we will soon see.

This looks very promising, I'm going to have to play around with that point mode setting

Greetings once again guys; will be commencing with an update shortly; I have to finish some important tasks, transfer some files and I will be ready to continue.

Looking forward to it. November was really a dead month for the wip part of the forum.

Yeah, I took a new job really ate into my spare time.

Looking forward to an SF update

Lol; the irony was this was supposed to be one of my busiest periods for SF; but turned out into a busy month programming for the rent. But at least there has been a number of nice new tools built for the project which will make for a useful update.

Development Update - 15/10/15 - 0:00

Hello. It has been some time since an update has been made here. This forum post is based on recent developments of tools and principles for future activities within the project.


Preperations

In order to prepare for texturing and 3D modelling, I have invested some time in refining tools and experimentation with some new concepts. I will hopefully find more time to make use of the tools.

Some of the new tools have been placed into the main development tool (XProducer.exe), and the others, have been developed separately for ease of experimentation, and testing before any costly engagement.

Most of the new tools developed directly into the main editor reside in the flow chart based construction module, the Node editor;



and a newer development module based on logical reasoning and calculation tables, simply called Reason editor.

To illustrate, I have used the new tools to generate 2D graphics and effects.



Other preparations

Other preparations include tools for preparing shaders and textures for scenes,



shape generation for world geometry and illustrations,



lots of vector related work,



and some minor character development experiments.




As per usual, the purpose of such experiments is to determine the most viable method of producing aesthetic geometric and textural content I can achieve in this development project and future projects. When a final method is proven to work best, then the method is executed with precision and care.

I will have these aspects of the development revealed in more detail in near future updates.



Node Editor Update - 15/10/15 - 16:00



Here we have some new user interface controls created for the purpose of defining the classification of a node. Node classification is established to define the role of a node in a game or other application. Typical roles of nodes include the programming of game entities; programmatic operations that can be defined without programming code, and can be interpreted in a runtime program.

Attributes



Each node is defined by an XML element which can carry inline attributes, or can contain other XML elements. Attributes carry information about the node and what ever it is defined to represent through the XML. In the development module, the data within the attributes can be defined by the attribute or taken from another attribute through linking. This linking is illustrated a certain view of the nodes; a component used to display data, which in this case is XML, in a way which best illustrates the data for the given purpose. The links are displayed as connected cables between the nodes, or icons, or with other implementations of symbolism. The node editor is to feature a flow chart view and other views such as spread sheet views and tree views. XML is also symbolic of what exists in the application so that other applications can easily interpret it; something which will be shown to facilitate porting and multi-platform design.

The next set of tasks involved introducing reasoning tables. The reasoning tables are a set of logical arguments established without programming, just like nodes, and can be defined in a running application. Reason groups are used to group these tables and are also registered as a node classes as the groups are defined, therefore enabling the developer to use these reasoning tools in their nodal algorithms.




Reason Editor Update - 15/10/15 - 17:50

Logical reasoning is an age old philosophy accepted in most cultures in the rational world, and is an integral part of computer science and practical forming solutions for processes such as artificial intelligence, data management and mathematical calculations; no strangers to the world of programming of video games. This principle is being developed in my products using the reasoning entities contained with the editor module appropriately called Reason.




The primary type of component of the module is the reason table. These tables consist of rows of reasoning objects, and columns of reasoning properties; thus each entry is a reasoning tool which contain properties describing its structure and data.




The reasoning objects are an abstract class used to define two more specific objects of reasoning; a criterion and a calculation. Now in many areas of work such terms can mean the same thing; but in this system the calculation object has its components more aligned with mathematical aspects of reasoning forming a resolution by arithmetic, compared with the criterion objects which are concerned with forming a boolean resolution; the true and the false.



The implementation of these objects and their design will be discussed in near future updates; as well as other aspects of the project. Until then, stay tuned and enjoy.

This is some impressive Stuff Chris. Things are really coming together now. Will you be using the new compiler that Lee put on github?

gets more impressive with each update, nice work man

Thanks guys. I will look into the new compiler (eventually); at the moment I am having to put most of my time into supporting the project. I think I will be getting back into action shortly, but things are going to change a bit. The concepts for the game have matured and I will be field testing some of the components of the game in smaller products for short term projects which I think can help facilitate the application of science and field testing much earlier than initially intended.

It is very interesting what I have discovered recently, how the most important thing I have done for the project, is take a break from it. This has helped me to think outside of the box. Now I look forward to coming back to it with far a superior methodology, a way of production I think will put my previous techniques to shame.

But first, I will need to restructure my online presence and expand this development post into a website, and make more frequent updates. Looking forward to it.

Preperations



Hello to all following the project. I hope all is well.

I have made arrangements to power work through the game mechanics and level loading this month. Providing nothing unexpected gets in the way, releasing an alpha build and providing access to the game server will be the main focus.

Documentation will be written and provided online to help players get started. Not much information, screenshots or videos will be provided early on because I want to play my cards close to the chest; l do not mind being copied, but being copied so early on would be undesirable.


The past 7 days
Over the past week I have been coding a number of character animations and sports foundations. Sports foundations are the framework used to define the fundamentals of each category of sport. Each subsequent sport contains its own scenarios, leagues, items and taxonomies. These sports are futuristic in relation to today, and are to be customizable to a degree in this test release build, if not fully customizable in the next release.

The most difficult task ahead is to develop a seamless installation/uninstallation and particularly the update process. I want any working update to be committed to your installation without hassle, as updates will ideally occur on a regular basis.


Preparing for the gaming experience
I will hopefully be able to set up a YouTube channel so that you can follow the experience without having to play, and to see what the download will offer before committing to play.

Providing nothing silly happens, the server should be able to host a reasonable number of teams and players. I will have some badges made for the profiles of the first batch of players to ever play the game; and the first to play certain sport catagories, amongst many hidden player awards which should be a nice reflection in years to come.


Required dedication

I will post a few progress updates on this release operation over the coming weeks. It will entail a 7 day a week 12 hour per day work schedule, so that I can cover a great deal of ground. I know what it is like to play a game that does not work, something I wish to avoid and have bankrupted myself to make certain this game works, and does its job, provides fun and entertainment.

Whilst many compromises have to be made to facilitate the inception of the player experience with my current limitations; for example low quality animations, inconsistencies, flaws in game design and in the sound and music; at the very least there will be plenty of fun and games to experience.

Holy smokes batman, an alpha version. That's great. Been following this for (years?) It will be great to see your hard work come to life.

Thanks for noticing. Much time has passed. It was expected to take years to make. Very important to pick a subject that would stay interesting, otherwise ones own lack of interest will become a barrier.

It is still only the tip of the ice berg in relation to what is planned for years to come; but during this phase I'll be taking an honest and simple approach focusing on the absolute fundamentals.

Now it is just a matter of turning the prototype into something presentable, distributable and serviceable.

The past 10 hours
I spent this time smoothing out DBP's character animations in relation to physics events. If the animation (particularly the run and jump sequences) looks at the very least reasonable, I will leave it for later when it is time to polish up.

Tomorrow will be the first day spent creating configuration components for sport foundations. These are for configuration windows to be used to edit or produce variatons of sports. I will be taking a gradient approach from simple to complex, with all the intermediate components defined along the way.
Starting with the simplest sport foundation, moving an entity from point A, to point B. What the entity is, where A is and where B is, is down to the given design of the classified sport the foundation supports. The next level of complexity will involve more than two checkpoints, and more than one entity, and variable checkpoint ordering, and variable forms and dimensions of reaching a checkpoint. What the entities can be will be shown.

Wow man, this will be a big push and that's a tough pace to maintain. Wish you luck and I am excited to see what comes out of this. I'm happy to help with testing and feedback when you are ready.

Thanks Ortu

Your testing and feedback will be appreciated; these are things the community are free to take part in. This production will not get very far without effective testing and feedback. From my standpoint I can only focus on the forest, but it is the players who will have a greater view of the trees. Since only I can see the whole forest, it will be difficult to not let my perspective blur my perception of the feedback. For this reason the system will provide means for submitting feedback and gameplay statistics, so that I can readjust where necessary, and provide means for players to implement their own ideas. Whilst I could not spend all day everyday simply reading feedback; at least the statistics and official testing events can help fine tune the experience.

Current Activity
As was stated previously, I am working on implementing configuration code so that the sports can be and tweaked by the community, starting from the simple to complex.

Today, my task is to implement my old scene loading code I developed last year into my new system. I will need the scene loading functions to import gaming triggers and events from various external editors. UV mapping is one of the most difficult aspects of this operation because it can easily take up a substantial amount of level building time. The development assets and tools at hand are not the greatest when it comes to UV mapping, which is one of the reasons why the level design will be efficient; which is not a foriegn ideal in a futurisitic game setting.

Previous Work

Hello to all following the game project. I hope all is well.

As I have made most of you readers aware of, I focused the past month on working the structural and conceptual foundations of each futuristic game sport, and any prerequisites such as entity sub-classes and functions. This game-defining component will continue be the focus this month because there is plenty more to do.

Current Work on gaming experience
A number of other tasks were performed to facilitate the growth of the sports library, and the aesthetics and ethics required to provide a good gaming experience, and to enjoy the experience myself because I do not want to have to play a boring game everyday in order to test it.

Latest features
My recent tasks included the development of the following fundermental features:


- Global identification of player/spectator configurations, contributions and social conduct with ID tags and social profiles; being able to reward the great players, the loyal players and the gems of the contributive community.

- XML based context sensitive content for smarter delivery of fun according to player interests. Most general PC level user interface and gaming expectations can be met given the observed research and feedback.

- Useful audio feedback of critical gaming events ordered by priority and proximity, some of which is illustrated further down this post. Advanced gamers will understand the need to determine the nature of crucial gaming events without being able to see the event from every angle.

- Global lighting procedure which will make the game look efficient without looking on one end of the scale detailed yet cluttered, or at the other end unobstructive yet bland.

Why we need such features
I have mentioned the latest features which sum up the majority of the programming work done over the past two weeks. In a nutshell we have the potential to enjoy the game without the experience being dumbed down too far by an early-on low budget; providing good entertainment software logic such as remembering your preferences accross different computers and keeping you close to your friends and your potential friends within the game world and accross the SF internet.

There are alot of easy ways to make derpy mistakes when designing a large game world, we do not want to be segregating friends with game design and character classification, and we do not want to be clicking through 10 buttons and 5 menu screens to perform a single game action.

Brief indicators of progress
As was stated in the previous update, development updates will be kept brief, leaving me more time to work on the game development.

Importance of development updates
Whilst the updates made here are important for potential contributors to keep track, they are all of what is available for future players to better prepare for action, whether or not they think they will not find interest in such a game, the nature and purpose of the game is not yet made available. The inevitible narrow window of opportunity to get ahead of the compitition may slip by you if you stumble a welcomed revelation too late; something crucial for players of a certain level.

Conclusion
To conclude this update, here are two random illustrations of some content development tasks I have undertaken recently. I look forward to sharing with you the next update later this month.

Can't wait to give this a try. Keep going.

Thanks Sepp, I will need a lot of help play testing.

Good morning, afternoon or evening ladies and gentlemen from where ever you are. In the previous update I indicated my focus and goals related to laying the foundation of futuristic sport in the universe of the game I am working on.

I have selected a game setting which I find really interesting, and I hope will entertain gamers with similar interests. The current work relates to two major classifications of gaming environments available which I want to focus on; gameplay with your character inside a planet or, mostly planet earth; and gameplay with your character in outer space.

These two environments will contain two types of events; sports and battles.


Sports and Battles




Your character earns income through competition in sports, sponsorships, community work, or illegal activities on the side, according to on your own principles and way of survival.

The meaning of sport, and battle in Sports Fiction can sometimes mean the same thing when dealing with certain characters and players you encounter in the game world; the question mark in the text logo could be used to illustrate the question of whether this is a game about sport, the question of which is to be answered by yourselves after playing.

As an athelete in an ideal sports world, one stands a better chance of winning, if one arrives in one piece.




The Two main Environments

The two environments I am focusing on separates the physics of the game and the game mechanics into two major layers of gaming, and thus your campaigning throughout the game will require consideration of events taking place on foot or in the air, or in outer space, on moons or planets, on or around space stations or asteroid mines.

With all the competitors, NPCs and team mates having access to a vast environment; your game-plan will require consideration of the kind of experiences you want to encounter, and the kind of sports you want easy access to; it will not make sense to set up your base near Mars, if you are mostly interested in water sports.

As the nature of the game is revealed to you, you will get a better idea of what to expect and what kind of fun you can access and in some-cases define yourself. A lot of the game, besides the episodic story modes and offical campaign modes, is player defined.

In game location will have a considerable impact on your available currencies, which have varying value throughout the universe from earth continent to continent, space colony to colony.

Thinking about the subject of currency; which I must stress is quite a variable measurement of value according to where you are in the game, I think it is a good time to introduce the basic grade system by showing how to recognize the grade or quality of items, materials, equipment and competitors.

Grades

At the time of writing, the game attributes, items, materials and players within Sports Fiction have a calculated rating. Most of the ratings are relative in the sense that their value or grade may change throughout the course of the game, given the state and population within an instance of the game. For example a rear item is only rear if hardly any item available has similar potential, and only powerful if more powerful than most items or attributes available in the game.

Something interesting will happen when the graded attribute or characteristic is player defined, or based on the skill of the players. The grade is a comparison to what has been performed by players or what has been achieved or produced by them; rather than a database setting established by the game developer.


Color codes are one method of recognizing the grade; it is important to note that the colours red, green, bronze and gold are not used in grading. These relate to other concepts and events.

Two color grades always have their captions in italics; these represent the best quality.

So coming into the game, some of you will recognize the concept and fundamental use of the grade analysis system; for example a green item, which is an item with a green caption, is more valuable or superior than a grey one; and as is to be shown, you will know that there might be trouble if your opponent has an orange or purple caption on their main weapon or sporting attribute.
The key point to remember is that these colour codes are not written in stone on a database; they are calculations based on the current state of the game, therefore a rear item in server one, may not be rear in server two; a superior player in server one may be inferior in server two.

Attributes and statistics of your team or your own entities in Sports Fiction are measured positively, relative to you and your team; which usually means that the higher the number or grade, the better it is for you or your team. Attributes and statistics of your opponents are measured negatively, the higher the number or grade the worst it is for you and your team.

At the time of writing the following chart represents the colour grades of statistical attributes.



At the time of writing the following chart represents the colour grades of items. The grade of an item in Sports Fiction is the current sum total of its structural attributes.



The grade is not affected by the condition of the item; which is a sum total of the hit-points of the item's subcomponents. Sub components, and other details about items will be revealed in the near future. There is no need to check the details of all of an items components to determine its value, but you can if you want more information about why a certain opponent is driving faster than you, or shooting further than you.

At the time of writing the following chart represents the colour grades of opponents. The grade represents the sum total of opponent attributes. In Sports Fictions, all entities which can win a sport or a battle against you are considered opponents.



Each type of opponent contains its own attribute system, thus are graded separately and can only be compared with any similar entity you have possession of.

The following chart represents the grade of your team mates.



The following chart represents the grade of sports or challenges, ranging from not very rewarding to highly profitable.



At the time of writing the following chart represents the colour grades of the condition of items, materials, components, characters, robots, vehicles or spacecraft.



Additional grades and similar topics will be discussed later.

Forcible and Push-able Objects

The past few days have been spent implementing objects which can be pushed or forced with the use of hitting, kicking, throwing, impacting or shooting; essentially the process of moving an object from one place to another without being able or allowed to carry the object with your hands or in a vehicle or spacecraft.

The character animations for interacting with objects which can be pushed or forced are being worked on in Blender and the editor.
The following diagram indicates the functionality of the push or force process. Pulling is also possible with the processes by reversing the direction of motion.


Entities called Push Effects and Force Effects have been coded to enable me to define how objects must be forced, or for players to define themselves how they want to kick or throw a ball, or how an event of physical impact is to affect the position of the forcible or pushable object on the ground, in the air or in outerspace.



Push effects or force effects are not gaming terminology that will be used in documentation, but at this moment in time the revelation of these programming terms help indicate that given a certain weight, characteristic, vantage point, material and force, objects are forced differently given the environment and types of impact, opposed to being moved by singular physics function. In other words, a ball may be thrown further by another player given superior conditions and advantages; a bullet or laser beem may go through a wall at high speed given the material and density of the wall.

Most casual players need not care about this stuff; but most serious players will; speaking of which;

Competitive Mode

I will not discuss this subject in detail so early on, but it is important to establish from now that a competitive mode will exist and will not feature the character leveling system and inventory from the normal game. The competitive mode will have the game mechanics and characters constrained and balanced out so that player skill and team work determine the winners, not the size of one's inventory or quality of ones items.

If your only interest is to play competitively, then you should not pay much attention to any discussion about character levelling , item levelling, inventory and item configuration; these concepts have no real place in the competitive mode, where what is available is determined by the sport and the given challenge.

Global Controls

So far the characters, vehicles, aircraft, robots and spacecraft are controlled in first person, third person or from aerial view using global mouse and keyboard controls. These controls are global for all sports and battles. The rest of the controls vary from sport to sport, or type of role in a battle.

The keyboard bindings can be changed in the option screen (the game window for which I will work on later). Each button can be mapped to the keyboard, mouse or gamepad. I have Microsoft Kinect drivers in place, so if I sense the need to implement it I might provide a few macros you can launch via your Kinect device.
There are more button actions in the game, but these are the common buttons; the ones used no matter the sport or situation.

Of particular interest to you may be the left/right trigger buttons; which control the left or right arms or legs of your character and some robots. You can punch, kick or force using either side of your character accordingly.



The combination of moves you perform from limb to limb will determine the effectiveness of your interaction, defence or attack; and can lead to special combos; something to be discussed in future.

Further details of the system will be discussed as it is developed; with most of the information and showcases provided during the early-alpha release.

WOW! You are creating a whole world around this. I can't wait to try this out.

Yes, I will be using my generator code and some design tools to arrange the gameplay into worlds; cordoning off works in progress and providing access to green lit regions.

Sports Fiction - 05/04/16 Socialogical Design

Greetings all; time for an update log. I will break this down into two posts because this update touches on a number of important subjects related to preparing players for action later this year.

I will take this opportunity to start discussing aspects of the game which provides value for investment of game time for players, streamers and content creators. Before commencing with such discussions I will quickly highlight the activities over the past week.

Activities since the last update include programming of hit-points, health regeneration, breakable entities and physical impact based events which I will elaborate on.

In addition to programming I have been reviewing past and current research on related topics I will now discuss in the first of the two posts. The final post will have the competitive modes introduced.


Research

Obvious to you all, the process of making a great product requires great planning, enhanced by research. With a great deal of planning and research behind this project, I feel optimistic about its prospects.

Now thankfully, video game research is not exactly the most boring subject to have to engage in research for hours on end for 10 years, and relatively speaking it is not the worst challenge in this time period with the abundance of articles, live footage, talks and reviews available online.

In addition to game design, a vast array of subjects from spacetravel, science fiction, human history, geology, neuroscience, precious metals, ancient warfare, weapons, real life treasures, ludology, philosophical subjects such as meta-physics, ontology, aesthetics, ethics and did I mention game design?. This particular selection of topics has helped me to design the game, helping me to think outside of the box and to find new ways to think about the future of video games for the better of the game and your engagement within it.

Since the game is just the tip of the iceberg, I also have to plan for distribution, maintenance, management, dealing with the competition, dealing with problems and providing a good user experience outside of the game, not just on the inside.




Research for Sports Fiction is ongoing; and one particular aspect of the research directly involves interested players or content creators through the analysis and monitoring features of the game.

So the game will have monitoring and analysis functionality which provides me with information that lets me know where the performance, user experience and gameplay works well, and where it falls short of the mark.

I am interested in providing menu links which allow the players to report issues, and have the important issues made evident and placed in proximity to major tasks. Something I will discuss in further detail in a later update.

Another interesting research topic which flagged up a lot of times is the subject of social media and why I think the subject matters for Sports Fiction.

Social gaming and media; finding new friends and keeping friends together.

One of my research diagrams produces a road map of modern online activities. This is one of those diagrams I have drawn up for the purpose of inspiring ideas for the game. I ended up with a complex network diagram of online activities with interconnections resembling a complicated city train map. I just could not complete the 4x3 foot sized A0 diagram because there are too many online activities and connections between them. With all the millions of users and possible interactions possible online, there is no time to cover everything; but the important thing was to find evidence of the useful activities and paths of interaction, or perhaps activities that would improve existing ones if made accessible or constructed if not yet built.

In additional to useful activities, the finding out what everyone enjoys, activities adjacent to gaming, and potential anecdotes such as how people could go from performing something unrelated to gaming to ending up playing with new bunch of new friends in a video game are examples of the value of such research.




Two of the most common occurring activities connected to the most populated branches of the diagram relate to information sharing and social networking. Whether a person is at the office running an online conference meeting or is sharing counter strike weapon-skins with friends or a streaming in front of 1,000s live; all of these people are performing at least one form of social networking or information sharing throughout the course of the day, whether or not they realize it. This is the kind of information I need to provide extra value by increasing the number of possible delightful experiences and making more dreams become realities; whilst preventing as many frustrating experiences as possible.


Put another way, if I do not take notice of the dreams and frustrating experiences; how could I be so sure that I am not screwing up the potential for gain and delight, and habouring avoidable frustration?.






Here are some of the main goals I will use the research to reach:
• Making the learning process effective and just as fun as the core game
• Enabling you to track and showcase your skills, performance and progress
• Making it possible to find your ideal teammates or similar people to socialize with
• Providing invitation tools to invite your friends to the game to join your team, episode or campaign
• Allowing you to follow and learn from advanced players who share their techniques
• Providing management and promotion tools for your game team, events or contributed content
• Providing buttons for sharing interesting and funny experiences online
• Providing tools for publishing scripts, key binds, tips and guides
• Providing means for identifying and reporting cheaters and internet trolls
• Other important goals; why not mention some?

This part of the research will make it easier for me to remember the point of view of the user and their objectives whilst laying out the structure of the game and the experience around it.

I will continue to discuss these research and application topics in further updates.

Now I will discuss a little bit about Sports Fiction party mode, the latest programming tasks, and progress on developing the Sports Fiction competitive modes. The campaign mode and episodes will be discussed in a future update.





Programming of game world sites

After spending some time working on the fundamentals of forcible and pushable entities, it was time to start coding the site process, a process which determines which entities, games and NPCs need to be loaded into the rendering and physics simulations. So now I will briefly go into detail about sites.

The game software and service will consist of a number of components including the server, rendering, physics, artificial intelligence and user interface.

A number of entities will need to be loaded and unloaded into memory in order for the software and service to work, but the challenge comes from the fact that one does not simply load all entities into memory... There are too many entities in the game to have loaded all at once.

To determine what entities are required for a given situation from the players stand point, or from the server's standpoint; and which components need to have the entities loaded, much thought has been put into organizing entities into sites.





The standpoint of the player is being used to determine what sounds, images and geometry belong near the player and other nearby players. This is to be performed as they all move through different parts of the worlds. The physics simulation is required to load collision data and interactive entities near the players, while the rendering process is required to load what the local player is likely to be able to see from their current position.

Not all regions of the solar system are to be generated, at least not with the resources available. Most parts of the solar system are impractical to travel to during the time setting of Sports Fiction, so the main focus is Earth and a number of scattered points around the planets nearest to earth. High levels of experience, gear and materials are required for distant travel.

So first the question is what information is required from a standpoint, then there are questions of how much information about such entities ought to be loaded into each component, or sent to each client given their role and level of access. These are the type of issues that have been put into planning and implementation of sites.
One type of entity which is being implemented into this site system are the terrains for planets.


Terrain sites
I have been working on a number of terrain maps which describe not only the height of the terrain on Earth, Venus, Mars and the moon, but also the temperature, weather, types of greenery, types of wildlife (if possible) and a variety of organic and inanimate matter which is to be spawned at certain points on the terrain. I will most likely be working on this aspect after posting this message tonight.




This heavily scaled down topological height field of planet earth I had prepared which is broken down into small images, each image of which are broken down further into smaller images which are shaded and prepared to be used as terrain height maps, weather maps and spawn points for plants, trees and animals.

In future updates I will discuss how all of the factors of terrain and weather affect the nature of the sports and intrinsic entities.



So now time to move onto the subject of SF party mode and competitive mode.






SF Party Mode
To provide comic relief, a little time to mess around with your friends, to enjoy special times with the family and to take a break from playing through episodes, campaign and competitive games, Sports Fiction party mode is being designed and developed.

The aim of the game in this mode is simply to enjoy yourself, chill out with friends or to make some new friends.



The core development of this mode is to take place after work on the main areas of the game because I will need the mechanics and completed schematics of the sports to be set in place in order to take them apart and turn them into fun party games. I will also need the concepts of lobbies and lounges put into place so that such parties can be accessed by public or private network players if desired.


Lobbies

The lobby system for party mode will be found in the user interface menu system. It will be available for offline and online sports fiction parties. You will be able to set up fun games and tournaments; or competitive play or campaign co-op or episode co-op groups if you wanted to engage into something a little more intense than a casual series of sports.

Lounges

Lounges are simply the in-game level version of the game lobby, a place in the game world where players can invite guests to play. These are entry points for players wanting to meet up, chat and enter into various aspects of the game such as the party game as well as PvE episodes, campaigns or competitive.

A number of lounges will be placed at certain locations in the solar system; probably one or two situated on Earth, and one on Mars. To reiterate, lounges are not the only place for meeting up; we will also have the lobbies in the user interface for a more private reception.

If using the lounge becomes too congested and you want to receive guests in the game world without having to resort to the use of lobbies, another way to receive guests is directly in the online game; whether at your HQ, or inside or nearby sports venues.

More information about party mode will be provided when it is in full development, along with other casual play modes such as PvP challenges.

Sports Fiction - 06/04/16 Competitive Modes

In the game, when you develop at least one of your game characters past a certain level, you will be able to engage in competitive play via the match making system I am developing.

You can solo queue or queue up with your own team. You will not require the single character to be used in the competitive matches, although you may choose to do so. If you do play in a competitive match with a levelled character, the character's abilities, items and level will be constrained temporarily for the competitive sport.

Quoted from my previous update,

At the time of writing, competitive play will involve one of two competitive modes; these are Universal Olympia, and Battle Champions.
I will be introducing these two competitive modes in this update with more details provided for Battle Champions since this is much further in development than Universal Olympia. I will continue to sharing my progress building these competitive modes moving forward.




I will now introduce some aspects of the Universal Olympia and Battle Champions modes, and the maps being developed for Battle Champions. The early release will have to occur before any secret aspects are revealled, but there is still a great deal that needs to be introduced to give you an idea of how these competitions will work, so you can get straight on with things when the competitions are activated.

Starting off with Universal Olympia, I will discuss the design for this competitive arrangement.






Universal Olympia
As the least constrained competition of the two competitions; Universal Olympia is being developed for allowing players with different talents and interested to join squads competing in a wide variety of traditional and fictional sports.

The competition will be broken down into monthly and quarterly leagues.



Universal Olympia is established by the in game Sports Federation for allowing athletes and sports professionals to unite and compete in modern sport around the globe and across certain regions of the solar system.

The key differences between the Universal Olympia competition and Battles Champions competition include the fact that all official sports can be played, rather than specific combat sports selected for Battle Champions (discussed further down this post).

• The UO competition separates the players into squads.
• Each squad is broken down into teams and solo players who compete for the squad in a number of sports selected by the team and squad managers.

The number of players required to compete in sports is a variable property of the squads.

On a match by match basis, the number of teammaters permitted are based on the structure of the sport.

Players volunteer to compete in the sports they wish to take part in. The more wins made by teams and solo players, the more points are awarded for the overall squad in competition against other squads; allowing the squad to compete in the monthly or quarterly competitions.

All of these specifications are in plain writing at this moment in time; during the early release period and after monitoring overall experience such variables may be changed to improve the game or find potential for improvements, to be later carved in stone.

A number of procedures for moderating the size and resources for each UO squad are being designed, but I welcome you to suggest any of your ideas now and during the early releases to make sure it progresses into a fair challenge for the best teams.

More about Universal Olympia and its range of sports will be discussed as they are being developed, so stay tuned if interested following its progress, participating or developing future teams.

I will now go into detail about the Battle Champions mode.







Battle Champions


The Battle-Champions competition is established by the in game Sports Federation as an advanced artificial warfare contest between two teams or a number of solo players in a Battle Royale. Each victory achieved will improve teams and player ranking.


The rules of each contest is determined by a further selected mode.

Given the game mode, being knocked out or getting tagging down from enemy fire eliminates or respawns the armoured players.

Injuries and death will not affect the character's progress in campaign or episode modes. In the worst case scenario, such instances of injury will reduce your characters abilities for the duration of the Battle Champions match. What is at stake is the player's rating, and the chances of victory; after the match all character states are reset.

Within Battle Champions there are a number of round based modes to choose from. At the time of writing, the following are the game modes that will be available in the final release.

(Please note that character roles and classes are not being revealed yet):
• BattleZones
o Zone, base or tower defense gameplay with two teams or solo player elimination. The players must obtain control of one or more zones to win each round of play. In team play, this round based game features two halves with teams swapping spawns.
• BattleBall
o Battle ball requires the players to get the ball into one of a number of goals or rings situated in the map, each offering their own score. There are no rounds in BattleBall, but it features two halves with the teams swapping spawns when initiated with team play.
• BattleRace
o Battle racing features armoured vehicles or ships used to race against opponents to the finish line. Each of the players are permitted to use whatever available means to win the race. Supportive vehicles, robots or ships may be used for assistance. There are no rounds or halves in Battle Races. Battle Royale solo play requires the last player to be eliminated from the race at certain checkpoints or laps if their vehicle or ship is still in one piece.
• BattleShips
o Battle-Ships is a contest of artificial warfare on spacecraft, watercraft or aircrafts. The players must tag down or commandeer the opponent ship/s in order to elimate enemy ships. In addition to Battle-Races, any permissable means can be used, with supportive ships and robots used to aid the team. There are no rounds in Battle-Ships, but in team play there are two halves with each team playing from each spawn area.
• BattleHunt
o Treasure hunt inspired game mode where the first to find and extract the treasure from the map wins the game. The treasure is typically a set of golden bars located at certain points in the map. The players and teams battle for access to these locations and must extract the treasure via a certain exit point or must remain standing with the opponents all eliminated from play.



So there are 5 Battle-Champions game modes planned; each team or player must reach some type of goal or must eliminate the enemies, and no information about character roles or classes are being revealed at this moment in time which will have as much significance as the challenges themselves.


At the time of writing, in team play, each team will consist of 7 players, and each of the players are to select one of the Battle Champions' team player roles.

Importing a character from PvE campaign and episode play is also an option where feasible.


In free-for-all Battle Royale, the Battle Champions 7v7 game mode rules still apply, however there are no teams, just single players attempting the same challenge with some minor map layout changes.

The aim of the Battle Royale game is to eliminate the opponents or meet the game map's challenge.

To conclude this update I will introduce the 12 maps which have been designed over the past two years and are in active development, with hopefully at least half made ready for the pre-alpha release.



Competitive Early Development Map Pool
Based on the mode of play each map will have a number of game modes which may reveal and conceal areas of the map to better suit the mode of play for 7v7 or Battle Royale solo elimination.

Most maps have been play tested with placeholder mechanics, AI and physics for about 50 - 200 hours gameplay on early release maps, and about 5 - 50 hours on the newer, less refined maps. Some maps have yet to be prototyped for a play test.


SF Competitive Map Creation Principle
The maps are designed to avoid obscuring vision, placing invisible walls, cluttering of the view and causing hindrance to the flow of movement throughout. They are to be kept with a consistent colour scheme to aid playing concentration and to make the maps look cool without losing competitive value.
Although the difficulty of maps vary, both teams or players are to share a similar if not identical balanced challenge. Players are to be encouraged to seek special vantage points or key position if skilled enough to claim the advantage.
Scientific method, play tests, stress tests and analysis play a significant part improving the design of the maps and the arrangement of the challenges. It is the best performing team or player that is to decide the winner the game, not the map.


Tombtown
Modes: Battle-Hunt, Battle-Race
Development Progress: 50%
Location: Giza, Egypt
Theme: Asymmetrical. Sand dunes, artificial ancient Egyptian architecture, relics and artefacts. Pyramids.
Style of play: Ramps and sandy hills. Breakable stone walls. A combat arena composed of stone, sand pits and artificial monuments is being used to host the treasure hunt. Sandy roads, desert plains and obstacle courses used in the battle race.

Tombtown features 7v7 or solo treasure hunt or racing battle sports. This map was brought to the pool quite late in comparison to earlier concepts, but has proven to be fun to play early on and is being developed efficiently due to the amount of experience gained from working on the earlier maps.

The hills and ramps in the map make for an interesting experience finding cover and shooting opponents. I am considering adding the ability to have projectiles affect the structure of the sand, but I am not yet sure if the feature is going to make it into the release given the potential for network overhead; it is a matter of coming up with solutions when tasks of higher priority have been completed.

I have constructed some ancient themed artificial buildings on desert plains which the players are able to enter into and engage in combat to gain access to the treasure. In battle race mode, such structures are mostly obstacles or part of the backdrop; however you will be able to use such buildings for planned or improvised strategic attacks for slowing down or taking out other racers.

There are paths and gateways leading into interiors which can be used to set up camp for repair armoured suits, robots and turrets. The treasure will spawn at different locations within one of these interior builds which make them a priority for your team.

The next development task for Tombtown is to make it look great. More on Tombtown in the next competitive map update.




Jackplot
Modes: Battle-Hunt, Battle-Zones
Development: 40%
Location: Las Vegas, USA
Theme: Action takes place in the Jack of All Spades, a casino turned combat sport arena. Traditional and futuristic casino games tables. A vault stashed with gold for treasure hunt mode.
Style of play: Quasi symmetrical. a battle for middle map control. Extraction of gold in hunt mode, or secure marked zones in zone mode. Projectile resistant glass makes for interesting encounters.

This map has undergone 2 reconstructions since its original design in December 2013, the most difficult one to get right so far. The challenge in designing this map comes from the placement of the vault for treasure hunt mode. After a great deal of tests and changes I have put together the layout and theme that I will push for release, hopefully an early release.

The map has symmetrical features but is not 100% identical on either side. Each team has a set of rounds starting from each side so a different strategy will be required to excel at winning both halves. The upper area of the arena is circular, which provides some interesting gameplay since the opponent could potentially flank from either direction from your standpoint in the circle.

The vault has been made accessible only through the middle of the map. All players and teams must access the treasure through the same route. With each team situated on the opposite sides, the key battle takes place in the middle preventing the other team from entering. An upper area has been constructed to allow the teams to flank the opponent spawn area. After obtaining the treasure, the treasure holders can exit via the lower vents, or back up the middle of the arena if the vents have been controlled by the opponents.

Projectile resistant glass has been used throughout the Jack of All Spades; at a number of points in the map you will see the enemy through glass, but will not be able to tag them down with bullets or lasers through this glass. The glass will be displayed with a distinguishable texture and impact animation to better indicate that you should not aim through it.

My next task is to work on the aesthetics for the map. The mechanics are for the most part ready for pre-release. In future map updates I will discuss some of the techniques being used.





Metropoligun
Modes: Battle-Ball, Battle- Zones
Development Progress: 40%
Location: London, England
Theme: Futuristic architecture. Old transportation networks and landmarks. Underground networks.
Style of play: Asymmetrical. Underground, ground and rooftop access. Vents, tunnels and old abandoned trains. Obstacle courses for battle-ball mode.

This is the first map developed which introducing the ball. Most of the details about battle-ball will come during the pre-release period.
The central structure used in this map is one of the earliest map creations, and one of the most fun to play. I was so interesting to compete in I decided to use its fundamental design again in one of the other maps now called Detachment.

Sports Federation have acquired a small abandoned London for use in Battle Champions TV. A number of derelicts, old subways and underground tunnels have been used as a battle ground for the players.
The asymmetrical layout of the map is complex and much like London city. The arena consists of streets, underground networks, abandoned trains and roof tops.

Each team will be given a set of rounds to start from each of the two spawn areas. Teams or solo players must either claim control of the scored zones or score with the ball, given the selected game mode, with the option of tagging down the hit-points of other players and robots. The battle-ball area of the map needs most of the work, with the battle-zone area requiring textures and models for completion.

This has been one of the most fun maps to play so far with the prototypes and alternative engine tests. Lots of vents, tunnels and interesting ways to flank the opponents.

I hope to get it ready for the early release but it is a complex task with lots of architectural structures and transportation entities in the backdrop; hopefully it will be ready sooner rather than later.





FreightRail
Modes: Battle-Hunt, Battle-Zones
Development: 35%
Location: New York, USA
Theme: Freight trains fabricated into a mobile arenas. Mix of classical and futuristic New York architecture and landmarks.
Style of play: Combat for zone control or for treasure extraction whilst staying onboard a moving train. Other obstacles must be dealt with along a straight route.

I was hesitant to attempt making this map, but after pushing myself and playing it, I am glad I took up this development challenge. It has great potential and offers hours of gameplay even in its early stage of development.

The Sports Federation have purchased old freight train services in a futuristic New York setting. They have set up an artificial warfare contest between two teams or in a Battle Royale solo elimination format.

In Battle-Hunt mode the players must extract hidden treasures which spawn in secret containers on the special train. In Battle-Zone mode, each contestant must claim control of certain carriages on the train.

Most of the construction work requires the construction of the buildings, roads, tunnels and landmarks used to set the scene in New York along the straight route. I will need to implement wind and vibration from the moving train to simulate such effects on projectiles and their impact on the game.

A mixture of old and new armoured containers have been used to fabricate the train. From carriage to carriage the players have to adjust their style of play to best survive in each presented situation.
The train has two decks of containers at certain points along the train, creating the potential to walk right underneath or above your opponents to secretly access key sections of the train.

Seeking higher vantage points early on is crucial for control of the train since the sniper rifles can tag down opponents along the outside of most of the train carriages. Certain projectiles can also penetrate through the surfaces of some of the older carriages. Only a certain class of robots can manoeuvre effectively in this mobile scenario, since there is not much ground to stand on.

The vast quantity of dynamic entities in the map could cause issues over a network unless optimized effectively; although most maps have their issues, and this is not the most complex construction task in the map pool; so most of the work ahead relates to simulating mobile combat effectively without reducing the competitive nature of the map.

I look forward to seeing how players deal with this challenge.





Tidalstorm Island
Modes: Battle-Ships, Battle-Hunt
Development: 35%
Location: Caribbean
Theme: Caribbean and pirate themed treasure island.
Style of play: Air and ocean combat for access to Tidalstorm Island in Battle-Ship mode with obstacles that must be dealt with on route. Treasure hunt takes place on the small quasi symmetrical island, with swamps, ocean waves, rope bridges and cliff edges.

Here we have the first map to introduce the Battle-Ships game mode. It also features a Battle-Hunt mode requiring the players to extract treasure from certain locations on the treasure island.

This is where things are going to get interesting because players must commandeer or take down aircraft and watercraft, a task that requires effective planning and execution. Each team or solo player have a selection of watercraft or aircraft to choose from.

Tidalstorm island has been designed from a symmetrical pentagon shape. The combat on foot is fun to play in the test engine. The placement of shacks and rope bridges adds tension and challenge. The challenge with building this island is its organize nature and the surrounding ocean.

The rope bridges will be kept static. I could not justify having animated rope bridges because it would lag the server and is not consistent with the dynamics of the other maps.

The map features a variety of terrain surfaces, a swamp and steep cliffs. I have placed some ropes at certain points in the map for climbing. The central area of the map features a ruins, where some of the treasure may spawn. I have been working on a number of displacement and sub surface functions for making the verticality of the terrain look impressive on DirectX 9.0; I will continue to enhance these functions as time progresses.

Having symmetrical features on the island, the two sides may access each spawn area in similar ways when engaging in treasure hunt combat directly; or they may choose to flank uphill or across a cliff edge.

In Battle-Ship mode the island may be used as a base for striking down passing ships, repair robots and performing other character roles.





Detachment
Modes: Battle-Ships, Battle-Ball
Development: 45%
Location: Satellite Arena, Planet Earth
Theme: Futuristic satellite space-arena. Abandoned space satellite docking stationed turned into a combat arena.
Style of play: Close encountered combat within the space station arena. Take control of turrets on the base station for attacks on ships. In ball mode, the players can detach areas of the satellite arena, removing contained players from access to the ball. Artificial gravitation varies the state of physics from section to section.

The Detachment concept is based on the Sports Federation's use of an abandoned space-station turned into an arena used for artificial warfare arena which orbits earth.

Players are able to detach parts of the space station into orbit in order to prevent access to goals and key areas of the base.
Most of the development so far has been focused on the central base. A great deal of the concept will require the development of advanced entities yet to be implemented.

From what I have experienced in test engines, the gameplay is really cool. It features close encounters because of narrow corridors and vents. The futuristic theme of the map is also nice to experience, even though not ready.

The futuristic space-arena by today's standards is somewhat science fiction; but in the setting of the game, the base is dated, no longer in use for docking much of earths satellites and space shuttles; recently acquired by the Sports Federation for artificial spacecraft and turret combat, with the docking facilities fabricated for battle ball.

Turrets will be made available for players to use to tag down opponent spacecraft. Taking control of the turrets in Battle-Ship mode will require entry into the station from your vessel and using your character to interacting with the turret. Robots and special character classes could then be used to turn the station into a temporary base for maintaining your team assets.

Artificial gravity is available in certain areas of the base station, but in some parts you will need to use propulsion to move around effectively.

The gravity needs to be taken into consideration when playing with the ball away from earth, much like the wind needs to be taken in consideration when playing with the ball on earth.







Apocalypse
Modes: Battle-Zones, Battle-Race
Development: 30%
Location: Namibia, Africa
Theme: Namibian ghost towns. Abandoned city themed arena surrounded by wastelands. A wall of fire separating the middle two halves of the zone map.
Style of play: The battle zone map is 100% symmetrical; both sides have an equal chance of vacating a number of demolished towers in a large tower defence zone control map. Battle-races take place around Namibian planes in surrounding abandoned towns and desert plains.

This epic large scale arena is has a symmetrical base used for the Battle-Zone mode. In 7v7s, teams start on opposite sides and must work towards controlling the central area of the arena.

The artificial abandoned city consists of demolished buildings, leaning towers, industrial derelicts and broken down diamond trains. The central area of the map is set on fire, so accessing the opposite side will require access through buildings on the sides or upgrading to make use of jet packs to fly over the wall of fire.

Because most of the map has demolished buildings and leaning towers, your character is able to access most areas of the map on foot. With such a large map it will be interesting to see how players make use of their radar and robots to track down the positions of the enemy.
What is fun about this map is its long range combat.

It offers hours of fun gameplay, allowing you to plan strategies and engage in combat to claim control of the surrounding towers. It will be quite interesting to see how it works in the real engine with better AI and realistic graphics.

Most of the development thus far has been on the Battle-Zone mode; no major work has been spent building the racing course. The artificial subway constructed at either spawn point may be used as part of the race course leading into surrounding desert.... who knows.

This is the largest contest map featuring land buildings thus far. The development of the Apocalypse map has been straight forward at least so far. It is one of the most recent concepts and is likely to be one of the early releases.

Apocalypse, along with the Labyrinth Castle and Oblivion, are epic sized maps making them the largest maps in the contest map pool so far.







Labyrinth Mountain Castle
Modes: Battle-Hunt, Battle-Ball
Development: 30%
Location: Netherlands
Theme: A castle arena constructed with gothic ornaments, visual puzzles and middle aged Dutch architectural themes placed on a snow mountain.
Style of play: The map features a castle with a number of visual puzzles, a maze garden and a labyrinth leading from one key area to another.

The Labyrinth Mountain Castle is a large map which contains a number of interesting puzzles, the main one containing visual challenges inspired by optical illusions pioneered by Roger Penrose and M.C. Escher, depending on your characters standpoint.

The gameplay for the main area of the map has been tested in placeholder engines, and make for a fun challenging game, and is quite spooky and nerve racking especially when you are the last player on your team.

There is a great deal work completed, with a great deal of work yet to be done due to the complex nature of this map.
Team work will be essential for navigating the tricky parts of the map while evading attacks from the enemy. Robots will be a useful tool for keeping the enemy on your radar who could just be around a corner.

At the front is an area for battle ball entry into the puzzle castle. Set in a cold climate, the level features icy floors and lakes which may affect the friction of movement in certain areas of the map. At the rear is a maze garden; being a maze it features more than one path and exit.

The labyrinth region of the map features a single path from one side to the other side of the labyrinth, with a number of interesting stairwells and access points throughout the interior.
The middle of the map contains a set of stairs leading to a an inner tower which provides a great advantage for the first team to control it.

The first goal is to obtain control of this central tower. Then the next step is to extract the treasure whilst keeping map control. In Battle Royale solo play, gaining control of the tower would be a luxury since the competition for access of this map region is great.

At the lower regions of the castle the players will find the treasure plus some interesting surprises.





Oblivion
Modes: Battle-Ball, Battle-Ships
Development: 25%
Location: Mars
Theme: Red hills, canyons, cliffs and peaks surrounding a cold dark cave network.
Style of play: Key areas of the map have been placed in a dark cave. Much of the game play will require the players to conceal themselves and the ball in darkness while keeping an eye on any moving object in the light which could potentially be an opponent. Rough terrain battle races on the surrounding surface.

Oblivion is a cave network discovered by Martian miners which has been acquired and fabricated into a Battle-Ball and Battle-Ship arena by the Sports Federation.

This map was recently started and is based on the concept of using light and dark areas of the cave to reveal or hide the ball or your spacecraft given the game mode. It can be quite tense especially when you can hear noises but are unable to see anything moving up until the point where one player takes a bad step and ends up in the light or falling off one of the steep cliff edges.
The gravitation on the planet is less than half the gravity on planet earth.

The progress of this map is at 20% because a basic layout has been built and I have managed to play test it for more than 5 hours, but it is still early in development with just a few cave textures here and there. The details of the map will have to be provided in a future update when the map structure matures.





Fractal Jungle Maze
Modes: Battle-Hunt, Battle-Zones
Development: 15%
Location: Yucatan, Mexico
Theme: Ancient Aztec themed architecture arranged in a circular arena situated within a fractal jungle themed maze.
Style of play: To be revealed.
The details for the Fractal Jungle Maze will be revealed in a future update.




Celsius
Modes: Battle-Race, Battle-Ships
Development: 15%
Location: Venus
Theme: Outer space high temperature regions surrounding planet Venus.
Style of play: Space racing and combat on board spacecraft around the Venus space base and on the volcanic surface of the solar system's warmest planet.
The details for Celsius will be revealed in a future update.



Rings
Modes: Battle-Ships, Battle-Race
Development: 10%
Location: Saturns Rings
Theme: Caribbean and pirate themed islands.
Style of play: Air and ocean combat for access to the treasure island. and battles for treasure extraction on a quasi symmetrical island. Other obstacles must be dealt with along the route.
The details for Rings will be revealed in a future update.


Conclusion
Now that the competitive map themes are out in the open, future updates can go straight into entity level detail without having to make an introduction of the maps.

The maps for the other game modes are either tied to the terrain or area of gamespace assigned to the campaigns, or will be fabricated for specific sports or generated for party or olympia modes.

The next step is to refine the earth topology functions; keep the thread tracked.

My God Chris. Just writing this last post was a feat in itself... The game worlds sound very cool. Are you doing all the level design yourself? You mentioned modding. Does this mean people can create their own player avatars? I assume they would have skeleton animation and be in the .x format. The lobbies sound like a good feature and i like how you would keep people of different skill levels separated. I don't play MMO games because i find most people online to be jerks, but i would love to give this one a try. Can't wait til you go alpha/beta. Keep on keeping us updated.

Really man, how long does it take, to make such a detailed log? Once again it is an interesting update! Do you have an aproximate date for the test version?

@Seppgirty ; I like MMOs too, and will be keeping a close eye on the jerks who try to spoil the fun in my game. The approval rating system is something I will discuss in future which makes it easier for you to find ideal team mates, and helps my bot to shortlist cheaters and griefers.

90% of the modelling is mine. I have built some of the game levels manually, the others I am generating with code. More screenshots will be provided over the course of the year as the levels are prepared. Videos will come at the moment of early release; unless I bother to make an early release trailer. There are a lot of spoilers that need to be kept under control.

Indeed I do want you to be able to edit the look of your avatars and characters in general, from clothing to facial expressions. The challenge is DBPs bone optimization being quite poor. In the worst case scenario I'd have to generate Direct X files for each unique player character. Idealy I will be able to apply vertexdata operations on a single animated mesh. The character mesh takes 10-20 seconds to load, and I need to a male and female version. Plus I need to load other animated entities, so there is not much freedom when it comes to bone animated entities. I hope this goes well because I have designed futuristic costumes and fashion items for the players to select, and I want them to look cool.

Keeping the skill levels seperated (or temporarily balanced) will be handled by the games scoring system, competitive modes and approval rating of the players. It is a touchy subject because some buddies want to play with each other even though they have different levels of experience.

Early on with just a small number of players the team games are not going to hold much weight; so the olympia mode allows players to enjoy the multiplayer game without having to play direcetly with each other; the single player will feature challenges and some AI to keep things interesting while the player population grows. Managerial aspects of the game will also be cool, making your own team etc.

@Dimis, it takes about 1-2 days on average for each update. That last day I posted included two updates and so took 3 days. I also consider parts of these updates to become a potential part of the official documentation, so I am kind of performing a two in one task. This is quite the same for everything I do; 'how could I knock two birds down with one stone'

The test version will come out when I can say to myself; 'I really should stop playing this now and get on with some work, man I finding it hard to figure out what visuals is worth fixing; I don't care what big company copies this now since I've got other eggs for the basket'

I will likely release an early release to a chosen number of people, then a beta for the public. Then a full release. There may be an alpha which comes between the early release and the beta which is likely to not feature any campaigns or storyline; if I feel the need for it.