Demo just got updated, download and play it:
- Fixed bug causing Gravity Inverter particles not being correctly rotated when resetting the stage.
- Changed scenes ambient music to be streamed from file instead of storing the whole music in memory.
- Added support for Ogre 1.8.1.
- Added Dash sound effect.
- Fixed bug causing hands to be put down when not being able to use a power.
- Added an intro video related to the plot (yes, Vitrum does have a plot).
- Added Shield sound effect.
- Fixed bug causing character to keep it’s mommentum after dying.
- Added Gravity Inversion sound effect.
- Fixed some issues with the Dash mechanics.
- Fixed bug causing horizontal doors (trapdoors) not activating objects when opening.
- Fixed music allocation issue.
- Added options to invert mouse axes.
- Fixed bug where bad sound streams coming from audiere were causing sudden crashes.
- Started streaming from file some bigger sounds instead of loading it in RAM.
- Changed components destruction to properly destroy its sound source and sound streams.
- Fixed bug in the kinematic character controller causing the character to stop falling when running against a wall (while in air).
- Changed default volume of sound streams attached to a source from maximum to minimum value.
- Modeled and painted a whole pack of assets (pipes, junctions, etc) in order to enrich and detail each stage.
- Modeled and painted an asset to start the game in (capsule designed to store and transport the android).
- Added pipes to the stages.
- Added starting capsule asset to the first stage.
- Fixed some minor lighting issues in a few stages.
- Properly balanced the difficulty evolution by re-ordering the stages.
- Ajusted the difficulty of the stages (lowered the difficulty of some and raised in others).
- Changed some puzzles to be more intuitive.
- Added more checkpoints.
- Repositioned some crystal shards making the activity of looking for and getting them more satisfying.
We collected a lot of good feedbacks from Steam’s Greenlight and did everything in the changelog below. We’ll keep collecting feedbacks and improving Vitrum.
- Added user pointer to components to optimize queries for objects using collision objects (performance).
- Improved collision sound effects handler (performance).
- Improved volume calculator when considering barriers between listener and sound source (performance).
- Improved contact trigger queries (performance).
- Improved laser weapon calculation of laser direction (performance).
- Fixed box position relative to screen when holding it.
- Added support to bullet 1.51.
- Added anisotropic filtering to graphics options.
- Changed android’s hands to be kept down when holding no powers.
- Added different sound effects when moving while crouched (slower footsteps rate).
- Added smoothed android movement (more natural motion).
- Added more points to the mouse sensibility slider.
- Changed anisotropic filtering 0x to actually work as a trilinear filter.
- Fixed master volume calculation (now using a natural exponential function).
- Fixed lighting bugs in every stage.
- Fixed assets positions.
- Adjusted stages difficulties.
- Repainted tunnel door’s frame.
- Repainted tunnel ceiling.
- Repainted tunnel floor.
- Modeled and painted tutorial asset.
- Added holographic screen shader to use in the tutorial asset.
- Added tutorial assets through the game.
Hello everyone, I will try to produce a couple of videos per week to show the Level Design of the stages.
The stage from the video is the number 25 and there will be 25 more to come… the stage name for now is: “Stairway to Hell”.
Have a nice day.
This post is dedicated to those who want to develop their own game, and it’ll be about project management. Basically, I’ll explain how we organized Vitrum’s development.
The first thing we’ve done was to think about how the game would be, and for this, we’ve defined some characteristics, such as:
- first person view;
- powers exploring physics engine features;
- game based on challenges, which consists in discovering how to beat each stage;
After that, we’ve defined which would be the general tasks to be done, for instance:
- develop powers’ physics;
- model and animate the assets;
- model and animate the character;
- create the stages;
- configure the stages;
- create the interface;
- develop the interface logic;
Next, we have defined a few auxiliary tables, with more detailed tasks that fit in the general tasks. The important thing here is that the duration of these tasks should not exceed one week. So, if we take for instance, the tasks regarding modelling and animation, the auxiliary table would be something like this:
- model the character;
- texturize the character;
- create character’s idle animation;
- create character’s walking animation;
- model the wall;
- texturize the wall;
After that, we’ve been following an agile and flexible production process, which consists in delivering weekly tasks, and doing meetings every week, at the same day and hour, in order to discuss at least these topics:
- check the evolution of the previous week tasks;
- estimate tasks for each person, to be developed in the next week;
- discuss technical subjects regarding the game (which color should be the X power? how much should be the duration of the Y power? how could we improve the design of the Z asset?);
- discuss any other topic regarding the company/game;
We are following this production scheme since november 2011, and it’s working good! In 6 months we managed to go from nothing to have finished at least 70% of Vitrum. The main hint here is to never let the team lose the pace, and this require every person involved! It’s always necessary that someone do the role of raising the morale and keeping things happening.
Feel free to ask questions, give suggestions and comment.
In this post I want to open our development box and show some of our tools and libraries. I really don’t want to start any unfruitful discussion about which is the best code editor, compiler or version control system, so I’ll just state what we use and I’ll move on…haters gonna hate!
Now the interesting part, Vitrum is being made with our own game engine. This game engine was built using Ogre3D (an excellent open-source graphics rendering engine) and Bullet Physics (a very fast and stable open-source physics library). And basically, the decision to build our own game engine using only free libraries allowed us to make a game from scratch without spending a single cent.
And aside of Ogre3D and Bullet, we also use the Boost Libraries, which are a pack of excellent C++ libraries. In my humble opinion, every C++ programmer should know Boost and try to keep up with its updates. And a good reason for that is that it’s made by the C++ grandmasters out there, so you’re getting the absolute best of the language for free.
I think that’s it for today, stay tuned for more posts about programming.
Hello gamers around the world!
My name is Daniel, I’m a the third member of the 9heads game studios. I work as a 3D artist and animator on the Vitrum project.
I have been working on different projects of games and other stuff for a few years, and now, Vitrum and 9heads are my main goal.
During the development of this project I’ll be posting a lot of information regarding Vitrum and the development process that we have built. I hope that this kind of communication with the gamer community can benefit us as well as it can benefit you guys who seek to initiate your own project.
We have the idea to create some timelapse videos to show some of our assets creation workflow, so if you find that’s interesting, please let us know!
Feel free to ask question about Vitrum and 9heads.
See you guys!
Hello everyone, my name is Henrique, Game and Level Designer of Vitrum. Graduated in Digital Games and currently working in a video game developer and publish company.
I don’t have experience as a developer in a company, but I did it a lot in my college and at home, I want to do this game very nice to play and very challenging and will keep working on it.