Posts

Source code available on github here.\n\nA recurring problem in 2d games is how to represent depth. In isometric games this is easily solved but in discretely top-down games it’s harder to solve. After doing a lot of research I fell onto a simple idea: do the best you can insinuating the depth and leave the rest to the imagination. Here’s the algorithm I used to create 2d top-down cliffs: Create a small map of perlin noise and a wide map of perlin noise. Add the two together and give the large map a weight of 3 with the small a weight of 1 and render the result with different breakpoints. This is ref map A. Less than 0.01 on A is deep water ...

Rivers are really hard to generate for 2d top-down games for multiple reasons: Rivers primarily form based on heightmaps which are hard to display in top-down Displaying fluidity when working with sectors or grid-based rendering can be complicated, bresenham’s line algorithm only goes so far to make things look smooth naturally occurring mechanisms of nature have numerous factors in play that caused them to exist. Simulating all of these factors isn’t reasonable. I was able to make relatively decent 2d rivers using a few techniques. ...

Two of the most influential components to decreasing LOE in balancing game mechanics is automating the most essential parts of testing those mechanics, and providing meaningful and easy to understand graphs. Some meaningful questions to better lay the foundation of balancing and creating these components: What are the actual ‘core stat(s)’ that identify survival? (Usually health) What are the ‘ancillary stat(s)’ that help facilitate the increase or decrease that core? (damage, strength, dexterity, etc.) I’m assuming all actors here are equal and we aren’t comparing apples and oranges. What are the ‘supplemental stat(s)’ that may contribute to the increase or decrease of the ancillary stats? (class, rank, level) What are the ’extraneous stat(s)’ that don’t affect the other stats already identified. I found that creating a tree by drawing lines connecting these identified stats provided incredible insight and direction. ...

I had originally written an article on how to implement PHS. Having found the maps generated slightly redundant I decided to take another look. Here are the steps taken to successfully generate a more realistic town. It’s essentially a drunken walker like Diffusion Limited Aggregation mixed with a hallway constraint that mimics the large part of PHS. Start somewhere in the middle, add this and all possible directions up to a certain dynamic length (I used a standard deviation of 1.4 with a mean of 5, ) as nodes: [{x,y,direction},...]. We will be looping until all nodes and edges (we’ll describe that shortly,) are gone. When we have node then check to see if the path between it’s ‘x,y’ and ‘x2,y2’ (given the length and direction) is clear. If it is, then add the entire path minus the start and end as edges, and add the end as a new node. Shuffle nodes after adding a new one. After building the path run through the path array randomly attempting to build a room in all directions. (this won’t be entirely possible and will leave negative space to fill with edges.) If there are no nodes, repeat step 3 except with edges (this helps fill the map negative space.) After all nodes and edges are gone then cover all cells adjacent to floors with walls if it’s empty. I found it helpful to use this simple formula to generate hallway lengths with a mean and standard deviation constraint. Both the x and y would work fine, here we’re using the y only. ...

While creating algorithms for random continent generation, I came across an old algorithm I had worked with called Coupled Map Lattice. Using that to create a continent was hard but I was able to accomplish it doing layers of filters: generate map with noise between -1 and 1 apply CML using Spatiotemporal Intermittency settings (a = 1.75, ε = 0.6) I found that using something too chaotic didn’t have a noticeable affect compared to just generating noise in general. normalize values to between 0 and 255 apply a gaussian blur normalize values to between 0 and 1 apply slight height restrictions based on distance to center of map ...

When using abilities within most games the user doesn’t have any time to look for an ability name so recalling an ability quickly by an image or icon that accurately represents it is incredibly beneficial. Similar to this idea, there are 4 basic requirements when creating ability icons. Below they are listed in priority order. It must be easily used (click/button press, etc.) The user shouldn’t have to look around documentation to understand what button to press The user shouldn’t have to struggle to hold down multiple buttons just to use it Accessibility should be taken into account (screen readers, etc.) It must be easy to interpret it’s purpose The user can immediately see the icon and have a meta thought about what it means, and thereby understand the ability that is being represented intuitively. It must be identifiably unique to other icons Icons shouldn’t look exactly alike Sometimes its best to have certain icons look similar if they have similar functions, but how similar they look should not cause confusion It must not be too distracting The icon should be convenient to the user, not distracting from the gameplay. The icon must be appropriately sized The icon must be carefully colored The icon must have an appropriate amount of contrast

I was asked a very interesting interview question today. Lets assume you have a single page application running on n users computers as a dashboard and you updated the application, how does all of the clients receive and manage the updated assets without incurring a browser refresh. The first problem to figure out is how do I know the application was updated? Polling the entry bundle asset Polling the Index.html and comparing hashes/versions Polling some custom tiny server text doc Dashboard websocket contains the version On acquisition of new data it contains version We don’t update until a change of route Now we have a version, we distinguish that the server version is ‘greater’ than ours. How do we acquire the new asset? ...

I’m commonly asked why more people don’t choose angular2 which in my head I correct to angular. (we’re on angular 3 alread.. no, 4,… no.) Quite simply, the answer is Typescript. Whether we like it or not the majority of javascript developers in our field are new or mediocre developers who don’t have the time or cognitive ease to attempt to learn another language. It was a huge mistake for the team to release the library with the small amount of constantly outdated documentation entirely in Typescript. Most stackoverflow searches for angular aren’t even relevant or accurate given the constantly changing api. Without good documentation, and so much irrelevant or outdated answers on stackoverflow these developers lose hope, and angular lost potential users. ...

Having spent a lot of money on purchasing the Pragmata Pro font (mostly to acquire a well-made set of glyphs for things like lambdas etc, I decided to allow this font to supplement my zsh theme. Here’s the results. This file is updated often and available on Github here. #!/usr/bin/env zsh local LAMBDA="%(?,%{$fg_bold[green]%}λ,%{$fg_bold[red]%}λ)" if [[ "$USER" == "root" ]]; then USERCOLOR="red"; else USERCOLOR="yellow"; fi # Git sometimes goes into a detached head state. git_prompt_info doesn't # return anything in this case. So wrap it in another function and check # for an empty string. function check_git_prompt_info() { if git rev-parse --git-dir > /dev/null 2>&1; then if [[ -z $(git_prompt_info) ]]; then echo "%{$fg[blue]%}detached-head%{$reset_color%}) $(git_prompt_status) %{$fg[yellow]%}→ " else echo "$(git_prompt_info) $(git_prompt_status) %{$fg_bold[cyan]%}→ " fi else echo "%{$fg_bold[cyan]%}→ " fi } function get_right_prompt() { if git rev-parse --git-dir > /dev/null 2>&1; then echo -n "$(git_prompt_short_sha)%{$reset_color%}" else echo -n "%{$reset_color%}" fi } PROMPT=' ${LAMBDA}\ %{$fg_bold[$USERCOLOR]%}%n\ %{$fg_no_bold[magenta]%}[%3~]\ $(check_git_prompt_info)\ %{$reset_color%}' RPROMPT='$(get_right_prompt)' # Format for git_prompt_info() ZSH_THEME_GIT_PROMPT_PREFIX="%{$fg[blue]%}" ZSH_THEME_GIT_PROMPT_SUFFIX="%{$reset_color%}" ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg_bold[yellow]%} " ZSH_THEME_GIT_PROMPT_CLEAN="%{$fg_bold[green]%} " # Format for git_prompt_status() ZSH_THEME_GIT_PROMPT_ADDED="%{$fg_bold[green]%}⮹ " ZSH_THEME_GIT_PROMPT_MODIFIED="%{$fg_bold[blue]%}⭍" ZSH_THEME_GIT_PROMPT_DELETED="%{$fg_bold[red]%}⮾ " ZSH_THEME_GIT_PROMPT_RENAMED="%{$fg_bold[magenta]%}⭷ " ZSH_THEME_GIT_PROMPT_UNMERGED="%{$fg_bold[yellow]%}⮓ " ZSH_THEME_GIT_PROMPT_UNTRACKED="%{$fg_bold[cyan]%}⯑ " # Format for git_prompt_ahead() ZSH_THEME_GIT_PROMPT_AHEAD="%{$fg_bold[white]%}⮍ " ZSH_THEME_GIT_PROMPT_BEHIND="%{$fg_bold[white]%}⮏ " # Format for git_prompt_long_sha() and git_prompt_short_sha() ZSH_THEME_GIT_PROMPT_SHA_BEFORE=" %{$fg_bold[white]%}[%{$fg_bold[blue]%}" ZSH_THEME_GIT_PROMPT_SHA_AFTER="%{$fg_bold[white]%}]"

It’s abundantly clear that making interfaces for portals, single page applications, analytics or CRUD apps is so much easier than creating applications for games. UX within games is much more complicated. Now add upon that complication a responsive design. It took the better part of 8 hours to get a design mock-up that worked on the smallest iphone device (man they’re tiny!) and that scales up to the largest phablet. I still need to work on detaching the pane and having a more ‘diablo-esque’ two-pane character panel / inventory approach for desktop users. ...