f0ssel

Go Patterns

Wed, 27 Mar 2024 14:09:36 -0400

I began learning Go in 2019, and it swiftly became my most productive and preferred backend programming language. In this article, I’ll share some common patterns I’ve observed in Go applications and explain why I favor them over other options.

Errors

Instead of checking for nil values or comparing empty structs, it’s preferable to return both a value and an error, then check the error. This approach is familiar to others and simplifies error handling throughout the codebase. It’s essential to always wrap errors, ensuring a clean and unambiguous error stack that traces back to the source of the error. Additionally, I prefer to explicitly return val, nil even when the error is nil for clarity.

// this is just OK
func parseInt(val string) (int, error) {
	return strconv.Atoi(val)
}

// this is better - clean error stack
func parseInt(val string) (int, error) {
	i, err := strconv.Atoi(val)
	if err != nil {
		return 0, fmt.Errorf("convert string to int: %w", err)
	}

	return i, nil
}

Some like to return an OK boolean instead of an error and I think that is just OK at times but I’d almost always reccomend returning an error. I do not think you should use an OK boolean over an error if the code path has multiple failure cases.

// this is just OK
func lookup(val string) (int, boolean) {
	return i, ok := map1[val]
}

// an error is better
func lookup(val string) (int, error) {
	i, ok := map1[val]
	if !ok {
		return 0, errors.New("value does not exist in map1")
	}

	return i, nil
}

// errors are required to know the failure case
func lookup(val string) (int, error) {
	i, ok := map1[val]
	if !ok {
		return 0, errors.New("value does not exist in map1")
	}

    i, ok = map2[val]
	if !ok {
		return 0, errors.New("value does not exist in map2")
	}

	return i, nil
}

If you are returning the same error in multiple places, or perhaps the same kind of error, you should consider declaring the error as a package variable. These are exported and usually the name of the variable take the shape of Err* so it’s clear to consumers what it’s for. The advantage of this is so consumers of the package can use errors.Is to check if the error matches a declared error they are antisipating.

var (
	ErrNoKey    = errors.New("key missing")
	ErrNotValid = errors.New("value is not valid")
)

func lookup(val string) (int, error) {
	if val == "" {
		return 0, fmt.Errorf("length is 0: %w", ErrNotValid)
	}

	i, ok := map1[val]
	if !ok {
		return 0, fmt.Errorf("map1 lookup: %w", ErrNoKey)
	}

	return i, nil
}

func useLookup(val string) {
	i, err := lookup(val)
	if err != nil {
		if errors.Is(err, ErrNoKey) {
			fmt.Println("404 - %w", err)
			return
		}

        fmt.Println("400 - %w", err)
        return
	}

	fmt.Println("200 - %d", i)
}

JSON Parsing

I prefer using a combination of pointers and the omitempty JSON tag for detecting optional field values when parsing JSON. This approach aligns well with frontends consuming the APIs I build, which often distinguish between undefined and 0 for number fields on a payload. It helps bridge the gap between frontend and backend communication by ensuring consistency in JSON representation.

type MyStruct struct {
	Name	        string `json:"name"`
	MyOptionalValue *int   `json:"myValue,omitempty"`
}

func printValue(data []byte) error {
	var mystruct MyStruct
	json.Unmarshal(data, &mystruct)

	// first check if it was even sent
	if mystruct.MyOptionalValue == nil {
		return fmt.Errorf("value is missing")
	}

	// this means we have a value, but it's zero
	// safe to dereference value since we checked it's not nil
	if *mystruct.MyOptionalValue == 0 {
		fmt.Println("value is zero")
		return nil
	}

	// we have a non-zero value
	fmt.Printf("value is %d\n", *&mystruct.MyOptionalValue)
	return nil
}

When using omitempty and returing JSON responses over HTTP/S you do not send the field if it’s nil or another zero value. You can then create the respective interface in TypeScript. At my current company Coder we’ve created a tool that generates TypeScript interfaces from Go structs based on this behavior and it works great.

interface MyStruct {
	name: string;
	myValue?: number;
}

Main

The main function should primarily handle signals and start the application, ultimately returning an error. It’s essential to confine exit functions like os.Exit() or log.Fatal() to the main function only. All other functions should return errors, which not only delineates the application’s start and end points but also facilitates easier testing.

package main

import (
	"context"
	"log"
	"os"
	"os/signal"
	"syscall"
)

func main() {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	sig := make(chan os.Signal, 1)
	signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM)

	go func() {
		<-sig
		cancel()
	}()

	if err := run(ctx); err != nil {
		log.Fatalf("error: %v", err)
	}
}

func run(ctx context.Context) error {
	// setup logging
	// setup database
	// setup api
	// setup http server

	<-ctx.Done()
	return nil
}

Interfaces

As Rob Pike aptly stated, “The bigger the interface, the weaker the abstraction.” Interfaces should have a narrow scope and usually end in er to denote their behavior. This pattern is widely used in the standard library for interfaces like io.Reader, http.Handler, http.RoundTripper, and http.ResponseWriter. Following the principle of “accept interfaces, return structs” ensures your codebase is easy to test and gives the consumer of your package the concrete type if needed.

// keep the interface as narrow as possible
type Reader interface {
	Read(p []byte) (int, error)
}

type myReader struct {
	r io.Reader
}

// implement the interface
func (m *myReader) Read(p []byte) (int, error) {
	n, err := m.r.Read(p)
	if err != nil {
		return 0, fmt.Errorf("read from reader: %w", err)
	}

	return n, nil
}

// return a struct that implements the interface
func NewMyReader(r io.Reader) *myReader {
	return &myReader{r: r}
}

// accept the interface
func useReader(r Reader, p []byte) error {
	// use the reader
	n, err := r.Read(p)
	if err != nil {
		fmt.Println("reading reader: %v", err)
	}

	fmt.Println("read %d bytes", n)
	return nil
}

// use the struct that implements the interface
func doTheRead() {
	r := NewMyReader(strings.NewReader("hello"))
	p := make([]byte, 5)
	useReader(r, p)
}

You can also validate if a struct implements an interface by using an interface assertion. This check is typically placed above the declaration of the struct and results in a compile-time error if the struct does not implement the interface.

var _ Reader = myReader{}

Directory Structure

Organizing commands in a cmd directory is a common pattern I prefer, especially for main packages. This practice makes it clear to consumers of the package where the entry points are located. I also favor keeping packages flat rather than nested or placed under a top-level pkg directory. This preference simplifies codebase navigation and comprehension.

myapp  
│
└───cmd
│   │
│   └───myapp
│	    │   main.go
│   
└───api
│   │   api.go
│   
└───database
│   │   database.go
│

Conclusion

These patterns have served me well in my Go journey, and I hope they help you write cleaner, more maintainable code. I encourage you to experiment with these patterns and adapt them to your needs. Remember, the best code is the one that works for you and your team.

Prototyping new Turn Based Tatics Game

Sun, 06 Mar 2016 17:33:20 +0000

I’ve been brainstorming a new tile based tatics-like game that I suppose I’m designing for mobile. I’m really trying to focus on making a project that’s DOABLE and within a reasonable scope for while I’m in school and have a budget of zero dollars. Without going into much detail, because right now my ideas are pretty scattered, I’ve been working on making a procedurally generated map the last few days and felt like showing off the first steps of the project.

Right now the map can be any radius between 1 and 99, has a rock border and rocks scattered throughout the map, and a procedural river that will always touch from the west wall to the east wall. As you can see above it doesn’t always flow so well, which is something I’m gonna be working on. I have just to impliment anything outside of built in unity perlin and random ranges, for the sake of rapid prototyping. I just changed the hexagons from shape to rounded edges today and really thought it gave a lot to the feel of the terrain. So overall pretty happy about it.

New Terrain Colors and Grid LOD System

Thu, 28 Jan 2016 22:45:55 +0000

I’ve revamped the terrain UV system to better suit the new texture design I had. Before I had a simple grid of 4 colors, and the height of the triangle’s vertices dictated which color was chose. Now, I’m using a fancy looking blurred gradient, and the height of the average of the 3 vertices are now scaled to a number between 0 and 1, and then used to choose the Y component of the texture gradient. The X scale is randomly selected at the moment, but I will most likely use a noise function in the future. This is nice because I can go in photoshop and add little details of darker and lighter colors to give the overall terrain a little more variation. It’s made with layer masks, so I can easily change the layer colors without disrupting the other colors or heights of the transitions.

I’ve been working on adding smaller lakes to the plains areas of the island and messing around with the Selector function in libNoise has gotten me more familiar with how it works. Hopefully soon I can re-write my noise generation function to include sub-biomes and overall be more expandable in the future.

I’ve also run into the same problem Facepunch, the developers of Rust, ran into a while back, and that’s having too make LOD Groups in the scene. Since the island is so massive, I was hitting this cap when I tried to add trees. Like Facepunch, I used my already existing grid system to create a LOD Group per grid. Getting this to work is a small milestone for me, since I had no understanding of how combined meshes worked before I tackled it. Basically, for every chunk, the trees get placed on the terrain. Each tree gameobject is actually a LOD Group, with 4 LODs. I took every LOD0 (highest quality) LOD mesh from every tree gameobject on the mesh, and combined them, and made a new LOD0 with all of them combined. I do this for every level of detail for each object. This results in every item on the chunk changing detail at once instead of every item doing so independantly. This drastically helped performace as well. Right now all objects stay active all the time in the scene. They simply get culled once they are too small in the camera space. There’s still issues to be worked out, I would much rather the LOD system be distance based instead of camera space percentage, since the angle of the ground can make that percentage change drastically. But it’s a great start for me and is keeping performance within reason.

Island Generation

Mon, 25 Jan 2016 02:46:25 +0000

After a good time away I’ve had some free time to spend messing with a problem I’ve had lately, and that is that I wanted a full map generated without watching chunks come into vision in the distance like they have been. I’ve tweaked my previous generation code in a lot of ways and made a lot of processes simpler and re-useable for other scripts, and finally came up with version numero uno of my island generation code.

It basically just generates the infinite noise like before but starts stretching the mesh downwards under sea level after it passes a threshhold. I was not happy with how drastic the linear approach was (you could see the change in slope very obviously, or you had mile long beaches) so I tried a quadtratic approach and ended up settling with an power of 4 for the curve from 0 to 1. Like so:

This meant that after passing the threshhold, it would very slowly start to lower elevation until it got very close to the maxium distance (this being a factor of 1 of the threshold) where it would very quickly fall off. This allows mountains to still be very near beaches without a visually obvious fall off towards the shore.

My first concern with the generations as I went through 20-30 different random seeds is that the mountain ranges always seem to start at the northwest side of the island and will continue towards the southeast side, dispite the seed being changed every iteration.

Hope to post more soon, exploring this island felt really great. I estimate running from one side of the island to the other should take anywhere from 15-30 minutes, so it feels massive. The much larger polygons and giant scale in general makes it feel a lot better than before and really opens up a lot of awesome views from the vantage points on the island.

Vertex Manipulation

Fri, 25 Sep 2015 23:58:32 +0000

I’ve been out of sorts with what I want to work on next with my project. Also, school has been keeping me pretty busy.

Runtime-player-action-based vertex manipulation is something I’ve planned on tackling for a while. Today I’ve started the ground level on how to do it. This means that a player can select a vertex on a mesh, and raise or lower it. (Think leveling an area to build a settlement) I plan to expand this idea to being able to manipulate vertices on all items and weapons in the game within margins to make things more personal and possibly add new function.

Working on Vertex Manipulation

More to come on this topic in the future.

Glider, Moon Phases, and A First Look at the Combat System

Mon, 31 Aug 2015 01:42:36 +0000

Enemy AI

What you see above is a cute little Slime. It wanders, it stays on the ground and doesn’t fly away, and it (tries) to avoid running into trees. If you get too close, it comes after you, but don’t worry it doesn’t do damage (yet). Instead it tries to get so close to the center of your hitbox if you position yourself correctly it’ll dance on your head.

The slime has a very basic AI and is the starting point of my mob system. They are inactive unless within a certain range. I may consider turning them off completely if I can find a way to do so without messing with the behavior. They have 100 health and 1 arrow shot does 25 damage, and as they lose health they change color from a nice see-thru green to a see-thru yellow and see-thru red. Eventually when it’s health drops below zero it destroys itself. But how do you do damage to it???…

Arrows

I modeled an arrow prefab and worked up a system for shooting it out from in front of the player to a target that is raycasted from the center of the camera view (it sorta matches up). They do damage to Slimes. They fly nicely through the air and are rigidbodies so they are affected by gravity and take time to reach their target. This means you have to lead your shots based on distance and enemy movement. There is also no crosshair. Good luck!

Glider

I wrote up a Glider system that works very similarly and is inspired in almost every regard from the glider in Cubeworld. It makes traveling quicker and gives great views. It works like this:

Having the glider out makes you fall slower
While in the air with the glider you travel faster
“rigging” the glider (Space Bar) uses stamina* but lets you travel farther
While rigging, your y-direction velocity is frozen and it’s ceiling is zero. This means if you time your rigging correctly with your jump you can have virtually zero falling velocity until you run out of stamina*

*Stamina is not in yet. You can rig forever at the moment

Clouds

Clouds are in! Volumetric and very in size, rotation, and density of cloud clusters. I’m STILL working on fog, but once I have a good solution they will be noticeably in the distance and not such a clear view like they are now.

Moon and Moon Accessories (Phasing)

The moon is in, and it rotated around just like the sun does. It has it’s own special light that only shines on it, and that light rotates a little bit every day, and gives the moon phases, just like in real life! When full, the moon will brighten up the night sky with a foggy glow, and will illuminate a dim bluish-white light. As it changes phases the fog will dim along with the ambient light. Right now there are 12 days between full moons. Two pictures below contrast a full moon and a half moon.

Got a lot done this week, and seems I’ve got a little bump in viewers of this blog so that’s awesome. I hope you guys like what I’m putting out. I’ve become a little more ambitious in my development goals as I’ve talked to people about it, so I’ll be trying my best to keep moving with new content.

Skybox, Time of Day, 3rd Person Camera, New Trees

Wed, 26 Aug 2015 16:20:28 +0000

3rd Person Camera

I got tired of the old cube dude model so I made another equally temporary low poly dude to take his place. I think he’s a little cuter. I’m having a hard time committing to a character concept, I really am stumped with this part. So I’ve just been going hard at the environment. I added in the old 3rd person camera, and I’m working on the controls because right now it’s shaky when traveling on anything besides flat ground.

Trees

New tree models were needed, and I think they look good. I’m going to make a few variations of similar looking trees to start mixing things up. I figured out how to unwrap a UV map in blender, as well as add ambient occlusion map to it in Photoshop, so from now on everything I model will have the sexy shadows in the edges. Only problem I see in the future is a world where everything is AO except the procedural stuff, so we’ll have to figure that one out when we get there. By making all the trees share the same one material with a texture and using more larger trees instead of a bunch of smaller trees I cut my draw calls down from around 7,000 to around 1,200 so the frames shot right back up.

Skybox

I said fuck it to the solid color skybox + fox + camera clipping for now. I just cant find a good way to make the fog work the way I’d like it to. So the default procedural skybox is in, and honestly is looks great. I’m going to try my best to work with this one. The major downside is without fog you see chunks generating in the distance. Oh well. I added stars that fade in and out depending on the sun angle, so that’s pretty cool. Still no moon though.

Night Time

So right now right time is really dark. The stars look great and the only light in the whole world is a very very dim blue light. I would like to have a moon cycle that would change every night, and depending on how full the moon is, the brighter the ambient night light would be. I think I have it figured out, and I’ll probably trying to implement that in the next few updates.

The lamp has been modified a little on it’s intensity, spread, and position with the player, so it feels a little better. It’s very rust-esque in the fact that you can see whats immediately around you, and you can sorta see stuff in the distance. I may model a little lantern for it soon to pop up.

Plans

I hope to start modeling more things to put into the world. Grass, campfires, lantern, animals, clouds, all kinds of stuff. I may not have a solid feel for the main character, but I have good pictures in my head for world objects and I’d like to start making it feel more immersive.

Optimization and Day / Night Cycle

Fri, 21 Aug 2015 04:53:50 +0000

Optimization

I’ve increased the draw distance to the length I’m happy with and it resulted in a huge amount of draw calls and dropped my locked 60 fps down to an average of 24 fps. So I’ve been doing a lot of under the hood stuff to help with that. One of the main problems is I had 4 different materials for each tree prefab, so I turned those 4 materials into 1 UV map in Blender, and that cut it down to a 1/4th of what it was. I then created LODs for the tree prefab and Occlusion Culling for not only items out of the shot but also covered by other objects in the scene. So now I can look at over 1000 trees in the distance and I can hold a steady 60 fps. Since I’ve set up the LOD and Occlusion Culling is in, I don’t think frame drops will be a problem in the future when I add even more things to the scene, so I’m really glad I started work now on it. I had to learn sometime, so even if I don’t end up using that tree model I’ll have the know how to do it again quickly.

Draw distance after LODs and occlusion culling

Day and Night

Since I’ve decided to try and make the solid color skybox and fog work together, I’ve sacrificed the ability to use a procedural default skybox that’s in Unity. So I’m going to have to figure out how to add gradients and things behind the loaded content to make the skybox look better. I need to add a new sun too. But I messed around with having a dark blue directional light facing the exact opposite of the sun’s directional lighting so that objects in shadows still have depth. It’ looks really good, and I’ll be working on a system that moves them in sync and changes the intensity of each other as the angle and positions move. I simulated some values for night time and gave myself a light like a lantern and I think it looks kind of interesting.

I’m going to find a good way to implement stars and dynamic clouds once I feel good about the state of the background sky box.

Mind Map, Fog, Water, and Rocks

Tue, 18 Aug 2015 05:11:22 +0000

Mind Map

I’ve added a link on the sidebar for my Mind Map. I saw Garry from Rust use the same site and really liked the idea of starting to put something down every time it pops into my head. Now when I feel stuck I can just look at it and get ideas for other things I can work on. (In a perfect world) Maybe one day I’ll get a little more traffic here and people who seem interested can get a rough road map of what my plans for the future are.

Fog, Real Water, and Rocks

Rocks

I tweaked the tree placement system and put rocks in. They are rotated randomly and scaled randomly between a range and placed in the same areas as trees, so it still leaves open areas of the grass to travel / build / fight. I also tweaked the code so I can shove any prefab into it and give it a few parameters and it’ll generate other stuff too (I’m thinking underwater items eventually).

Welp, class started back today. I don’t think I’ll be slowing down on my work though, I’m really starting to feel some momentum. Let’s see how it goes.

Tiling Based on Movement, Trees Placed by Noise

Fri, 14 Aug 2015 21:38:44 +0000

I’ve had some free time before school starts so I’ve been crunching out as many updates as I can. The chunk tiling I mentioned last time (like has Minecraft does it) is started and I learned a lot today about making Lists in Unity and working on items from the list every frame, instead of trying to start and finish a loop in a single frame. I originally wrote the tree placement and chunk generator to be done all at Start(), but it started taking a lot longer the more I added things, and I never planned to actually pre-generate the whole map at start anyways, it was just a good place to start learning how to do these things. So now I have chunks filed into a queue whenever you move out of the area that is already generated, and the queue loads exactly 1 chunk every frame. It works surprising well, and I’ll probably keep it like this since I plan to add distance fog in the future that will cover up any chunks being rendered in the distance. Cubeworld has a really nice looking fog that basically increases your draw distance based on your computer’s performance, or maybe based on how many chunks away it’s already rendered, not really sure since it’s just speculation. Either way it’s cool and I’d like to do something like that soon.

I messed with the colors and the height cutoffs to make it look a little better. Still needs a lot of work. Still cheating with the water plane too. The trees are generated 1 tree per frame per chunk. So where there’s 49 chunks (like in the video below) around you they are generating at 49 trees per frame. Again, except for at initial generation, you will almost never see them being generated. Still looks cool though.

ProcGen 0.1 and Tree Placement from Noise

The placement of the trees are based on a Perlin noise with a cutoff value, and after messing with the cutoff value to find the sweet spot, I really like the results. Here’s a short list off the top of my head that I think are doable goals I’ll be working on next:

More tree models
Rock spawning
Other object spawning(ruins / driftwood / flowers )
Water Implementation (just the surface)
Tweak colors / scale / noise of terrain

And here’s some stuff I have no clue how to do and plan to tackle next:

Biomes
Ocean edges
Ambient Sounds
Better Day / Night
Post Processing Effects

Honestly I’m not even thinking about a character model / controller because I think the world and the feel should come first, and I think there’s a lot more documentation on the more classical game elements than the other things listed above, so I don’t think I’ll have a hard time with it.

ProcGen 0.1

Thu, 13 Aug 2015 22:32:00 +0000

I am very happy to present the first look at my progress with low poly procedural generation.

So there’s a lot going on here. Generally speaking, chunks are assigned starting points, noise is rendered, the mesh is created for each chunk, height is given to the vertex based on the noise algorithm, and a solid color texture is given to the triangles based on the min height of the three vertices.

I’m using the Unity port of the noise library LibNoise, the noise generated in the picture above is following the tutorial made by the creator. I plan to tweak it to fit what I want, and hopefully expand into regions / biomes in the future. But for now it’s looking great and really showing off what it can do.

Right now I’m generating the meshes in chunks, each 20 x 20 (unity units?). Unity can handle about 20×20 chunks generated at start. I plan to eventually get chunks loaded based on where the camera is in the world, like Minecraft.

A straight line is used for the height cutoff values of the colors, and it doesn’t look half bad. I kind of like the even look. But I will probably use a noise function in the future to decides the colors so it looks a little more natural.

I’m cheating with the water, its just a colored plane I added at about the right spot. That’s the next task on the agenda. That, and implementing my prefab spawning script I wrote into these meshes and seeing how that works out. I’m really happy I finally tackled this daunting task, because I really just couldn’t wrap my head around the process for the longest time.

Progress is being made!

Baby Steps

Mon, 10 Aug 2015 17:55:30 +0000

I woke up today with the idea to just mess around with purely my previous knowledge of math and some help from the unity manual, and I got my first baby step into understanding how to create procedural meshes within unity. It’s a simple code that I’ll have to rewrite once I figure out how to make it fit all purposes, but I got something and I’m super excited about it.

More details to come! (When I figure it out…)

Tinted Lighting, Spawning Prefabs, Terrain Research

Thu, 23 Jul 2015 04:27:02 +0000

It’s been a while and I haven’t really worked on much over this break, but I’ve been researching a good bit on different ways I should think about tackling procedural terrain generation that will still look like what I’m going for. It’s all a bit over my head at the moment so I think I’m going to hold off on that topic for the time being. I like the idea of starting with a hand crafted map to begin with, and then exploring procgen at a later date. For now I have a little flat valley surrounded by mountains, and it’ll be my playground until I need something else.

Despite handcrafting the terrain itself, I have no interest in placing every object in the world. So I started and finished that project today, or at least the framework for it. Right now the script finds the dimensions of the mesh, shoots rays down through the mesh, finds the normals and then places the objects along the terrain normals so hopefully I can get some interesting results on hills. For some added randomness I have the trees rotate around the trunk randomly, as well as the rocks on their x and y axis. I also added parameters so that trees shouldn’t spawn on too steep of hills, and also added a density function based on the area of available spawning places. Trees shouldn’t spawn on rocks or other trees (hopefully).

I also worked on tinting the lighting. This means that in the morning there will be a cyan tint to the light, daytime will be a typical white-yellow, and afternoon will be orange-ish into a deeper red for sunset. I’d love to add a weather system soon that can work with and affect the ambient tint of the lighting.

Tree and Rock Spawning, Tinted Lighting

That’s really all for today, I hope to work on this more often but not sure for the next few weeks. I’m moving soon, working every now and then, and starting back to school in less than a month so we’ll see.

Basic Movement Controller

Sun, 05 Jul 2015 20:38:58 +0000

I felt it was important to talk for a second on the movement controller for a second. I am very particular about controllers for games, and I have ran into a few really, really good ones, and a lot of terrible ones. I will be spending a probably more than fair amount of time on tweaking the character controller throughout development, because I feel its one of the most important things in a game. I get a lot of inspiration from games such as the Dark Souls series and Cubeworld (RIP Wollay…) for the 3rd person orbiting camera style that I love so much. Cubeworld has amazing feel to it, and I plan to use a lot of similar mechanisms to achieve a similar feel in movement, camera control, and combat. I also want to make sure the game is completely playable with a controller along side mouse and keyboard, which is another reason why Unity is so great for these kinds of projects.

I have a character controller in place that I wrote a while back, and will most likely be using it as my baseline code. It’s a shitty little cube man holding it’s place for a real model. I’ve been thinking a lot on what kind of character model for a while and haven’t felt solid on a single idea yet, so he’s staying until I do. (Along with the animations I need to learn how to do at some point) It’s arcade-y and responsive and gets the job done for now. He jumps and climbs so far.

First Draft Movement and Camera

I messed around with lighting for a good hunk of hours today, and really didn’t get anywhere. All the pre-baked stuff I would do turned out awful looking, and the on screen ambient occlusion that is built into Unity was fuzzy and terrible looking. I’m going to have to look more into lighting. Right now the realtime lighting looks good enough, and I think once I get a AO solution it will be great.

Starting Work with Dynamic Lighting in Unity 5

Sun, 05 Jul 2015 20:36:43 +0000

I know I just posted earlier today but I got home and was itching to figure out the lighting in unity. I came across a method that is new to Unity 5 to simulate a day and night cycle and imported my little island I made a few days ago so I had something to work with, and it turned out better than I expected. The default settings are being used so I still need to tweak with the GI and AO, as well as the reflections on the shaders. But that’s all besides the point. The shadows look great in Unity 5 and I can’t wait to really dive into working with the lighting and ambient color to get that “awe” effect.

I guess you could call this an end of day 1 video:

Day Night Cycle Test

First Blender Render

Sun, 05 Jul 2015 20:34:17 +0000

With the official birth of this blog I’d like to show what I have worked on so far while teaching myself Blender. I’ve been following posts on /r/low_poly and love the art style, so I thought I’d give it a shot.

I hope to use this art style in upcoming projects I’m going to be working on. Right now there is no clear direction, I’m just trying to dive into something and see what unfolds. I plan to update this blog whenever I have milestones in my work and document my progress throughout my future projects.