• You can syndicate your blog to the GameDev.net community.
Learn how here.

# Blogs

## Surprise Music!

So, I got really close to getting a new build out last night, maybe tonight. If you've played thus far, you've probably noticed there wasn't any music.  I hadn't even thought about it much, more of a final touches thing in my mind I guess..  But then I got a DM a week or so ago, randomly from a very nice guy offering to help with that. Then this morning I woke up to an equally nice bit of theme music in my inbox! Check this out!  Sling Bot Boarding (Theme).mp3 I think it's pretty rad. Let me know what you think?!   Check him out, here's his info(he approved the share): User: @Jacky Chan https://soundcloud.com/jacky-chan-536075013 https://open.spotify.com/artist/4CeAevk6JYAzqIJAqVz3g5

## GameDev - Dungeon Crawler Challenge - Part 1

Well, I'm late as always to the show, but I sat down today for a few hours and created my concept for the entry along with the base mesh.   For this challenge my intent is to have the player play as a goblin looking creature with the object of escaping the goblin den. There will be other goblins that the player will fight, and I'm planning on using a Diablo style for this entry. The basic level layouts will be rooms connected by hallways, and these will be random per 'level'. Levels will happen once you beat the boss for each floor and you will be presented with a door to enter to go to the next stage. There will also be rooms with chests that have higher loot values, but cannot be opened until you kill the key holder in that room. All goblins will drop loot as well, and potions to heal. At the start of each spawn point there will be a shopkeeper to gamble gold for new items, and to buy potions. The player will level up with EXP, and can apply to STR, DEX, and HP. STR allows you to do more DMG plus meets equipment requirements. DEX allows you to hit more accurately, and also impacts equipment requirements. HP will just increase the player's health pool. Equips in the game will consists of helms with a variable of abilities, chest armor, shields, and swords that can do elemental damage, and cause poison damage on top of physical damage. I only had a few hours to make the base mesh for all the spawns, and the player. I started with primitive shapes to help sculpt my forms then added in more detail as I went. I still need to fix up some things, but for the most part it will be okay as the camera isn't close enough for extreme levels of detail. Low Poly: High Poly:   Test bake, and quick paint job: NOTE: I haven't added in eyes or eye lids yet.     Game Concept camera positions:   I will need to fix up a few issues with the model, add in the eye lids, and eyes, then detail in the skin, and make a generic paint job for the base. Then I'll create variations using texturing for all the enemies, and bosses. In my next update I will show case the armor equipment, shields, swords, and helms along side the completed goblin mesh. 'This blog entry is for the GameDev.net Challenge'

## This Week in Game-Guru - 1/14/2018

This week's update will be a bit shorter than usual as I am in crunch mode for my book (which goes to the publisher in Feb).

So just a quick pass on the GameGuru stuff from this last week:

Official GameGuru News
Nothing official but it seems the issues list on Github is climbing ever higher. Maybe we'll see some of those get knocked off soon?

What's Good in the Store Lots of good things out there this week, notably the RPG pack by moshroom and the music packs shown below.

However, it seems Dvader dropped a pretty unique 'lockpicking' script that brings to mind a certain game set in post apocalyptia.
I'd love a video of this, but for now, this still will have to suffice!

Free Stuff A free top-down low poly character: https://forum.game-guru.com/thread/220434
Tarkus1971 put out a new track called 'the realization' - https://forum.game-guru.com/thread/213190?page=5#msg2610573
Piratemyke is continuing to provide interesting free models (in a sense) made with the EBE: https://forum.game-guru.com/thread/220414

Third Party Tools and Tutorials Nothing new this week.

Random Acts of Creativity (WIPs) Karmacomposer posted a sneakpeak of his current work:
Not bad! Though with these entities I'm sure the optimization phase will be an absolute bear.  Good luck on your project, Karma. Details available here: https://forum.game-guru.com/thread/220427

Maha25 posted an interesting screenshot of a Jungle-based project called N.D.A. -

You can get more details here: https://forum.game-guru.com/thread/220404

Ramiro has a new project (Psalm of Salem)on their way:

In My Own Works
My 3 proofers have basically been working at getting their updates done, which I have to incorporate into the book while simultaneously doing a first draft edit.  Initial feedback is very positive. I also have my editor looking at it so he can make appropriate changes to help cram this in as quick as possible.  Next week will be me making pictures and formatting changes.  Then I *crosses fingers* will be done.

## Photo finish - automating previews of levels

Hi all, The main project for this weekend was to get powerups tied to an actual level in the game, which i have now got working as in the video below: With this out of the way I have decided to progress onto the next feature of the game which requires development. This is the level select page, which you are presented with if you have previously unlocked any levels in the game, letting you revisit and replay them to get better scores and collect extra powerups. Within the menu, each level should have a preview image, or thumbnail, showing its appearance to allow for visual memory of which level is which. This was previously implemented on the .NET version of Firework Factory, as can be seen below: In the newer unreal engine version this must be re-implemented. In the previous version, screenshots were taken by spawning the entire level, taking a screen capture of the level and storing that in a texture. I decided to do something similar in UE4, only to find that doing so would be overkill, as instantiating a level is quite expensive, and would have to be done dozens of times on startup just to capture screenshots to render targets, which could then be turned into materials, and displayed in the menu. Instead, i chose to make a 'photo studio', and get the levels 'photographed'. Yes, you heard right, a photo studio. The solution for the problem is to first create a separate map. Within this separate map create a couple of strong directional lights to ensure that there isn't too much shadow in the images. Secondly, create a floor made of a non-emissive completely black material with no reflectiveness. Essentially, this floor is impossibly black, much like it has been painted with vantablack. Next, I set up a blueprint to incrementally load each level in a loop, wait 1 second for the postprocessing effects to settle, and issue the console command: HighResSnapshot 3.0 The code for this can be seen in the blueprint below: This causes the game to save a screenshot of the current level to the folder Saved\Screenshots\Windows, where it can be loaded into GIMP and autocropped, giving me an image like the one below, which is the one for level 4: These can then be associated with the levels as a Texture2D by importing them into the content folder, so that a thumbnail can be displayed. As i add new levels, i just re-run the process to generate the snapshots, pick the new levels images, autocrop them and drop them into content, which takes all of 30 seconds. This means i can ensure that all the images are taken from the same angle, with the same lighting, the same postprocessing effects, and have an image of exactly the same dimensions. Next on the list: Use these thumbnails for an actual level select menu! Feedback as always is more than welcome, stay tuned for further updates!

## Final IK Set Back

While testing Final IK we ran into a problem with our code which we're working to resolve currently. We've also been working on art assets this week and have been developing plans for the music and fx we hope to use. More to come soon but for now here is the WIP Logo we will be using.

## The Team is Back, Hard at Work

Janus is currently animating a flopping fish, our newbie Josh is planning out the controls and instructions while the rest of our team is fine-tuning our other mini-games.

## Dungeon Crawler Challenge - Update 2

This past week I ended up working on a torch light feature. I feel as though I should've been focusing my time on creating enemies to fight and items to pick up and use but this was something I just couldn't pull myself away from. Always so close to having everything worked out that just a little more time wouldn't be an issue. My hope is that it leads to something that ends up being more enjoyable in the game than frustrating. In any case, I have something that is pretty much what I was aiming for. It's a basic spotlight kind of thing that I can attach to generic things that I add to the level and it's possible for the player to pick those things up and walk around with them (though there's a bit of refactoring to sort out). I tell myself that being able to place torches throughout the maze will be kind of cool and be a part of the exploration. Being able to see everything around you makes a maze way too easy to navigate. Being able to pick up and put down items is a step forward as well. The player moves over the item to pick up and presses a key and the item is now in your hand as you walk around. An inventory won't be far off and I think that's where picked up things will be placed into by default unless I think of some UI that's more convenient. With being able to move things in the game from one place to another, the player would be able to bring keys to doors or perhaps some other tool to resolve a puzzle, if I can think of something. There's a bit more to finalize with moving things around but I think next I might want to look into a jump functionality. The maze you walk in isn't a cave environment with walls all around you but more like a platform to walk on. Maybe it's a path in a swamp. So maybe finding places that are safe to jump across could have potential. And maybe the distance you can jump is affected by how much you're carrying. Lots of "maybes". Hopefully it all comes together.

## Everything is in the Wrong Order!! - Test Adventure Dev 05

G'Day.... This is a quick post as I wanted to get something "shown". So this is just a quick demonstration of the application running. It is showing the start screen and then playing the Cinimatic_Enter for the 1st room you find yourself in. There are a few features you can see in action here. The game engine initialises. This dose a lot of stuff like reading in text files for rooms and items and word lists. It also resizes the console to a non-default shape. This is as I wanted more vertical room to allow for long text strings. I also elongated it as well. It shoul fit comfortably into a 1280x720 screen so I doubt the resize will be an issue. Unfortunately there dose not appear to be a way to "lock" the user from resizing the screen. It is just up to them to not do it I guess as resizing the console will destroy the screen formatting. Then it prints the "start screen" this is the big Adventure Text and my message under it. These are actually two different print functions. One is a "frame print" that is a instant display, well really just a super fast display if lines) and the other is a "type written" effect that types out each character at a time. You might also note that there is a dynamic wordwrap that makes sure the text has a nice margin on both sides and no spit words across lines. The cool thing is that the user can use any key to "skip" the text output to the end. After pausing for an Anykey it then starts the actual game. We are now in the main game loop that takes input then returns to a point that takes input. Then it prints out what I am calling a "Cinematic". In this case the cinematic is the "entered the room for the first time" List<string>. All this data is read from external text data files and can be changed by simply editing the files in a notePad. These Cinematic only play if certain switches in the room are triggered. So every input loop the room.Activates().. but the switches determine what automatic information is displayed before accepting input. This way I can add any story text or events or scene changes, and then after that, no matter how may times you re-enter you do not see them again. So in this case the CinematicEnter plays the very first time the player enters the room.   Aren't I supposed to be working on the CommandPhraser? YES! yes, I am. A good mate of mine who is a programmer recently got over sickness and rebooted his online presence. After I was telling him of my project and how it has been going and he kinda gave me a bit of a scolding. Apparently, I have done one the cardinal sins. I have been focusing on the wrong stuff. Almost on polish rather than the meat of the application. Meaning that I have done a lot of work here and have really failed to make anything but minor inroads into the command phraser. Which is really the entire focus of the application and the main "chunk" of it I plan to be carrying lessons form into other more complex projects for the stage 2 "2D" projects. Without a command phraser there simply is no game. So why have I not prototyped that first in a clean simple environment? I dunno man.. I dunno. I probably should have haha! You see I was trying to build what I have now.. an environment that I can easily test commands. So I have a player sitting in a room, with items and in a level. While I was building the DataReader I found I was working on phrasing data I had no real idea on how to use. So during the rewrite I redid the code to be generic. It now reads raw individual lines into strings or reads raw individual lines between brackets into List<strings>. So I am not longer restricted with pre-planning the entire data file. It is trivial to add more read data types as I need them. So now I had the data reader, it seemed logical to me to work though in a forward,s tep by step kind of way. So I add and use in a "real" manner the data. Rather than having all this junk data. So when I am coding the command processor I am also coding how the read inputs can be used in a scene and at the same time build the exact data it needs to do those commands. Without having to pre-plan everything. Well that is my reasoning.. I still think I probably should have made sure my command processing concept was workable before hand... oh well. Regardless I am pretty happy with were the project is right now. Everything seems to be working as I wanted, and I am now in the exact position I planned to be.. as in a area free to experiment wit the command phraser and it's action implementation in a hands on kind of way. See ya next time! --A4L

## Noel's Hope - is alive!

Noel's Hope - is alive! Hello!
Not a little time has passed since the second post, but the project is still alive;)
Moreover, after a series of successful and not very successful tests, the project is finally ready to try to go in Steam Shop and conquer your hearts!
Noel's Hope - This is a story in RPG, Survival, Adventure style with a small of Roguelike genre.
What game should be expected now?   Collect resources for survival, build useful objects on the ship, improve your character, upgrade characteristics, explore the islands and dungeons, destroy bosses, solve secrets, help survivors, find satellites and etc.!
There are dungeons/islands and some zones in the game, with auto-generation of traps, enemies and useful items. Also bosses, additional quests and many stories! Unfortunately, because I am alone make this game - I had to use a lot of Free Open Source models, textures, etc., which probably already become boring of games on the Unity3D engine, but without this, the game could not exist... An important aspect is the COMMUNITY and the feedback that will be. Your opinion about the mechanics of the game, about which points you liked / didn’t like, what needs to be changed, what to adds, what to news and etc. I really hope that "Noel's Hope" will like to those who love these genres of games! p.s. In the game is not fully implemented the plot, for several reasons - one of them, the lack of a good, high-quality translation into English. (Yes, I use Google Translate + some plugins + some help else, but this is not enough!).
The game is in early access until the plot is fully implemented, like some new mechanics. Much of what was planned - I am implementing right now and in the future this will be even more!
Thank you for understanding Trailer: Idk, why videos (.wmv) don't work here, so just a link on Steam Page (Trailer) Screenshots: Dungeon gate example: Magic Ocean: House on island: CHA-A-A-A-ARGE! Skill upgrade tree: Treasure:   Steam Shop: Steam Page P.p.s. I’ve almost finished preparing a big update, in which appear the heavenly islands, new types of traps and something else.
The work on Alchemy and tools of the ship, is also actively underway. Thanks for attention:) P.p.p.s.

## Gameplay Games from Xilvan Design!

Hi everybody, Xilvan Design building 3D games since 2004 in Blitz3D, we are now presenting you our kindly official gaming related pages: - The Xilvan Design Website - (please click on each links, download games & bookmark the pages): Lights of Dreams IV: Far Above the Clouds v10.57. Candy World II: Another Golden Bones v14.37. Candy Racing Cup: The Lillians Rallies v4.07, Candy World Adventures IV: The Mirages of Starfield v8.07. Candy to the Rescue IV: The Scepter of Thunders v8.47. Candy's Space Adventures: The Messages from the Lillians v18.57. Candy's Space Mysteries II: New Mission on the earth-likes Planets v9.07. Heres my YouTube Channel ZeldaOOT, where we are showing Candy's & Lights of Dreams Series. Lately, I was working on newer video for my fans. - My Youtube Channel - Friendly, Alexandre L., Xilvan Design.

## Unity Weekly Updates #27 - Ｓｔａｒｉｎｇ　ｉｎｔｏ　ｔｈｅ　深淵

Why hello there, and welcome to this 27th weekly update! I've been cooking up something literally game-changing (sorry for the pun). Hang on tight and be careful not to fall, and let's get right to it! Steppin' In my previous post, I've ended on a bit of a teaser. I've talked about an algorithm that helps to create varied types of floors. In essence, the idea is to be able to "paint" different floor type onto a 2D array  (or an "image" if this is abstract enough for you). Once that image is painted, we simply render it and generate special floor types all around the level. The Array Because I've previously used this Unity tutorial as a basis for building my level generate, reusing it was really ideal. I've simply added another 2D array that describes floor types at a given position. Because I've also previously worked on another 2D array algorithm for prop placement, I've also taken the liberty to reuse those drawing algorithm too. By mixing both codes I was able to create a reliable 2D array that was easy to modify and access, which is arguably really nice to have. The Rendering Now that the array is set, we now need to somehow render that array to the level, which wasn't as straight forward as it seems... Because I've followed that tutorial, the algorithm I use is the mighty Marching Square algorithm, which does work nicely on binary maps... However, my floor map isn't binary. This creates a pretty glaring issue: corners. While I can treat each floor type as their own binary map (and consequently as their own mesh altogether), their corners won't match up and will create holes where there should be none.
Notice the small bright pink triangles on this map So we need to tweak the algorithm to fix that: we don't want the ground to be swiss cheese... Patching-up holes After thinking about it thoroughly I could list up the "problematic" cases. First, we could narrow down the problem by simply stating that because a square only has 4 sizes then there could only be as much as 4-floor types per square. this limits the amount of case to search. Then it was only a matter of visually scanning every problematic case possible. Here's what I've found: As we can see, there's a pattern forming. We can state that problems only occur when the following conditions are: The floor type we are currently rendering only has one active node for a problematic floor square. There are more than one floor type for that square The biggest sum of the total number of active nodes between two types of floors is less than 4. Aside from that, there's also the idea that only non-corner floors can be problematic.  One thing to note is that there are two configurations that are exempt for it: As you can see, when there are exactly 3 types of floors with these configurations then there are no holes at all... The algorithm In order to fix those problematic cases, a new algorithm was in order. After snooping around and searching different marching squares tutorial and/or general discussions, I've decided that the best course of action was to use dual squares at these junctions. For those who don't know, dual squares are the more conformal cousin of marching squares.
From left to right: marching, dual In essence, with marching squares, we want to create a "triangular" meshes with "rounded" corners (Think of it as a "smoothing" function for pixels), while with dual square we take their dual point. Like marching squares, dual squares also works by building indexes for particular squares. It's just that when it comes to rendering, duals are far more square that their marching counterparts. To illustrate this, here are the possible configurations for marching squares: And here's the same thing for dual squares: One particularly alluring thing about dual squares is that I can simply reuse the code for building marching cubes meshes but just create another vertices-creating function which creates those squares meshes. This is far easier to plug into the previous code. Walkable floors types Another important thing to note is that even though we now have a hole-free ground we also need to do another step in the rendering. The way the enum is organized is that there are certain floor types that are marked as "non-walkable" (i.e, they aren't your typical floors). Every non-walkable floor type has a chance to be completely invisible. This means that the player could see holes where those type of floors would be. Not really aesthetic if you ask me... So, in order to fix these, I've decided to create walls that would surround every walkable floor. Thus, if a non-walkable floor is completely invisible, there would be a wall and possibly a dark "bottomless" pit too. Because the tutorial also shows how to create walls you would think that just reusing that code would be great, and you'll be partially right.  Although that walkable floor map would be binary, we also need to take into consideration the aforementioned junctions, and more specifically their configuration. If we have one of these dual junction squares then the extended walls need to only encase walkable floor. Otherwise, you'll get holes in the floor again.
Notice the black triangle on the upper-left. To fix this we'll simply store an additional square for each junction that actually describes not whenever or not there's a floor there but whenever or not that node relies on a walkable floor. This way, while building those extended walls, we could simply check these "junction" square instead of the real ones. Paired with a nice fading shader this makes for a believable bottomless pit. Foor patterns Much like the props placement algorithm, this one also comes with room-specific floor patterns. It works much like the prop placement ones, but it renders directly onto the floor type map.  Right now, aside from a generic random one, there's only one other arrangement: the Island pattern. Basically, the pattern consists of a central island surrounded by non-walkable floors. There are also ridges along the rooms' entry and exit wall side. Everything is connected by semi-procedurally generated bridges. There will be a lot more different floor patterns... There will also be huge structures here and there too, like lakes or chasms. Of course, some room patterns will override these, but not all of them. Floor types Now that the technical stuff is done then let's talk about the floor types. Normal Floors This is your typical floor. Nothing special here Grass Floors  A typical grass-filled ground. It is very noisy and will get instantly noticed by enemies while walking on these. I'm not sure how to make this type of floor more interesting...  (A Geometry shader perhaps, or maybe an actual separate mesh of simple billboarding triangles...) Grass Wetness One particular thing to notice is that this type of floor will have different coloration depending on the wetness level of a room.  To achieve this I've decided to have another 2D array of the float that describes the wetness of a particular square. Like the floor types 2D array, there are many utility functions to draw on that array. I've also wanted to have some blur going on so I've decided to look into the gaussian blur algorithm, which is quite useful here. With it, I can control the amount of blur applied between different zones. After that, I store the wetness of a particular floor square in an unused UV map. In the shader, I just sample the U coordinate of vertices to get their wetness and that's it. Take a look: Here's the algorithm I've looked at. Sand Floor (WiP) This is a sandy floor. Jumping from it yields a really low jump. Mud Ew, mud! Careful not to get yourself dirty! You can't go really fast while walking in mud. Chasm   This is a chasm. Falling into them results in death, so be careful. Lava (WiP) This is your old friend lava. It is a heart-warming friend that is always there for you.  But seriously, don't get in there or you'll catch on fire. Ice A nice clear floor, yet it's quite solid. It is quite slippery, so be careful. Water Ah, nothing feels quite like a nice swim, especially when you're on fire. Poisonous Water This isn't like your normal water. Bathing in it will poison you, so be careful not to slip! Liquid Nitrogen (WiP) This is quite a scene: a sea of liquid nitrogen.  It's impossible in real life, but this is a video game. But like real life, touching this will freeze you, so be careful! Spikes (WiP) I didn't finish their design yet, but it's your old friend the spikes. You get the gist: stepping on them will hurt you so be careful! Love Potion (WiP) A bit of a stretch, but it's there! Stepping in this will make you frenzied, so be careful! Liquid Floors Another thing to mention is that I've also cooked up a wavy vertex shader that makes models wavy, which is quite useful to simulate big bodies of liquids. Here's a good look of the shader in action: wavyWaves.mp4 I've followed this tutorial to achieve this if you're interested Minor updates I've finally decided to fix most melee weapons hitboxes. Previously I've used the actual weapon's hitbox to basically see if the attack hit something. This was unreliable at best, mainly due to by both animation and code being wanky. I've changed it so that hitboxes are now more reliable and will always hit where the player aims their crosshair. This makes weapons like sword relevant again! This applies to both players and AIs Next week Last week was insane! That floor algorithm really took a lot of my time and I think it can really pay. With things like chasms, jumping now gets the importance it should have. Lately, I'm trying to somehow fit AI in this. I want to give the player the ability to "push" enemies in chasms. Right now AIs are restricted to their navmeshes, which is neat but it makes them immune to chasms, so there's a lot of thinking ahead. There's also some polishing to do with, especially with floor formations and stuff. I also need to change the visual of some floors, like for example the spikes or the grass. Afterwards, I really want to diversify enemies. This would be an important step towards having a public demo of some sort.

## Bug Fixes 1

In my last post, I talked about the Undo feature that was implemented. Undo allows you to revert the last valid move that you made and will put back the score that you had then, with a hit of two points. I demonstrated all the different ways that you can undo your moves, basically all the different possible moves that constitute a valid Undo move. Furthermore, I introduced a bunch of bug fixes related to the game. I did not demonstrate how the bug fixes are now working, however, this blog post future blog posts that include bug fixes will now be accompanied by a small demonstration of the expected result. I had scheduled some time for me to work on the Autocomplete feature. For this feature, the user will be able to right click anywhere on the board, and all the cards that are face up that can be moved to any of the foundations will be moved there. As I was preparing myself to start work on this feature, I glanced over at the number of bugs that were lingering, and I felt that it would be a nice gesture to get a few of the bugs out the door before I start work on a new feature. Therefore, I took a step back and got to work on a bunch of bugs, which I will present to you below, and one feature that handles the spacing of the cards more accurately to that of the original game.
1. Clicking on the stock and then performing an undo, does not subtract 2 This is now working, and as you can see, performing an undo after clicking on the stock, will now subtract 2 from your score
2. Double-clicking on an Ace will position itself momentarily at 0,0 if you hold the mouse down on the second mouse down There is an issue related to the container of the game being invalidated, causing a refresh and whatever card you have on that container having its bounds set to 0,0. This is now fixed and working as expected.
3. Switching from outline to non-outline does not update the cards in the talon view There was an assumption made a while back that if something is not visible, it should not be able to receive events. This is obviously not a good assumption to make. The code has been changed so that all registered objects of a particular event will receive event handler invokes, and it is up to the underlying object to handle if it should do something or not.
4. When dragging multiple cards in outline mode, the outline does not look consistent There was a small miscalculation when the card's bounds were being computed. This is now working as expected.
5. In outline mode, doubling clicking to automove a card shows a small green artifact on the status bar This required the underlying game view to be refreshed, this is now working as expected.
6. Talon Card Proportions (NEW FEATURE) The spacing on the tableau views is now proportional to that from the original Solitaire game. Cards that have their backsides shown are approximately 3 pixels apart on the y-axis.
Whenever a card has it's face shown, further cards below will be approximately 12 pixels apart. This feature will now work as expected. I still have to handle the stock and the talon views
with respect to proportions, those have been logged as feature requests.
7. Automove shows the card at the top left on the second mouse down This issue is related to other issues with the container being invalidated, this is now working as expected.
8. Dragging more than one card causes the cards to be cut at the bottom when playing in a timed game This issue is related to other issues with the container being invalidated, this is now working as expected.
9. Playing a timed game causes the card to jump to the origin every tick This issue is related to other issues with the container being invalidated, this is now working as expected. Now that I've closed a lot of bugs, It's time to implement another feature. I will continue my work on the Autocomplete item. You can always follow my progress by following the game located at https://github.com/danielricci/solitaire and if you have any questions I will do my best to answer them.  Take care, until my next blog post.

## Character Models

Currently, we have two fully rigged models; an astronaut and an alien. We will be using the "Final IK" asset to properly sync the models' hands, arms, head, and body to the player's movements. The models were acquired from Yobi3D.com and are free to use commercially.   Sources: Astronaut: http://www.yobi3d.com/c/S8lsl21i43HTFCWw Alien: http://www.yobi3d.com/c/ctia5j1F5yvpuMvR   -Kristen

## Another #madewithcorona hit from Sphere Game Studios: Merge City

Sphere Game Studios has another hit on their hands with their new title: Merge City which is currently on Google Play’s “Indie Corner” in the “Our Indie Picks” section. Merge City is a blend of city building and merge gaming, similar to the game Merge Planes. The game play is simple: You merge two level 1 buildings to unlock a level 2 building. There are 30 different buildings to unlock in two neon-inspired worlds. You can visit other players from the leaderboard and compare your cities to theirs. Merge City is free to play with in-app purchases and is available on both the Apple App Store and Google Play. Check it out!

## The Great Tribes Devblog #33

Hello dears! And happy new year's holidays! It's been over a month since the last development diary. I have to say that I wanted to post a diary before, but faced with a intractable problem, which spent a lot of time. But all in order. According to the development plan, the first contact with AI was implemented: At the bottom of the screenshot you can see messages about crossing the army control zones with another army and the city. Now we had to develop an interface element that would display the event data: This screenshot in the upper left corner shows the implementation of UILabel with the ability to transfer text by words. An important element of the interface that is useful in the future. In the lower right corner, above the end of the course is now visible various messages, hover the mouse over them POPs up a hint (also a new interface element), with a short description of the event. By pressing the right button, the event can be closed without making any decision, and the left button can open the message.
In this case, when you click on the event button will be the first diplomatic contact in the game: It was further implemented the first maneuvers of AI. AI walks on the map and tries to determine the boundaries of its continent. In the video at Dukat https://youtu.be/69G51u_Mq3g?t=693 that is the moment where he runs over the enemy army, which pays no attention to him, because busy with study card
And somewhere in this place and at this time, I was faced with a problem, a performance problem. Our Modeler has a powerful modern computer of red Assembly. But it the game is terribly slow shipping a single core processor. The reason is simple-there are a lot of cores in new processors, but in fact they are less productive in single-threaded applications. And that moment I had a render in one stream. But in fact, the reason was not so much in this. And in the process of finding problems, I decided to count how many polygons we have in the scene: On the middle map at the maximum distance and a large cluster of palm trees - it's just scary! 15 824 756 triangles! Almost 16 million!!! After a bit of map generation, I found a place with 16.75 million. Although here is a similar place with trees gave only 8.5 million triangles: And in the middle stage consisted of about 4 million:
In General, I was glad that my render copes with such a huge number of triangles, but their number was excessive. It was necessary to optimize the number of polygons in the models. 40% decreased Poligona trees! Differences practically are not visible. Next, we have altered palms - Poligona on the palms was reduced in 10 times. 600 - 700 against six thousand of polygons per pack. While there was parallel work on the models I have been trying to simplify the geometry of terrain. Here's what it looked like before optimization: And after the first steps: But it was all done by a simple method — all smooth tiles were replaced by two triangles instead of 882. But there were still flat places that could be optimized, and I began to build polygons from those triangles that had the same height: Build on them convex-concave contour (Concave Hull). With Convex Hull ω was not a problem, I already used the Graham scan (Graham scan). But the construction of Concave Hull has a problem... Information on this topic on the Internet was quite difficult to find. I had to write the implementation of algorithms from scratch. I will not lie if I say that I read a dozen different dissertations on this topic. But all the proposed algorithms gave an approximate result with some error. After a week of torment and pain, I came up with the idea of my algorithm, maybe I'll describe it someday
As a result of two weeks of torment, I got the desired result and was able to build Concave Hull of almost any complexity, bypassing the set with holes, just dividing them into 2 halves of the hole. Received contour and triangulated it: Getting the output of such a result:
The fog of war has also been simplified:
And in zones where was present only fog of war it turned out only about 300 polygons:
But in the end I was upset with the result and tell you that these two weeks I spent in the shuffle... The algorithm developed by me gave a significant increase in performance when rendering, as the number of polygons on average was reduced by 60 — 70%. But the generation of the map began to occur 10 times slower.... the algorithm was time-consuming and difficult. 3 days I lost in ATOM RPG removing stress:) Even at work did not go. Thank God we have at this time the thermometer went off scale at the border -44 - -46 degrees Celsius. And I gave my melancholy for an excuse not to start the car. And before the new year holidays, enough to play, but the truth is not passed the game, I gave a new lightweight version of the algorithm, which was suitable only for my conditions of tiles. Data calculations for optimization were not noticeable against the background of map generation and the number of polygons decreased by an average of 40-50%.
But there are artifacts when rendering water, I had to rewrite all the algorithms associated with water.
Here is the result: Anatoly meanwhile made unit of nomads: While he lies resting While working on optimization, I came up with the idea of how to change our mountains.
Mountains have become more embossed, it is noticeable without texture, as the texture is now not suitable for them: On the grid, so in General the differences are obvious: It remains the case for small — need a new texture of the mountains. The next step was to rewrite the resource loader and map generator. Along the way, remaking the start menu for all these things:
Now loading of resources goes in parallel and then map generation begins. I did a great job in dividing the render into 3 streams. The whole difficulty was in synchronization. Now we have one thread responsible only for drawing, the second thread for recalculation of the visible space when moving the camera and other interactions with the map space, and the third thread is responsible for animation and communication with the server part. And Yes, we now have a server part responsible for all events in the game and for the AI. In turn, each AI player is a separate process. Let's summarize the work done:
- Graphics optimization from the software side.
- Optimization of graphics models.
- Server part.
- Split render into 3 streams.
- Preload resources (textures and models).
- Rewrote the fog of war, water and terrane shaders.
- Reduced RAM consumption by 20-30%
- Implemented a number of UI elements
- Redesigned start screen with the new UI.
- Fixed errors in normal calculations.
- Fixed the hills.
- New mountain.
- Introduced normalmap for terrain.
- New selection of units.
- New animation units.
- Window of diplomacy.
- Actions AI. Study the map.
- Actions AI. Diplomatic contact.
- Actions AI. The conclusion of peace, friendship, or a Declaration of war.
- Actions AI. Action units in a collision.  - In General, a lot of work has been done to optimize and not a lot of game mechanics. I hope this month to the CE goes to plan and I'm finally going to finish the city

## Our latest Websites informations...

Here's our latest websites: -Xilvan Design Official Websites- | -Weebly Website- | -Wix Website- It show everything about the older and latest development of our games! Friendly, Xylvan, Xilvan Design.

## SlingBots - Foundations for Progressive Levels

Been working and reworking a whole lot of things in SlingBot Boarding over the past few days.  I've finished up some of the lingering aspects of the NPC steering code, so they're a bit more reliable and less twitchy.   I've also been reworking some of the player controller code... Mainly because I brought back the LOOP!! I know I never put it in the game anyhow, but I posed a teaser of it a while back.  And well, it's still not IN the game, it'll be another day or two before I put out a new build, lots to do. So, great, a big loop to nowhere eh?  Nice one dude...  haha, not really..   Here you see the invisible arena that appears as you complete the SuperLoop! Inside this arena we have a new prototype Snowball Turret! I know, SUPER INTIMIDATING right?  haha!!  I'll model something more.. More!  Later..  For now, it appears to shoot snowballs just as well as a fancy model will. As the basis of my first level prototype(and it will likely be the contents of Level1) I have a grid of 20 of these guys in the middle of the arena that you must disable by exploding a snowball near them.  When they are hit with an explosion that is strong enough they get knocked off their pads and can no longer fire.  I have not yet, but I will be enabling a damage and/or power meter for arena levels and racing so that I can establish a few more lose scenarios and increase the difficulty in more ways. Another thing I've discovered on my journey to getting Tube riding working, was how to enable extended flight in a controllable manner.  So, you should expect some form of that to be appearing before too long.  But not before we have some progressively harder levels to defeat!! So, what happens when you defeat an Arena Level?  Well, that's easy, your defeated foes start appearing in the wild.  They will show up in random places around the park and will also be setup along user generated courses.  This will allow the entire game difficulty to increase as you progress through the levels.  For example, after defeating level 1 and it's array of snowball turrets, you can expect to find snowball turrets showing up on race courses and in random spots in the park.  With bonuses and rewards and awards for defeating them wherever they appear!!   Well, that's about all I feel like divulging at the moment!  More.. tomorrow probably.   Happy Coding Everybody!

## Comic for January 9, 2019 - "Status Report"

http://angriestprogrammer.com/comic/status_report

## Corepox Explained: the Lazer

Today, we will discuss the lazer: a component that can help you destroy your enemy. A lazer shoots when its’ input is greater than zero. If no input is provided, then the lazer’s input is assumed to be 1. If the input is zero or negative, then the lazer does not fire.
Here, you can see a small demonstration of the lazer. The lazers with positive or no input, fire a long range pulse of damage with the same shooting power. The actual value of a positive input is not proportional to the power of fire. The lazer with zero input, doesn’t shoot at all.