# Blogs

## Featured Entries

• ### Game Design Document, Scoping, Prototyping

By Stefan Hendriks

• 1075 views

By Promit

• 985 views
• ### Node Graphs and the Terrain Editor

By JTippetts

I've been working on the node graph editor for noise functions in the context of the Urho3D-based Terrain Editor I have been working on. It's a thing that I work on every so often, when I'm not working on Goblinson Crusoe or when I don't have a whole lot of other things going on. Lately, it's been mostly UI stuff plus the node graph stuff. The thing is getting pretty useful, although it is still FAR from polished, and a lot of stuff is still just broken. Today, I worked on code to allow me to build and maintain a node graph library. The editor has a tool, as mentioned in the previous entry, to allow me to use a visual node graph system to edit and construct chains/trees/graphs of noise functions. These functions can be pretty complex: I'm working on code to allow me to save these graphs as they are, and also to save them as Library Nodes. Saving a graph as a Library Node works slightly differently than just saving the node chain. Saving it as a Library Node allows you to import the entire thing as a single 'black box' node. In the above graph, I have a fairly complex setup with a cellular function distorted by a couple of billow fractals. In the upper left corner are some constant and seed nodes, explicitly declared. Each node has a number of inputs that can receive a connection. If there is no connection, when the graph is traversed to build the function, those inputs are 'hardwired' to the constant value they are set to. But if you wire up an explicit seed or constant node to an input, then when the graph is saved as a Library Node, those explicit constants/seeds will be converted to the input parameters for a custom node representing the function. For example, the custom node for the above graph looks like this: Any parameter to which a constant node was attached is now tweakable, while the rest of the graph node is an internal structure that the user can not edit. By linking the desired inputs with a constant or seed node, they become the customizable inputs of a new node type. (A note on the difference between Constant and Seed. They are basically the same thing: a number. Any input can receive either a constant or a seed or any chain of constants, seeds, and functions. However, there are special function types such as Seeder and Fractal which can iterate a function graph and modify the value of any seed functions. This is used, for example, to re-seed the various octaves of a fractal with different seeds to use different noise patterns. Seeder lets you re-use a node or node chain with different seeds for each use. Only nodes that are marked as Seed will be altered.) With the node graph library functionality, it will be possible to construct a node graph and save it for later, useful for certain commonly-used patterns that are time-consuming to set up, which pretty much describes any node graph using domain turbulence. With that node chain in hand, it is easy enough to output the function to the heightmap: Then you can quickly apply the erosion filter to it: Follow that up with a quick Cliffify filter to set cliffs: And finish it off with a cavity map filter to place sediment in the cavities: The editor now lets you zoom the camera all the way in with the scroll wheel, then when on the ground you can use WASD to rove around the map seeing what it looks like from the ground. Still lots to do on this, such as, you know, actually saving the node graph to file. but already it's pretty fun to play with.
• 1288 views

By ApochPiQ

• 1 comment
• 6548 views

By kostile

• 973 views

## Our community blogs

• 3
entries
• 1
comment
• 149
views

#### Recent Entries

Latest Entry

galaxa.neocities.org/games/40.html

• 55
entries
• 86
• 38762
views

Latest Entry

## Companion

### ANDREJ KREBS

I started making the player’s companion based on Mito’s design sketches. This will be a small floating robot, that will follow the player around and be available to him. The companion will mostly stay out of the way, but the player will be able to call it to help him with certain tasks.

### Usefulness of a companion

• They will be projecting the inventory, crafting and character UI. This will be a mostly aesthetic task that should add some more immersion.
• Companion will have a limited healing capability. It will be able to heal the player, but its healing capacity will deplete quickly and will take time to recharge.
• It will work as a limited gathering tool. The companion will be able to shoot a mining laser, that will break trees, rocks and mining veins, but it will quickly run out of power and need to recharge. This will give the player the ability to gather resources, even if he finds himself without any gathering tools, but also give him incentive to craft them, because they are much quicker at the task.
• Technically, the companion will be regarded as a tool that will always be available. It is animated in a similar way as the weapons, meaning it has animated interactions with the player character’s first person rig.

## More User Interface Changes

### Player Stats

In the lower right corner you will find various player variables: health points, energy points, companion energy points and jet pack fuel. The panel is intuitive – the most important player stats have colors. If a certain stat is being low, the icon starts flashing (there will be also danger SFX for it later). If you gain certain stat (e.g. you are getting healed or damaged), the text color is changed as well to notify you something is happening to you. More details about a certain player stat:

Player stats
• Health points: this is something you will have to watch out for a lot, like in other games. You will be able to replentish your health in various ways, from consumable items, companion healing and world “healing stations”.
• Energy points: this is the secondary stat to monitor. It depletes when doing certain tasks: mining, jumping/running endlessly, diving in waters, staying in radioactive zones, to name a few. To replentish the energy, you will be able to craft yourself energy batteries or build yourself (or finding one in the world) a charging station.
• Companion energy: as mentioned before, you will be able to use your companion to heal yourself or as low-level resource gathering tool (until you craft yourself a pickaxe or another more advanced tool). Companion energy will deplete and replentish fast and its resource gathering/healing capabilities are basic.
• Jet fuel: it will be used to reach previous unaccessable areas with fast depletion and slow replentish rate. There will be no way to replentish it with consumable items.

### Item Bonuses

Since we have player stats now defined and ready to use, there should be an option of improving or degrading them. For this purpose, I’ve implemented item bonus system that’s going to be enabled if you put items in your hotbar or gear slot (gear items won’t work in your hotbar though). A sample item with bonuses:

Item bonuses

Crafting menu has been overhauled to be more intiutive. The design is not yet finished as it requires SDF icons and other minor tweaks. Items are sorted in different categories, from weapons, tools to electornic devices. You can easily see what items are still missing to craft a certain item or if it requires a workbench to craft it (applies for bigger, more advanced items).

### Crafting Queue

You can add up to 5 items to your crafting queue where items are being crafted for you. You can cancel certain recipe from being crafted and regain all items needed for this recipe back to your inventory.

Crafting queue

## Resource helper

I’ve been creating an in house resource helper, that will reduce time costs of searching and manually changing files containing item definitions and resource definitions. What you see is an XAML app, that parses .json file and gets out values of each item. These values can be manipulated easily through WIP UI interface and later simply replaced by just one click of the button. Soon I’ll be moving to crafting variables, and its manipulation.

Resource & Crafting Helper

As you can see, this is a necessary chore, which allowes even non-coders in the team to easily fix over or under saturated values of variables. This will become specially useful in the testing phase, so we’ll be able to change things on the fly.

Later on, I’m going to implement server connection, which will broader the options what we can do with it. Nothing is sure for now, but a bit deprecated version could be used even for players. That way they know which items/crafting receipts are used in the game, or even for modding support. But as I said before, this is just a thought, we will let time decide other proper use cases for it.

## Updating UI icons

### MITO HORVAT

Since Domen is extensively reworking the entire UI and the whole inventory system, we’ll have to update the icons as well. The current icon style won’t fit the UI design that is currently being created. So this week was kind of frustrating, simply because its not the simplest task to find the exact type of icon style to fit the UI. After plenty of rejections and reworks this is what I came up with. Some of them will probably get replaced in the near future.

## Terrain

### VILI VOLČINI

Due to creating a new Floatlands world lately, I had to rework terrain as well.

Optimizations:

• Multithreading of all operations on 2D maps, which includes Perlin noise generation, filtering, map rotation, addition.
• Pool for 1D and 2D arrays, also with thread-safe functions.
• Direct mesh contruction (previously mesh was constructed then modified).
• Caching where possible to avoid Garbage Collection.

• Signed Distance Field for each Biome, so I can know how far away from biome edge I am (inside & outside).
• Picking quad diagonal based on surface curvature, so that mesh looks more natural.

To demonstrate how it’s done on 2D arrays. Lets say you have a quadcore PC, then we split any workload to 4 parts, so each thread gets it’s own part to work on.

A code example of how it’s done in our project.

 1 2 3 4 5 6 7 8 9 10 11 12 /// N is resolution map /// x is index MapUtils.ForPararell(N, (x) => {       // this closure inside is now running on it's own thread       for (int y = 0; y < N; y++) {           // do operations on 2D arrays as you'd normally do,         // don't share state between threads though, or bad things will happen     } });

This is the current state of terrain, with still some tweaking to go:

• 2
entries
• 0
• 195
views

#### Recent Entries

Latest Entry

Free mobile Zombie Road kill Action Racing game 'Dead Run : Road of Zombie' is updated to new version 1.0.6

Enjoy more fun playing with Cinematic camera and mission.

**************** v1.0.5 Update****************

Cinematic camera moving

Play time extension

Display combo Kill numbers.

• 8
entries
• 0
• 1151
views

#### Recent Entries

Latest Entry

Currently on alpha test, silverpath online has active event currently that spawns bosses on event room.

You can join free and feedback bugs, glitches or whatever problem you have encountered.

Currently friends and community system is on progress you feedbacks are important to me, also alpha users will get prizes on beta regarding their alpha-end rankings.

• 2
entries
• 2
• 177
views

#### Recent Entries

Latest Entry

Time for an update.

So what have I been working on in the last couple of weeks?  Firstly the lighting and particle systems are activated.  The particle system is pretty unintrusive with the most notable aspect being the chimney smoke rising from the different steampunk engines.  Alongside this there is now a bit of splashing water and a few sparks flying around.  Much more noticeable is the lighting system as demonstrated in the new screenshots.  Here there is now a day / night cycle - I spent quite a long time making sure that the night was not too dark and I already have a game setting allowing this to be turned off (while this will lose a lot of the atmosphere just having day light slightly improves performance ... no other lights need to be active ... and maximises visibility).  Introducing other lights was a bit more problematic than expected.  Firstly, it took a while to get the light fall off fine-tuned correctly and secondly I upgraded the code quite a bit.  Originally, the light manager would always choose the lights nearest to the player, meaning that a maximum of 7 lights (beyond the sunlight) could be active in any scene.  Okay, but it did mean that more distant lights would suddenly flick on.  The new logic activates lights nearest to each game object or map tile currently being drawn, allowing a much greater number of lights to be shown in any scene.  In general the list of lights to activate are pre-calculated as each map section is loaded, with only lighting for moving objects being calculated on the fly.  So far seems to be working nicely - if I overloaded a particular area with lights there could still be light pop-up, but with sensible level design this can be avoided.  I did consider pre-baking the lighting but with the day/night cycle and the desire to alter light intensity and even colour on the fly this was going to be too complex and the performance of the current solution seems to be very good.

The other task I've been working on is the introduction of two new map zones.  The objective was to introduce something distinct from what had been done so far and to this end I have been working on a wilderness and an industrial zone.  And the wilderness zone completely failed to work.  It's a beginner zone so there wasn't any intention to overload it with complex gameplay, but even so it's just empty and uninteresting - back to the drawing board on that one.  As for the industrial zone this one is going better.  There are a number of new models being used and a few more to add with a couple of objectives in mind.  First off the aim is to create a little bit the confusion of a steampunk factory - pipes, big machines, smoke and steam.  Secondly, to hint at the down side of (steampunk) industrialisation with the texturing more grimy and even the addition of waste stacks (handily blocking off the player's progression requiring them to navigate their way round more carefully).  An early draft is shown in the screenshot below - the ground texturing needs to be changed with green grass needing to be replaced by rock and sand and I will also be working on the lighting and fog - to draw in the view and create a darker scene even in the middle of the day.  The scene may be a bit too busy at the moment, but I will see how I feel once these changes are made.

Hope the update was interesting - as before any feedback most welcome.

• 4
entries
• 3
• 231
views

#### Recent Entries

Latest Entry

Unreal Engine 4 is an awesome game engine and the Editor is just as good. There are a lot of built in tools for a game (especially shooters) and some excellent tutorials out there for it. So, here is one more. Today the topic to discuss is different methods to program player world interaction in Unreal Engine 4 in C++. While the context is specific to UE4, it can also easily translate to any game with a similar architecture.

# Interaction via Overlaps

By and far, the most common tutorials for player-world interaction is to use Trigger Volumes or Trigger Actors. This makes sense, it is a decoupled way to set up interaction and leverages most of the work using classes already provided by the engine. Here is a simple example where the overlap code is used to interact with the player:

// Fill out your copyright notice in the Description page of Project Settings.

#pragma once

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "InteractiveActor.generated.h"

UCLASS()
class GAME_API InteractiveActor : public AActor
{
GENERATED_BODY()

public:
// Sets default values for this actor's properties
InteractiveActor();

virtual void BeginPlay() override;

protected:
UFUNCTION()
virtual void OnInteractionTriggerBeginOverlap(UPrimitiveComponent* OverlappedComp, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult);

UFUNCTION()
virtual void OnInteractionTriggerEndOverlap(UPrimitiveComponent* OverlappedComp, class AActor* OtherActor, class UPrimitiveComponent* OtherComp, int32 OtherBodyIndex);

UFUNCTION()

class UBoxComponent* InteractionTrigger;
}


This is a small header file for a simple base Actor class that can handle overlap events and a single input action. From here, one can start building up the various entities within a game that will respond to player input. For this to work, the player pawn or character will have to overlap with the InteractionTrigger component. This will then put the InteractiveActor into the input stack for that specific player. The player will then trigger the input action (via a keyboard key press for example), and then the code in OnPlayerInputActionReceived will execute. Here is a layout of the executing code.

## Source

// Fill out your copyright notice in the Description page of Project Settings.

#include "InteractiveActor.h"
#include "Components/BoxComponent.h"

// Sets default values
AInteractiveActor::AInteractiveActor()
{
PrimaryActorTick.bCanEverTick = true;

RootComponent = CreateDefaultSubobject<USceneComponent>(TEXT("Root"));
RootComponent->SetMobility(EComponentMobility::Static);

InteractionTrigger = CreateDefaultSubobject<UBoxComponent>(TEXT("Interaction Trigger"));
InteractionTrigger->InitBoxExtent(FVector(128, 128, 128));
InteractionTrigger->SetMobility(EComponentMobility::Static);

InteractionTrigger->SetupAttachment(RootComponent);
}

void AInteractiveActor::BeginPlay()
{
if(InputComponent == nullptr)
{
InputComponent = ConstructObject<UInputComponent>(UInputComponent::StaticClass(), this, "Input Component");
InputComponent->bBlockInput = bBlockInput;
}

}

{
//this is where logic for the actor when it receives input will be execute. You could add something as simple as a log message to test it out.
}

void AInteractiveActor::OnInteractionProxyBeginOverlap(UPrimitiveComponent* OverlappedComp, AActor* OtherActor, UPrimitiveComponent* OtherComp, int32 OtherBodyIndex, bool bFromSweep, const FHitResult& SweepResult)
{
if (OtherActor)
{
AController* Controller = OtherActor->GetController();
if(Controller)
{
APlayerController* PC = Cast<APlayerController>(Controller);
if(PC)
{
EnableInput(PC);
}
}
}
}

void AInteractiveActor::OnInteractionProxyEndOverlap(UPrimitiveComponent* OverlappedComp, class AActor* OtherActor, class UPrimitiveComponent* OtherComp, int32 OtherBodyIndex)
{
if (OtherActor)
{
AController* Controller = OtherActor->GetController();
if(Controller)
{
APlayerController* PC = Cast<APlayerController>(Controller);
if(PC)
{
DisableInput(PC);
}
}
}
}


## Pros and Cons

The positives of the collision volume approach is the ease at which the code is implemented and the strong decoupling from the rest of the game logic. The negatives to this approach is that interaction becomes broad when considering the game space as well as the introduction to a new interactive volume for each interactive within the scene.

# Interaction via Raytrace

Another popular method is to use the look at viewpoint of the player to ray trace for any interactive world items for the player to interact with. This method usually relies on inheritance for handling player interaction within the interactive object class. This method eliminates the need for another collision volume for item usage and allows for more precise interaction targeting.

## Source

### AInteractiveActor.h

// Fill out your copyright notice in the Description page of Project Settings.

#pragma once

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "InteractiveActor.generated.h"

UCLASS()
class GAME_API AInteractiveActor : public AActor
{
GENERATED_BODY()

public:
}


### AMyPlayerController.h

// Fill out your copyright notice in the Description page of Project Settings.

#pragma once

#include "CoreMinimal.h"
#include "GameFramework/PlayerController.h"
#include "AMyPlayerController.generated.h"

UCLASS()
class GAME_API AMyPlayerController : public APlayerController
{
GENERATED_BODY()

AMyPlayerController();

public:
virtual void SetupInputComponent() override;

float MaxRayTraceDistance;

private:
AInteractiveActor* GetInteractiveByCast();

void OnCastInput();
}


These header files define the functions minimally needed to setup raycast interaction. Also note that there are two files here as two classes would need modification to support input. This is more work that the first method shown that uses trigger volumes. However, all input binding is now constrained to the single ACharacter class or - if you designed it differently - the APlayerController class. Here, the latter was used.

The logic flow is straight forward. A player can point the center of the screen towards an object (Ideally a HUD crosshair aids in the coordination) and press the desired input button bound to Interact. From here, the function OnCastInput() is executed. It will invoke GetInteractiveByCast() returning either the first camera ray cast collision or nullptr if there are no collisions. Finally, the AInteractiveActor::OnReceiveInteraction(APlayerController*)  function is invoked. That final function is where inherited classes will implement interaction specific code.

The simple execution of the code is as follows in the class definitions.

### AInteractiveActor.cpp

void AInteractiveActor::OnReceiveInteraction(APlayerController* PC)
{
//nothing in the base class (unless there is logic ALL interactive actors will execute, such as cosmetics (i.e. sounds, particle effects, etc.))
}


### AMyPlayerController.cpp

AMyPlayerController::AMyPlayerController()
{
MaxRayTraceDistance = 1000.0f;
}

AMyPlayerController::SetupInputComponent()
{
Super::SetupInputComponent();
InputComponent->BindAction("Interact", EInputEvent::IE_Pressed, this, &AInteractiveActor::OnCastInput);
}

void AMyPlayerController::OnCastInput()
{
AInteractiveActor* Interactive = GetInteractiveByCast();
if(Interactive != nullptr)
{
}
else
{
return;
}
}

AInteractiveActor* AMyPlayerController::GetInteractiveByCast()
{
FVector CameraLocation;
FRotator CameraRotation;

GetPlayerViewPoint(CameraLocation, CameraRotation);
FVector TraceEnd = CameraLocation + (CameraRotation.Vector() * MaxRayTraceDistance);

FCollisionQueryParams TraceParams(TEXT("RayTrace"), true, GetPawn());
TraceParams.bTraceAsyncScene = true;

FHitResult Hit(ForceInit);
GetWorld()->LineTraceSingleByChannel(Hit, CameraLocation, TraceEnd, ECC_Visibility, TraceParams);

AActor* HitActor = Hit.GetActor();
if(HitActor != nullptr)
{
return Cast<AInteractiveActor>(HitActor);
}
else
{
return nullptr;
}
}


## Pros and Cons

One pro for this method is the control of input stays in the player controller and implementation of input actions is still owned by the Actor that receives the input. Some cons are that the interaction can be fired as many times as a player clicks and does not repeatedly detect interactive state without a refactor using a Tick function override.

# Conclusion

There are many methods to player-world interaction within a game world. In regards to creating Actors within Unreal Engine 4 that allow for player interaction, two of these potential methods are collision volume overlaps and ray tracing from the player controller. There are several other methods discussed out there that could also be used. Hopefully, the two implementations presented help you decide on how to go about player-world interaction within your game. Cheers!

• 4
entries
• 4
• 300
views

#### Recent Entries

Latest Entry

Hi there,

this week I was working on following stuff.

# Scaling issues

I was struggling with the scaling issues. As you might have seen, the "pixels" displayed on the screen did not always had the same size. Now, this issue is fixed and it looks way better. Check it out:

# Mouse dragging

Because of the scaling issue, now not all the tiles are visible on one image. In order to navigate through the map, you can now use the mouse and drag the camera around. You're going to use this feature in greater maps in order to navigate your characters and get an overview.

# Title screen

Finally, I implemented a title screen. From here, you can navigate to a new game, your settings and exit the game. It is currently under development, so it might change a bit. The background image should stay the same.

That's it for this update. Be sure to follow this blog in order to stay up2date. :3

As always, if you have questions or any kind of feedback feel free to post a comment or contact me directly.

Additionally, if you want to know where I get my ideas regarding pixel arts from, you can check out my Pinterest board.

• 3
entries
• 5
• 424
views

#### Recent Entries

Latest Entry

Hello everyone!

Oh, I'm so delighted with the number of views! And gamedev.net even featured our entry on their Facebook page! Thank you for finding this blog interesting!

In the last entry, I made a brief introduction of our Egypt: Old Kingdom game. It's not just based on history, we're basically trying to recreate the history in a game form. Of course, it requires a tremendous amount of research!

Sometimes people ask us: "Why did you choose Hierakonpolis/Memphis as the main location, and not Thinis or some other important settlements?"

The reply will be: because in order to make the game really historical, our location of choice has to be very well researched. We need a lot of information about the location: events, personalities, buildings, lifestyle.

The research was done by the game designer, Mikhail, and I think he can now get his master degree as an Egyptologist because he knows A LOT about Ancient Egypt thanks to his research!  He did the research by himself for Bronze Age and Marble Age, but then it got too hard to keep up with both research and game design. For the next game, Predynastic Kingdom, we contacted the scientists from the Center For Egyptian Study of Russian Academy of Sciences (CES RAS). We're lucky they agreed to help! Predynastic Egypt was the first game made with their support.

For Egypt Old Kingdom Mikhail created a huge database containing most of the known events, places and personalities of the Old Kingdom period:

Every little thing about the period is studied thoroughly in order to immerse the player deeper in the game. We learn about kings’ deeds, their authority, did they properly worship gods or not, did they start any wars or not. We study climate, soil, vegetation, natural disasters of that period. We learn about the appearance of ancient Egyptians, their dress, their food, their houses.

Sketches of Egyptians' appearance:

When the database is ready, Mikhail goes over it with the scientists. They check everything, correct what's necessary, provide more information and details. Like every other science,  history has a lot of controversial points. For example, "The White Walls" of Memphis is something that scientists can't agree about. There are two major opinions about what could it be:

1. It is the walls of a palace.

2. It is the walls of burial grounds.

In our game, we don't want to take sides, so the scientists of CES RAS inform us about such "dangerous" topics as well. This way we can avoid the controversy and let the player decide which theory he prefers.

This is Mikhail (left side) discussing the game events with scientists  In the middle - Galina Belova, one of the most famous Russian Egyptologists. The director of CES RAS to the right.

During this part of the work we sort out all of the events and divide them in groups: the most important events which must be in the game;  less important events which can be beneficial for the atmosphere of the game; insignificant events.

When this part of work is done, and all of the information is sorted out, the design of the game begins. In the process we still keep in touch with the scientists, because some events are not easy to turn in a game at all.

For example, one of our goals is to make the player fully experience the life of Ancient Egypt. We want to make player think like Ancient Egyptians, to make him exparience the same difficulties. In order to do that we have to know what Egyptians were thinking, and also through the gaming process, we have to put the player in the same conditions as Egyptians had.

Ancient Egyptians strongly believed that if they would not worship their ancestors and gods properly, the country will experience all kinds of disasters. This belief was unconscious and unconditional, that’s why they were building all those funeral complexes, made sacrifices, trying to please their ancestors. Even cities were built only as a way to please gods and ancestors! They were sure if they will stop properly worship them, the country will be doomed, because ancestors will stop to protect them.

We wanted to nudge the player to build all these pyramids for the same reasons as Egyptians, and this is how stat “Divine favor” appeared. This stat is mostly necessary to worship the gods’ cults, and player can earn it by working in temples and worshipping ancestors. But what really makes the player to feel like Egyptians did is the feature of “Divine favor” stat – it degrades by 0,1 every turn. It happens because people are dying; hence, there are more and more ancestors that must be worshipped. If player will not pay attention to this stat and it will degrade too much, more and more disasters will start to happen, such as fires, earthquakes, droughts, etc. If will greatly influence the economy and the result of the game.

That's how we turn history in a game. It can be fun and challenging! There are many other examples of similar transitions. We'll definitely keep working with the scientists, not only Russian, but also foreign. In fact, we hope to engage more and more people in the process of game making.

That's it for now. Thank you for reading! Comments are very welcome!

If you would like to know more about the game and follow our social media, here are links:

• 27
entries
• 53
• 17641
views

#### Recent Entries

Latest Entry

Three weeks have passed, a few new people have installed the game. I had the chance to deploy the game also to juniors x86 tablet, where it currently crashes. The tablet does have a gyro sensor, which I thought worked fine when using it on Windows Phone, but apparently the code isn't crash proof enough.

I've been looking mostly for crashes now, and a handful (well, two in the last 3 days) did appear. The crash info is all over the place. Some have a really great stack trace, other nothing. Some seem to be in between. I reckon this is heavily affected by fiddling with telemetry settings.

What I'm also missing on a first glance is the configuration of the crashed app. Since the compile builds executables for x86, x64 and ARM it'd be nice to know which of these were the cause. What's always there is the name, IP, Windows build version and device type of the device that was running the game.

While the stack traces sometimes help they are only that. You don't get a full dump or local watch info. So you can get lucky and the location of the problem is clear, or you're out of luck. In these last two crashes the stack traces hints on a null pointer on a method that is used throughout the game (GUI displaying a texture section). I suspect that it happens during startup and the code path went inside a function when it wasn't ready. In these cases I can only add a safety check and cleanly jump out of the function. Build, upload, re-certify and next try in 1 to 3 days.

Currently I'm struggling getting remote debugging done on the tablet. I can deploy the app via enabled web portal, but the remote debugger is not properly recognized by Visual Studio. I was hoping for USB debugging as that works nicely on the phone, but had no luck with it.

Well, here's to the next version hoping to get those crashes fixed!

• 1
entry
• 1
comment
• 64
views

#### Recent Entries

Latest Entry

Here goes my game.

This challenge is sooooo convenient to me for I have no ability of drawing... :(

By finishing it I learned lots of Cocos Creator, which is good at UI effects.

Thanks a lot for the Challenge!

Source code:

Screenshot:

Spoiler

title

gameplay

• 2
entries
• 0
• 113
views

#### Recent Entries

Latest Entry

For QLMesh (and some other projects), I am running my own fork of Asset Import Library.  The difference: it is amalgamated build - all sources are merged into one file (including dependencies). Since Assimp recently switched to miniz, I have replaced remaining references to zlib with miniz - so zlib is not required too.

drwxr-xr-x  85 piecuchp  staff     2890 Jan 17 23:34 assimp
-rw-r--r--   1 piecuchp  staff  4921627 Jan 17 23:34 assimp.cpp
-rw-r--r--   1 piecuchp  staff  2893785 Jan 17 23:34 private\assimp.h

Everything you need to buid the assimp is:

g++ -c -std=c++11 code-portable/assimp.cpp


or just add assimp.cpp to your project/IDE (you can find code-portable directory in my repo.

One disclaimer: I have only tested this amalgamation under OSX with QLMesh). Main reason for this amalgamation is that it makes compilation/recompilation on different platforms with different configurations rather easier.

Side-effect is that single-file assimp.cpp compiles really fast (like 10x faster on my MacBook than original project files).

• 1
entry
• 7
• 73
views

#### Recent Entries

Latest Entry

I have released my first free prototype!

How terrifying!

It is strange that I have been working to the moment of releasing something to the public for all of my adult life, and now I have I find it pretty scary.

I have been a developer now for over 20 years and in that time I have released a grand total of 0 products.

The Engine

The engine is designed to be flexible with its components, but so far it uses

Opengl, OpenAL, Python (scripting), CG, everything else is built in

The Games

When I started developing a game I had a pretty grand vision, a 3D exploration game. It was called Cavian, image attached. and yep it was far to complex for my first release. Maybe I will go back to it one day.

I took a year off after that, I had to sell most of my stuff anyway as not releasing games isn't great for your financial situation.

THE RELEASE

When I came back I was determined to actually release something! I lowered my sights to a car game, it is basically finished but unfortunately my laptop is too old to handle the deferred lighting (Thinkpad x220 intel graphics)  so I can't test it really, going to wait until I can afford a better computer before releasing it.

Still determined to release something I decided to focus more on the gameplay than graphics.

# Is This A Game?

Now I have created an Experimental prototype. Its released and everything: https://yesindiedee.itch.io/is-this-a-game

So far I don't know if it even runs on another computer. Any feedback would be greatly appreciated!

If you have any questions about any process in the creation of this game design - coding - scripting - graphics - deployment just ask, I will try to make a post on it.

Have a nice day, I have been lurking on here for ages but never really said anything.....

# I like my cave

• 2
entries
• 0
• 146
views

#### Recent Entries

Latest Entry

Last week we made a draft design document to visualize the global structure of the game.

Because the levels are linear with a lot of verticality and the camera free, we are trying to find a good solution for the boundaries. Of course it will be heavily filled with environments deco but we want don't want to spend a lot of time making sure there are no holes! And we don't want invisible walls which are not obvious. So I tried with a depth-faded (using depth fade for the intersection between the wall and the other objects, and a camera depth fade) magic wall like this:

Now the chantilly path automatically conform to the ground:

As much as possible we try to save time by creating tools like this:

• 20
entries
• 58
• 36674
views

#### Recent Entries

Latest Entry

This will be a short technical one for anyone else facing the same problem. I can't pretend to have a clue what I was doing here, only the procedure I followed in the hope it will help others, I found little information online on this subject.

I am writing an Android game and want to put in gamepad support, for analogue controllers. This had proved incredibly difficult, because the Android Studio emulator has no built in support for trying out gamepad functionality. So I had bought a Tronsmart Mars G02 wireless gamepad (comes with a usb wireless dongle). It also supports bluetooth.

The problem I faced was that the gamepad worked fine on my Android tv box device, but wasn't working under Linux Mint, let alone in the emulator, and wasn't working via bluetooth on my tablet and phone. I needed it working in the emulator ideally to be able to debug (as the Android tv box was too far).

Here is how I solved it, for anyone else facing the same problem. Firstly the problem of getting the gamepad working and seen under linux, and then the separate problem of getting it seen under the Android emulator (this may work under Windows too).

## Under Linux

Unfortunately I couldn't get the bluetooth working as I didn't have up to date bluetooth, and none of my devices were seeing the gamepad. I plugged in the usb wireless dongle but no joy.

It turns out the way to find out what is going on with usb devices is to use the command:

lsusb

This gives a list of devices attached, along with a vendor id and device id (takes the form 20bc:5500).

It was identifying my dongle as an Xbox 360 controller. Yay! That was something at least, so I installed an xbox 360 gamepad driver by using:

sudo apt-get install xboxdrv

sudo xboxdrv --detach-kernel-driver

It still didn't seem to do anything, but I needed to test whether it worked so I installed a joystick test app, 'jstest-gtk' using apt-get.

The xbox gamepad showed up but didn't respond.

Then I realised I had read in the gamepad manual I might have to switch the controller mode for PC from D-input mode to X-input. I did this and it appeared as a PS3 controller (with a different USB id), and it was working in the jstest app!!

## Under Android Emulator

Next stage was to get it working in the Emulator. I gather the emulator used with Android Studio is qemu and I found this article:

I followed the instructions here, basically:

Navigate to emulator directory in the android sdk.

Then to run it from command line:

./emulator -avd YOUR_VM -qemu -usb -usbdevice host:1234:abcd

where the host is your usb vendor and id from lsusb command.

This doesn't work straight off, you need to give it a udev rule to be able to talk to the usb port. I think this gives it permission, I'm not sure.

Navigate to etc/udev/rules.d folder

You will need to create a file in there with your rules. You will need root privileges for this (choose to open the folder as root in Nemo or use the appropriate method for your OS).

I created a file called '10-local.rules' following the article.

In this I inserted the udev rule suggested in the stackoverflow article:

SUBSYSTEM!="usb", GOTO="end_skip_usb"
ATTRS{idVendor}=="2563", ATTRS{idProduct}=="0575", TAG+="uaccess"
LABEL="end_skip_usb"
SUBSYSTEM!="usb", GOTO="end_skip_usb"
ATTRS{idVendor}=="20bc", ATTRS{idProduct}=="5500", TAG+="uaccess"
LABEL="end_skip_usb"

Note that I actually put in two sets of rules because the usb vendor ID seemed to change once I had the emulator running, it originally gave me an UNKNOWN USB DEVICE error or some such in the emulator, so watch that the usb ID has not changed. I suspect only the latter one was needed in the end.

To get the udev rules 'refreshed', I unplugged and replugged the usb dongle. This may be necessary.

Once all this was done, and the emulator was 'cold booted' (you may need to wipe the data first for it to work) the emulator started, connected to the usb gamepad, and it worked!

This whole procedure was a bit daunting for me as a linux newbie, but if at first you don't succeed keep trying and googling. Because the usb device is simply passed to the emulator, the first step getting it recognised by linux itself may not be necessary, I'm not sure. And a modified version of the technique may work for getting a gamepad working under windows.

• 1
entry
• 0
• 77
views

#### Recent Entries

Latest Entry

NeutrinoParticles is a Real-time Particles Effect Editor and it is a new extraordinary editor on the market.www.neutrinoparticles.com

What makes this editor recognisably different than other editors is, it allows you to export the effects to the source code in JavaScript or C# which makes them extremely compact and fast, and it is absolutely FREE.

MacOS and Linux users may use WINE to run the editor for now. Native packages will be available soon.

Particles Effect Editor, JavaScript, C#, Unity, PIXI Engine, Generic HTML

The software has some renderers for JavaScript (PIXI Engine, Generic HTML) and for C# (Unity, C# Generic).

For example, if you use PIXI on your projects, you only need to copy/paste several lines of code to make it work.

• 2
entries
• 1
comment
• 80
views

#### Recent Entries

Latest Entry

We've uploaded a video to our Dailymotion account that is a full length recording of the intro text scene we've been working on for the game.  This was interesting to do because we've never done animations that are timed and sequenced.  The intro quickly details the lore a bit, who you are (good), who's the bad guy, and some history behind your powers and training.  This is one of the first things we've made for the game that is actually a playable part (not a test level, or rigging to get controls right).  Follow for more updates on the game, hope to show the tutorial section of the game quite soon.

• 1
entry
• 2
• 79
views

Latest Entry

# Game Programming Resources

Rodrigo Monteiro, who has been making games for twenty years now, started a thread on Twitter for sharing his favorite game programming resources. I then collected those and a few responses and indexed them into a Twitter moment here:

Here’s what was in the thread:

Game Networking: https://gafferongames.com/categories/game-networking/

Development and Deployment of Multiplayer Online Games by IT Hare / No Bugs’ Hare is a multiplayer game programming resource split into nine volumes; the first of which is available here on Amazon.

Linear Algebra:

Geometry – Separating Axis Theorem (for collision detection): http://www.metanetsoftware.com/technique/tutorialA.html

How to implement 2D platformer games: http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/

OpenGL Tutorial: https://learnopengl.com/

Audio Programming: https://jackschaedler.github.io/circles-sines-signals/index.html

Entity Component Systems provide an alternative to object-oriented programming.

Entity Systems are the future of MMOG development: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

What is an entity system framework for game development? http://www.richardlord.net/blog/ecs/what-is-an-entity-framework.html

Understanding Component-Entity-Systems: https://www.gamedev.net/articles/programming/general-and-gameplay-programming/understanding-component-entity-systems-r3013/

Alan Zucconi blogs about shaders and game math for developers on his site: https://www.alanzucconi.com/tutorials/

AI Steering Behaviours: http://www.red3d.com/cwr/boids/

Bartosz Olszewski blogs about game programming here: gamesarchitecture.com

How to write a shader to scale pixel art: https://colececil.io/blog/2017/scaling-pixel-art-without-destroying-it/

Here’s podcast on C++ programming: http://cppcast.com/archives/

Note: This post was originally published on my blog as game programming resources.

• 3
entries
• 2
• 240
views

Latest Entry

# Main character : Zoile.

First shared concept art ! Please give me your tough about him (comment below, share and subscribe). My first intention was to reveal the plot, but I felt like the blog was missing some more visual support. 10 followers and we will unlock a new character next week

### Today's question: who was your favorite game, cartoon or comic book heroes and why ?

Zoile is the main character of a group of three. In our game, you will have the chance to control 3 main character, each having individual weakness and strength. You will be able to control them all at the same time and all the time ! How you will control them will be covered in an upcoming post, but promise to be a fun and unique way of handling different skill set. I remember one of my old time favorite arcade game 1989 Teenage Mutant Ninja Turtle. My favorite character was Michelangelo, but Donatello had this long stick that could reach enemy from a much further distance making him the best choice to fight the first boss Rocksteady which I felt was the strongest of the game beside Shredder. It was always annoying to have the choice between the one I liked and the one that was most capable to handle that situation. I felt the same thing playing many RPG like Diablo, II and WoW where you just can't invest enough time in all classes and you always dreamed to mix and match class skill to get the best possible character you could build that would match your play-style. How we approach that problem will be reveal soon.

Quote

At this point in time, you may feel that ETs are old-dated, unrefreshing and filled with "cliché", think again. I swear that our anti-heroes are different and that the plot and the phylosophical humorous twist that will be explored in this universe is very different and refreshing from what you have in mind.

Zoile is the self-proclaimed leader of our squad. He is particularly strong physically for his race and possesses a quick wit, few have dared to challenge him. His descent gave him a high level of  self-confidence and Zoile quickly became imbued of himself. Afraid of none, he sees himself as one of the best fighters of his race and has an unwavering pride of his homeland. He was born from a war hero and has always dreamed of becoming a full member of the prestigious flying squad of the 452b Pekler Interplanetary Army. After several failures in the admissions exam, Zoile became very mean and bitter towards others. After 4 years of attempts, he finally was accepted as a low rank recruit. It is said that his father intervened with the council so he could have the chance to demonstrate his value. Unfortunately, many disciplinary problems and conflict with other members have confined him in low rank function. After several difficult years with the squad, the high council allowed him to create a small squadron with two members of his choice for his first mission. He, unsurprisingly selected the only two members with whom a sincere friendship was developed. The two members accepted the honor after a convincing patriotic speach from Zoile and since then he has taken his role with the great honor. Despite is strong wrong and frequent fight with his two friend, he is willing to give everything to show to everyone that his team is the best, because he is the best leader and a good leader can bring weak soldier to great honor.

You can see Zoile with and without his armor set and a typical ray-gun weapon. The Zarin are a humanoid skinny race from a nearby planet.

Zarin, as a race, are mostly peaceful, minding their own business and seeking knowledge. They have an equivalent length of evolution compared to human, but they took a different path. They are scared about a recent discovery they made that put their world at risk of what they call the "multicolored tall people invasion". More info about the Zarin will be shared in an upcoming post !

Thanks, please share your opinion, it's very valuable. 5 comments and we publish a video tutorial on how to draw it.

• 196
entries
• 58
• 29875
views

#### Recent Entries

Latest Entry

I'm a man on a Mobile Gaming Quest (MGQ) to play a new mobile game every day, and document my first impressions here and on YouTube. Below is the latest episode.

Run, swipe, die. Rinse and repeat. Seriously, Glitch Dash looks gorgeous but might just be the most difficult arcade game I've played on mobile (well, apart from Flappy Bird). Avoiding the swinging hammers and laser beams is pure torture, but extremely satisfying when you finally complete each level.

The game's currently in beta, but I decided to include it as I was having a lot of fun with it, and I figured some of you might want to signup for the beta.

## 1) Localization will be key

To make your game connect its audience in different parts of the world your game needs to speak the language of your audience in different local markets. There are many markets that are far from dominated by any single language, and often these markets offer the bigger untapped potential for new game apps. While localising the game language is crucial, there are other considerations as well.

Localisation should also be offered through a selection of payment methods. The selection of payment methods should be made available as per the penetration of such methods in respective markets. For instance, markets having lower credit card penetration should be given other methods of payment for the game players. In some markets, third-party payment solution or third party publishing rights may be good solutions while in others they may not.

## 5) Game ads rewarding players

Mobile game players are more habituated with promotional contents compared to other app users. With the traction and engagement for in-app ads to garner any substantial revenue often a game needs a huge audience or players to earn a substantial value. This is why game ads need to be thought in a completely new light. Rewarding game players for watching game ads have come up with a really effective strategy. Around 80% of game players prefer watching video ads for game rewards.

Sponsored contents within mobile games continued to remain another popular aspect of many mobile games in the recent years. It started way back in 2015 when Angry Birds players were allowed to kill the awful pigs by Honey Nut Cheerios as long as for 2 whole weeks and thus promoting another game app. Soon, several other games followed this trend which incorporated elements of other game apps in the gaming actions for the purpose of sponsorship. It works great specially for developers who have multiple game apps with a few successful ones across the board. In the present year, we can see mobile game developers to reduce dependence on the in-app purchase by embracing these rewarded and sponsored ads.

## 7) Merchandising game products

Merchandising your game-related products to the game players is still effective for too many mobile games. But it needs at least a certain level of commercial success for the game app. Only when your game has a widespread following and enjoys a niche branding, you can come up with the marketing of in-game characters shaped into real life products like t-shirts, stuffed toys, game-inspired cars, and even notebooks or coffee mugs.

## In conclusion

All these strategies and avenues seem to have one thing in common, and it is more about connecting audience more specifically and in a targeted manner. In 2018, we can expect these strategies evolve further.

• 1
entry
• 0
• 1213
views

#### Recent Entries

Latest Entry

It's been awhile since I've been on this site.  Been busy at work, but as with all contracting, sometimes work gets light, which is the case as of the new year.  So I saw this challenge, and thought it might be fun to brush up on my skills.  I've been working mainly with embedded systems and C#, so I haven't touched C++ in awhile, and when I have, it's been with an old compiler, that's not even C++11 compliant.  So, I installed Visual Studio 2017, and decided to make the best use of this.

Time is short, and I don't exactly have media to use, so I decided to just go out and start to learn Direct2D.  I have little experience with any modern form of C++, and zero experience with Direct2D and XAudio.  Whereas I didn't mind learning Direct2D, I fully admit XAudio presented a bit of problems.  In the end, I blatantly stole Microsoft's tutorial and have a barebones sound system working.  And unlike the Direct2D part, I didn't bother to spend much time learning what it does, so it's still a mystery to me.  I'm not entirely sure I released everything correctly.  The documentation said releasing IXAudio2 would release objects, and when I tried to manually delete buffers, things blew up, so I just let it be.  There are most likely memory leaks there.

As you can plainly tell, this is by far the worst entry in the challenge.  This is as much of a learning experience as an attempt to get something out the door.  I figured, if I couldn't be anything close to modern, at least be efficient.  And I failed at that miserably.  Originally I wrote this in C.  Excluding the audio files, it came out to a whopping 16 KB in size, and memory usage was roughly 6 MB.  And then I decided to start to clean up my spaghetti code (I said start, never said I finished), and every time I thought I was getting more clever, the program grew in size and memory usage.  As of right now, it's 99 KB and takes up roughly 30 MB RAM on 720p resolution.  I haven't really checked for memory leaks yet, and I'm sure they exist (beyond just the audio).  In reality, I'd prefer to clean up a lot of the code.  (And I found a few errors with memory management, so I need to track down where I went wrong.  I removed allocating memory for the time being and pushed everything onto the stack.)

The other thing is, this code is ugly.  Towards the end, I just started taking a patchwork approach rather than keeping it clean.  I was originally hoping for modularity, but that got destroyed later on.  And I'd love to replace the pointers that are thrown liberally throughout the code with smart pointers.

Unlike the other entries, I only have missiles for the gameplay.  I didn't include UFOs, airplanes, smart bombs, nor warheads.  I just don't feel I had enough time.  Yes, there's still a couple weeks to go, but I'd prefer to cleanup what I have than add new features.  And unfortunately, I was a bit shortsighted, which caused problems later on.  There are multiple places where the code is far more verbose than it needs to be, because I wasn't properly focused on the correct areas.  I wanted to make it scalable, and I focused making the game a 1:1 ratio internally, yet displayed 16:9 to the user, which caused massive problems later on.  I ended up having to do math on pretty much every piece of graphics and game logic whereas if I had just displayed it as 1:1, or handled the internals in 16:9, I could have shaved off a thousand lines of code.  And it also caused problems with hit detection, which is another reason I didn't bother adding in anything but missiles.

The hit detection was a mess.  I had everything mapped out.  The game was going to work whether a missile went 1 pixel a second, or 1000 pixels a nanosecond.  Calculating moving objects and collision with circles or boxes is easy.  Unfortunately, I was using ellipses.  And while there are formulas for that, I'll admit my eyes started to glaze over at the amount of math that would be required.  In the end, I decided to leave it buggy, and only detect if it was currently in a static ellipse, which is easy and fast enough to calculate.  I mean, I guess if the program freezes up, the user was going to lose a city/silo anyway, or lose it if the missile was traveling at light speed, but it's still a bug, and still annoys me, especially since everything else was calculated regardless of what the user sees. (*EDIT* Thinking about this more, the solution was right in front of me the entire time.  Just squish the world back to 1:1 and do the hit detection that way).

Controls:

1,2, and 3 control the missiles, and the arrow keys control the cursor.  Escape for the menu, and Enter for selection.  I've only tested this on Windows 10, as I'm pretty sure it requires those libraries.  It's a 64-bit executable.