In this section we will have short but powerful introduction to Blender. We will cover
just enough of model creation basics, you will need to create most of simple projects.
No, we will not cover animation, shaders or modificators here, but just enough minimum
to create this ramp floor for our tutorial:
You will find lot of keyboard shortcuts here. And this is one of the most awesome
features of Blender - you can work without menus or panels! Everything you need
can be done with keyboard!
So let’s dive in Blender now!
Have you ever heard about end-to-end testing? Or maybe about testing automation?
Those of you who had, may now be imaging Selenium. That’s right, in most of cases
you will need to run Selenium Server and use Selenium Webdriver in your
tests. Those come handy to run a standalone browser window, with no caches,
filled-in fields or cookies and perform some operations in it.
In this article I will tell you my story of writing E2E tests for Angular webapp.
A brief of history
In my case, we first tried to use Protractor with Chai.js. That time we ended
up with almost unsupportable bunch of code, succeeding in 100% of runs.
Next time we eliminated Chai and reworked all our tests to use Protractor only.
So the code became more clear (I did not like the syntax, but it worked…),
but after upgrading libraries (including Protractor), the ratio of successfull
test runs decreased to just 40%.
We worked for two days, trying to fix those tests. And that’s how webdriverio
came to our project.
And here’s a short tutorial on how to implement E2E tests with webdriverio in
a sample project.
These days I was given a reeeeally interesting homework at the university. I was given a set of
MD5 hashes, calculated from single words (taken from Libre Office’ dictionaries) with a given
sault. And the task was to find all those words.
So, the first idea which came to my mind was using an internet service for MD5 breaking. But…
aaarrrggghhh! There’s a sault, so the webservice, looking for words over a dictionary fails to
So the second idea was to take that dictionary from Libre Office and iterate through it. At the
end, it worked =) And worked reeeally fast. But that is not an interesting part.
I wandered if I could find those words in my dictionary, generated by my own code.
At my job we recently started researching logging tools to make our RESTful API, written in Clojure,
writing logs in JSON format. We were using Log4j already, but decided to use another tool for
this task, making it less painful. So we felt into timbre. Is seemed so easy to use, but it is
According to timbre’s API, we needed to define our own appender for writing to a custom JSON file.
And we found the
output-fn option to configure this behaviour. But it is not documented at all,
so we started looking for repositories, using timbre, examples and all the stuff. And finally,
we ended up with our own solution.
Underneath you will find description of our way to use timbre from scratch.
How do we usually create a web application? We run a bootstrapping script, which provides us with a skeleton of our application and then we just extend it with the features we need.
That’s exactly what we did at the last hackathon we were attending - we started with
rails new twf and spent half of the day integrating our blank app with Angular, Paperclip, creating API methods and so on. But the effort we needed to accomplish our goal (quite a simple web app) was really huge.
So I decided to find the best combination of backend and frontend technologies that would cause less pain.
At the project I was recently introduced to, the line between frontend and backend is distinguished very clearly: we have an API, written in Clojure and thin frontend application, made with Angular that works on a generated set of static assets - HTMLs, CSS and JS files (but under the hood we are using HAML and SCSS).
The application I will be implementing throughout the whole article has the same architecture: it has RESTful API and MVVM on the frontend, made with Angular. I welcome you to the journey of research and new technologies!
At my work we’ve lately been having a discussions on email validation. I recalled a post on
different options, including effective and psycho solutions.
At this point we have an application with
- 1x Ninja, walking around
- 1x sphere, hanging in the center of the screen
- 1x cube, flying around the sphere
That’s our “game”? Doubtely… So let’s make things move like in real world! Or just like that…
As we discussed, we will describe the whole game in scripts, and the core functionality
we will define in the core. In this chapter we will be adding Lua to our application.
You do not need to download Lua itself - you’d better install it with your system’s
package manager (
apt or whatever your Linux uses,
brew for OSX…).
First of all, you will definetely need the Irrlicht engine, so
go get it.
Now, you need to compile it. Compilation process depends on the operating system you use,
but it’s really similar everywhere.
Positive thinking is a good-to-have when starting something =)
Let’s talk a bit about our application before we create it - let’s make some planning! We will think of our
application at least as of well-designed one. So what is the application architecture? Not just a game, but
any application? It’s the way developer split its parts, divided classes, modules, variables, entities and other
pieces of application, packing them into separate units and defining how they will interact. So that any new
improvement or change to the application does not make one feel sick at the task definition stage.
But how about a game? What the good architecture of a game looks like? Do we need to separate one 3D models from
others? Or does that means writing each quest in a separate
*.cpp file? No-no-no. That means we should create
such an application, so that any new quest, model or even a text change will not require us to re-compile the
damn bunch of code for hours or look for a places, where that particular model or text is used and changing
it everywhere in the source code.
I assume our game to have a stable, rarely changed core, a set of assets (models, textures, sounds - any
content, made by artists and used to be presented to the player) and a bunch of scripts, defining all the
logic of a game - how character looks like, how the menus are shown and how they react to player’s actions, how
objects in the game world behave and how that world looks like and all the stuff. The main criteria here are:
- scripts and assets may be changed at any time
- scripts and assets define the whole game
- none of the changes to scripts or assets force us to re-compile game core
Basically, we can make the core so flexible, we may use it in any game. Or we may want to create a GUI editor
to create scripts in more handy way. But that requires much more work. And there is never a limit to make
something better. So currently we will not advance that much.