Blog

The following relates some things that happened back the beginning of march between 07-08 March. And also the effects thereof a month later when I thought everything had been fixed.

The frivolity of software is not due to the fact that it might lack something. No it's due to the fact that software is becoming extremely complex.

Software has to work on a broad array of hardware architectures. On a broad array of operating systems working each on another architecture.

Linux is the best example of software that is robust

But what happens when software isn't robust? When there are new features added, when there are security issues which require a fix?
Then you issue an update!

And so our journey begins. An update can either break something or enhance something. Having enough trust in Linux systems for the past 10 years I can say that an update/upgrade rarely breaks the system.
If something goes wrong it's a minor point and you can usually fix it or it won't bother you too much.

I've trusted Debian, Ubuntu, Fedora and Linux Mint, each had a portion of my time.

This is more of a DevLog than a tutorial.

I've developed a system to do a Procedurally generated Map, but you could say that it's more or less a controlled Random Map Generation.
Before this could have been done I needed to import the JSON and convert it to Elixir Maps. Unfortunately detailing every little step seems to take too much so I'll refrainto the bare basics.

Although we won't use it too much in this tutorial , we will download the JSON database form cataclysm.
It's included in the download at the end of the post.

Our game world consists of multiple maps.
The current map is the one the user is located at.
Each map location or tile consists of a tinymap.
Each tinymap consists of 24x24 tiles.
Each tinymap tile is 0.5m by 0.5m.
Meaning that a tinymap is 24x0.5 = 12 meters in width and height.
The total size in square meters is 24x24 x (0.5*0.5) = 144 m2 which equates to quite a considerable size.

Our User module works great for the purpose it has been created.

However we need to to prepare for the future when we'll implement our NPC's and battle system.
We will also probably need to store other details in a "global" repository in memory.
Yes, ETS works great for this, however that's for a future date.

We can copy paste the user module and modify it each time we need to store data, but there is an easier and better way.

Creating another Module DataStorage on which our User extends.
This way our application will make calls to the DataStorage module

DataStorage module

the DataStorage module is responsible for handling all our data in a special process. We will then implement the user model on top of that.

To view ALL The code in the Fossil Respository for the 0x06 Modifications to State click here

I've deployed my first live system with Phoenix and Elixir. Since this was a mostly manual process, I need a way to analyze the access logs generated by nginx.

Google Analytics works great for those clients that have JavaScript enabled. But what about uses who don't? What about bots, cralwers, and requests to other files like CSS/JS?

Or what happens when there's someone like me and doesn't allow javascript by default or blocks certain domains?

I had planned to write a full extensive explanation on how to use doctests, test files and on how to implement testing with exdoc by using mix test

It's however come to my attention that there are already MANY places on the internet that already discuss this.

Since time is valuable I'd rather go ahead with the development.

You can view the changes that occured in 0x05 at the Life Beyond Apocalypse Fossil repository.

Download the full sourcecode here for 0x05 here

This is part of the Elixir Life Beyond Apocalypse Zombie Game creation tutorial.

Before we start coding we first need to think how do we handle and save our items?
Should we save them in a database, a flat file? Sqlite? In memory? Embedded in the code?
It depends. I've long opted and worked with SQL databases.
For our purpose we will save everything in a module variable in memory.
This will make everything easier since we don't need to go into details on how to work with SQL from Elixir right now.
Items the user has are stored in the items
Whenever we save the state of a user we can save it to a file.

Later we will refactor our code and save our data differently.

At the moment we will keep things short and easy. Items will not be stackable.
We won't make too many verifications for the sake of smplicity.
For example we won't verify if the user already has full health or energy.
These will be added later on.

I was back-up'ing my system and I reviewed everything after the stupid debian bug I've encountered.
I noticed that I had some 37 GB of video's from the 2nd semester of the CCCP study.
For 50 minutes of lecutre I had around 900 MB.
For a resolution of 1280x720 at 30 frames per second with 24bit color quality per pixel you would get a 30 GB file without any compression.
So clearly this is a 30:1 win and even the 900MB is a great compression if you stop to think about it since it was already compressed with the H264 codec.
I started to look around and test things with libtheora and ffmpeg I eventually got a 401 MB file.
For a aproximate bitrate of 1024K/s for the video the file size was roughly half. One problem I encountered with the libtheora was that it could not use all cores, which made it VERY SLOW.
Ok, i could convert all my videos at once, but that's pretty lousy. Not to mention the quality was reduced so theora wasn't an option.

This is part of the Elixir Life Beyond Apocalypse Zombie Game creation tutorial.

In the last tutorial(Elixir - 0x02 Command Line Fun - LBA Game) we created a command-line application.
Due to the immutability of Elixir and Erlang we had to pass the user structure map to every function.
However, passing the user struct form one function to another only makes things more complex and makes everything error prone.

Elixir has a solution for this.

Storing data in Elixir can be done by creating a new process and storing the data there.
We will be using spawn, send and receive for the whole thing.
Later on we will upgrade our codebase to use Agents.

Normally when we work with processes we always need to work with a PID. This means that whenever we want to send information to the process (to get back a response) we need to pass the pid.
This makes it again a little bit difficult since we would need to pass the pid instead of the user struct.
However thanks to Elixir we can name our processes! This can help us a lot.