Two weeks ago took place the 0H Game Jam, in which everybody has to write a little game within the daylight saving time transition, an hour-long time frame which does not technically exist. This basically means building whatever one can in one hour or less!
Having taken a liking to small versus games on mobiles (I had a blast playing Bang with friends), I decided to have a crack at making such a game in a small time frame.
Behold, Versus Mini! A two-player, one-button shooting battle game made with Unity in just about an hour !
Here is a quick summary of the rules:
Each player controls his character from one side of the screen.
The goal is to have your opponent collide with any wall.
Tap your side of the screen to shoot. Shooting makes you change direction, but also knocks you back slightly.
Being hit knocks you back a significant amount.
The speed of the game increases gradually until it reaches a maximum or one player dies.
When a player dies, his opponent earns a point, and the game moves to the next round.
There is no score limit (mostly due to time constraint). Feel free to set one as you play!
The game is currently being made into a full-fledged project at the ENJMIN school of game development with a team of four people. New graphics and full network support are on the menu! We are also looking into other forms of motion controls. Kinect-less footage can be found here.
With Fish is a small asynchronous multiplayer game developed for the Three Thing Game Jam 2012 at The University of Hull.
In a peaceful aquarium, a Mr and Mrs Anglerfish are enjoying the good life. That is, until their owner decides to bring them some new friends to play with. Enter the goldfishes, whose sole reason to live is to make the couple’s life a misery.
One player controlling the two angler fishes using Kinect will have to face the invasion of goldfishes, each being controlled by another player on a touch device.
The aim for the goldfishes to enrage (ie, hit, startle, annoy) the anglerfishes until they -literally- explode. The only way for the Kinect player to win the game is to eat them all before this happens.
With various hazards layered amongst the aquarium (notably changing water level and hiding spots), the game turns into a fast paced pursuit as the many players taunt and manipulate the one player on kinect.
As the one of you who reads this has probably noticed by now, I have not really posted much new content recently. This is mostly due to the astronomical amount of coursework and applications I am currently going through.
There is, however, something I found through gamasutra. Something I really, really loved reading, which I will probably print and pin on a wall.
This is the No Twinkie Database. Ernest W. Adams, a game design lecturer at GDC (and founder of the International Game Developers Association) compiled through his years what he found to be game design faults into a simple, easy to browse list. It is both extremely instructive and entertaining to read. If you are into game design, you should definitely read it, then frame it or something.
Before an angry mob storms my house armed with torches, rakes and stakes, I would like to make something clear. I adore Electronic Symphony. It is the game I played the most on my Vita, and rarely has a game given me such a blissful feel of sensory overload. Now that this is out of the way…
In Lumines : ES, your “avatar” (the character dancing at the bottom left of the screen) has a purpose. Activate it, and it uses its special power, which will benefit the player by adding some random blocks, shuffling the board or other effects. After use, this power needs to be recharged to 100% through the player’s combo bonuses. It is a lengthy process, as one combo adds 1% to the gage. This amounts to approximately 1% every five/ten seconds for a player with average skills.
However, the player can simply tap the back touchscreen to add the very same percentage to the gage. The tap is not limited in time. In other words, there is no latency or time to wait before tapping the touchpad again. Therefore, an average player could fill the entire power gage in less than thirty seconds.
Lumines: ES is a high-score based game. I personally play it to relax, but one could expect that high scores (and the way they are integrated with PSN friends) are what keeps some players coming back, to beat their friends’ high scores and reach the top of the leaderboard. This friend leaderboard is displayed on the main menu, from the moment you start the game.
What ties the flaws together is the simple fact that avatar power influences your score. It can get the player out of a lot of tricky situations, or multiply his/her combo, leading to an increased score. The fact that tapping is a very effective method of regenerating the power turns it from simple tool to necessity. Players aiming to reach world leaderboards, or just to impress their friends, will most certainly need to tap the back of the console maniacally to refill the power gage as fast as possible.
The ergonomy is worth mentioning. Curving your fingers around the system for repeated taps will loosen your grip and make the system’s face buttons much harder to reach. The best answer to this, I suppose, is having a friend sit next to you to take care of the relentless tapping.
Summing things up… The mechanic is physically inconvenient and can be subverted. It is imbalanced. It has a great influence on the final score, forcing the subversion on all players who would desire to climb up leaderboards.
One could guess that this feature was shoehorned into the game at the very last minute, following Sony’s request to make the most out of the Vita’s capabilities.
However, it may not be such a problem for hardcore Lumines veterans who grew on all the game’s iterations without the need for powers (only introduced in ES). Touching the avatar is a very short process, but that can cost some precious hundredths of second to very quick fingers at the fastest game speeds. This is why the most advanced players might ignore the tapping altogether, as it may prove detrimental to their style of play.
Waiting for Players (pending title) is a multiplayer survival horror game developed in 48 hours using the Unity engine. It was submitted as part as 2013’s Global Game Jam Humberside, and earned first prize.
Our team was composed of Louis Deane, Daniel Endersby, Ryan Hollands, Duncan Mulholland, Don Holland, Jack Wood and myself. That’s a lot of Hollands.
Players are thrown into what appears to be a dark mansion. One of them becomes an invisible presence, tasked with eliminating the other players. To do so, the presence must maintain eye contact with the survivors until they faint. The game stops when all survivors are dead, or when the last person alive makes his/her escape.
The survivors, on the other hand, posess the ability to sense the presence’s heartbeat. The louder, the closer. The speed of the beats can also indicate the pace of the ghost’s movement. A very slow beat will indicate that the presence is sitting idle, waiting for prey. On the other hand, it will most certainly be running if the heartbeat is fast paced.
The survivor’s vision becomes increasingly twisted the more their health diminishes.
When the presence is staring at a survivor, a screeching music is played, alarming the survivor of the threat without revealing its position.
Several other cues can be used by the survivors to locate the presence, such as decorations falling when the presence brushes past them.
A ball of light is located somewhere within the mansion. It sticks to any surface it is being thrown at, and allows the carrier to slow down and reveal the presence.
The last two features, although implemented in a local version of the game, were not implemented for network play due to time constraints.
Or, “How to access the bytecode of a vertex shader in a compiled DirectX Effect file?”
Earlier in the year, looking into symplifying the use of my DirectX library, I have been pointed to a tutorial by Bobby Anguelov, which described in detail how to load your own InputLayout for a shader by using reflection. InputLayouts are usually difficult to implement coherently, without having to hard code them to match each individual shader in the application.
But what this code allows you to do is, in a nutshell, to read the compiled shader bytecode to obtain the input information of the vertex shader. Based on this information, you can automatically set up a suitable InputLayout to bind to the shader.
This tutorial is indeed very useful, except that my library uses the Effects framework (which Microsoft had the grace of deprecating – FABULOUS!). The Effects framework provides its own implementation of reflection, but nonetheless the process of accessing the shader input is the same as in the tutorial above, using an instance of ID3D11ShaderReflection.
However, what changes is how we obtain the shader bytecode, to create said instance. We need to access it through the framework’s own reflection, by obtaining the description of the pass within the technique we want to build the layout for. From the pass description, we can then obtain the Vertex Shader description, which will provide us with the desired ShaderEffectVariable. Using the ShaderEffectVariable, we create the shader’s description, which contains the shader’s bytecode!
Here is a snippet which creates an ID3D11ShaderReflection instance from Pass 0 of Technique 0 of an effect. It is probably a lot more demonstrative.
Here it is, the “seasonal island in the globe”. You can see it motion in this video, accompanied by the cheesiest music I had on the top of my mind. I don’t even know why, I’m not even a Final Fantasy fan.
The main (and personal) features include:
Entity parenting and transform stacking.
Geometry shader particles, with mesh-based generation. Low-poly meshes are used to generate particles, per around certain areas.
Multi-pass lighting and shadowing.
Mesh reflection (work still in progress).
My initial consideration was a component-based architecture, which I later traded for a more standard, hierarchy-based structure, as many people convinced me it was just overkill. Truth be told, even without a proper composite pattern, the end result is probably just as much. One feature I dreamt of having was soft particles, but sadly I had to prioritize other aspects for the deadline.
The island follows the cycle of the four seasons, having respectively:
Leaves growing in spring.
The tree burning in summer.
Thick mist masking the island in autumn.
Water freezing in winter.
A dynamic, directional light used to simulate the sun.
Four (optional) spotlights, which show off the multi-pass shadows-lights.
I just had one of these moments. One of these moments when you think about something, try it out, and it just works. Happy.
As most of you probably know, Okami is one beautiful game, and despite being something else, is one of the late PS2’s finest gems.
If, on the other hand, you do not know Okami, here is a quick refresher.
There are big, dark outlines, billboards, all of it combined with textures which describe their elements using the same black outlines. Adding a few screen-space effects to make the outlines more organic in motion, and you get a jaw-droppingly pretty game.
I recently bought (and played around ten hours) the HD re-release, and I am having a delightful time. But with crisper visuals, some smaller details become more apparent, some small details start being noticeable.
..and this is how I notice Okami’s method of cell-shading. During the PS2 days, there were no shaders, and while there would still be ways to internally displace vertices, there was no such thing as a pixel shader.
Okami’s method of outlining is clever by its simplicity. As I twisted the camera to some angles, I noticed that the large outlines you can see on the cliffs and landscape elements would distort. It is because they are in fact drawn twice. Once as the normal, textured model is drawn, another model, slightly larger, with a fixed colour (in this case, black), is drawn on top of it, with culling faces inversed. What you are seeing as an outline is in fact the inside of another model painted black.
After being intensely in love with this game for many years, this realisation came like a M. Shyamalan plot twist.
But wait, you might ask, pretending to care. Wouldn’t this be very easy to do with shaders?Exactly, and I had a little play with DirectX.
As you can probably see in the video, this method causes some visual artefacts when geometry intersects (see below). I cannot think yet of any efficient way around the problem, however it is only a small price to pay for such satisfying results obtained without influence of the pixel shader.
However, it is still possible to observe the same kind of artefact in the game itself, when looking at the models carefully.
But these types of artefacts are not clearly visible in the game, and you would have to pay a lot of attention to spot them. Exception goes to the landscape elements (such as rocks) which do have to intersect with the ground, thus revealing the outlines.
Another thing you might notice from this screenshot is that the outlines are not regular, like in the teapot shader. In fact, in most character models, they are far from being regular. For instance, on Amaterasu’s model, the ear and the stomach outlines are much more prevalent. This goes to show that instead of using vertex displacement for the characters, the team behind Okami might have created its own outline models. It implies more work on modelling, but on the other hand, more artistic liberty in how the outlines look. Namely, the ability to make them larger to emphasize certain parts of a character, or smaller, to hide possible artefacts.
Here is the shader code to render the outlines using a vertex shader. I intentionally left out the texture rendering pass to save some space.
Now, many things remain for the render to look really Okami-like, such as distortion of the outline (the outlines are distorted in motion), and screen-space effects, which I hope I will have time to cover at some later time.
This particularly long title stands for a game I developed in my first year for the Imagine Cup.
The game is a side-scrolling shooter featuring a combo mechanic and some mild RPG elements. The player controls a flying recycle bit, exhibiting a proud mustache. Various enemy types will storm from the right, and the player will have to destroy them. When an enemy gets blown into smithereens, it may drop some garbage which the player needs to properly recycle.
The twist is, the player actually controls three separate bins (although just one at once), each with its own unique type of shots. The keys QWE allow to dynamically switch bit and shoot with it.
Collecting garbage with the appropriate type of bin will increase the bin’s experience level, as well as the combo meter. When the experience bar is full, the bin levels up, and its shots become more powerful and varied.
If a bin ever gets hit by enemy fire, it will be incapacitated for a certain period of time, and the combo meter is reset. There is no game over, but this holds an impact on the final score.
At the end of the game, the player gets issued badges for his achievements, based on his score and damage received. One objective of the game is to obtain all badges for all levels.