|An epic firefight in Red Eclipse!|
Also check out the development planet.
|An epic firefight in Red Eclipse!|
The Saab JA-37 ‘Viggen’ (the name goes back to an old Swedish word and means ‘thunderbolt’) is a Swedish single seat all-weather interceptor aircraft variant. With it’s delta wings and the canard surfaces, it is a most iconic sight, and when the first prototype of teh design was rolled out in 1967, it was considered one of the most advanced aircraft at the time.
The main design requirements were based on the notion that the aircraft would have to be operated from improvised airstrips, thus both the ability to utilize short (and, given Sweden’s climate, possibly frozen or snowy) runways and easy maintenance were considered very important. In fact, the ‘Viggen’ was constructed to cope with just 500 m of runway, yet to reach Mach 1 at sea level and Mach 2 at high altitude.
This is made possible by a powerful Volvo RM8 turbofan engine augmented with both an afterburner and a thrust reverser – the latter being fairly unique among fighter aircraft (only the Panavia Tornado is similarly equipped).
The aircraft simulated in Flightgear includes the JA-37 as well as the AJ-37 and the AJS-37 variants.
While the 3d cockpit is not the kind of photorealistic work to create an immediate ‘Wow!’, there’s also nothing jarring or severely amiss. Faithful to the original, all gauges on the main panel show metric units and many labels are in Swedish, but if Flightgear’s tooltip function is activated, just hovering with the mouse over a gauge explains in English what it is and provides the value in imperial units. The HUD can likewise be switched from metric to imperial units.
Away from the front panel, switches and warning lights are typically labeled in English to help the international user, and also the various audi-warnings produced by the aircraft are in English.
From the outside, the 3d model is rather compelling, and the plane comes with nice effects implemented – such as Mach shockwave and afterburner flame light illuminating the fuselage – in addition to lots of livery options.
The aircraft starts up with engines off, but if you want to get into the air quickly, there’s a quickstart function provided.
The ‘Viggen’ in flight
Once in the air, you can enjoy highly detailed flight dynamics. There’s tons of windtunnel and engine performance data worked into the FDM, including the behavior at very high alpha, so there’s realistic departure from controlled flight, including stalls and spins modeled.
The attention to detail shows, it’s one of the planes which just feel real. For instance, when approaching the transonic region or a high alpha regime, the plane starts to shake slightly.
Generally the ‘Viggen’ is easy to handle and one can quickly get the hang of flying the approach and landing. Faithful to the original, the plane can be brought onto the runway at fairly low alpha without a pronounced flare, and using the thrust reverser after touchdown is great fun.
Beware though – damage is modeled, and pulling too high g or smashing onto the runway will break the plane!
Most interaction of the pilot with the avionics is probably through the HUD. Generally, the plane tries to be helpful and allows the pilot to focus on flying. There are four main HUD modes (takeoff, flight, tactical and landing) and with the exception of the last, they switch automatically as needed.
The plane also automatically tries to tune into nearby ILS frequencies, so when you approach a runway equipped with ILS, not only the airport designation but also ILS symbology will magically appear.
There’s lots of other small details to discover in the way the HUD works and interfaces with other systems aboard.
With close to a hundred working switches in the cockpit, the pilot can go through fairly realistic startup and shutdown procedures. The ‘Viggen’ makes good use of the Flightgear checklist functionality, with the option to highlight the control that should be operated next, or to automatically complete an item.
As an added surprise, the state the airplane is in when starting up us somewhat randomized in that sometimes a switch may already be flicked, sometimes not – a good way to keep the user’s attention on the checklist!
You probably won’t find too many planes on the Flightgear repository which have the systems modeled down to a working air-condition unit – but there it is. If you allow the cabin air to get too cold or too warm, not only will you see on-screen messages that you’re getting uncomfortable, but also the canopy will frost or fog, impairing your view.
There’s lots of other things modeled, among them a well-tuned autopilot, automatic control of flaps, an electrical system in which you can drain the battery and will see lights dim in response and last but not least a full range of working weapons systems, ranging from the cannon to un-guided air-ground missiles.
If your definition of ‘realism’ in a flight simulator goes beyond photo-realistic 3d modeling and you can get excited about very detailed flight dynamics and systems modeling, the ‘Viggen’ is a plane for you, and you can well spend a few hours exploring all the little details that are lovingly worked into the simulation, from a large range of sounds via the simulation of different damage modes to the way the radar interacts with MP or AI planes and can get blocked by the terrain.
Well-implemented checklists and tooltips as well as the quickstart and shutdown functions make it easy to get used to operating the plane – give it a try!
With four people at equal score, the tournament will have a second phase for tie-breaking purposes (not really; it is mostly an excuse to play some more ). The second phase will consist of three games played in teams of 2v2, with teams changing every game, so that everyone will be teamed with everyone else once and against everyone else twice. Individual victories then will decide the winner. In case of tie, the tournament will have many ex-aequo winners.
All the games will be played on the archipelago sea map, and every player will have a different starting position every time. The three games are planned as such
|king of nowhere (blue)||WorldSavior (green)||vs||notabilis (yellow)||Sirver (red)|
|WorldSavior (blue)||notabilis (green)||vs||Sirver (yellow)||king of nowhere (red)|
|notabilis (blue)||king of nowhere (yellow)||vs||Sirver (green)||WorldSavior (red)|
The first game has been agreed for wednesday 18 january at 18:30 UTC.. As always, spectators are welcome. hopefully, putting the strongest players together in one of the most difficult maps will result in some very interesting games.
---- EDIT: the game must be rescheduled-----
(if some admin knows how to make writings in actual colors, he can change the names to display the color they will be playing or something like that and then remove this parhentesis)
With 2016 in the bag, I thought it would be fun to explore all the data that was recorded in the Xonotic world during the calendar year. For this I turned to XonStat’s underlying database XonStatDB. Armed with the Pandas and Matplotlib libraries for Python, some interesting visuals appeared!
First up, let’s look at the number of games throughout the year:
It’s interesting to see that the winter months hold the most amount of games! I wonder if this is because of the large amount of time off that folks get over the holidays. With new gifts of computers all around the world, what better way to test it out than with a few adrenaline-boosting games of Xon! Also worth noting is the solid representation of the three biggest game modes: capture the flag (CTF), deathmatch (DM), and duel. Although I didn’t break this chart down by the mods in play (e.g. insta), it is still good to know that we have reasonable variety.
Next, a question that I’ve always wanted to answer: what time of day and what day of the week is best for getting a game? A heatmap of the games played will help us answer that. Behold:
It comes as no surprise, but the evening hours are the best times to play games. That’s when just about everyone is off work or out of school. Your best chance is on Fridays at 8PM UTC. Note that these times are in UTC, so adjust to your time zone accordingly. I’d recommend World Time Buddy for keeping track.
Looking at the number of games is one thing, but what about the players who create those numbers? This next chart looks at the number of distinct players per month.
I’m not sure what to extrapolate from this one, but it comforts me to know that we don’t have any dramatic spikes in either direction. Instead we have a steady stream of players, with slight surges in the spring and winter months.
Next up we deal with weapons. Having all that weapon data sitting around in the database, I had to see what it looked like when plotted out! Were there any trends? Was any weapon predominant? Let’s have a look at the weapons data by damage dealt first.
I am rather surprised to see representation from all the various weapons in here (including some non-standard ones too, from modified servers). I was expecting larger blocks for the “core duel” weapons that we talk about in IRC often: mortar, devastator, and vortex. It’s good to know that people are getting usage out of all of them. Aside from the large block of blaster activity in May, things look - dare I say - balanced! Oops, that’s a trigger word. I’ll shut up with that one right now.
The number of frags dealt by all that damage is another lens through which we can look at weapon data. Here’s what that looks like:
Similar to the per-damage one above, this one also has a somewhat-even distribution. It’s slightly weighted towards some of the duel weapons I mentioned above with the exception of the crylink. Also, from this visualization it seems like people aren’t quite as comfortable finishing their victims with the electro or the hagar.
This concludes my data-tour of 2016. As it turns out, formulating these visualizations using new libraries takes a lot of time. While I could have opted to use something more familiar (like NVD3, which is used in stats), I enjoyed learning something new. I hope you’ve enjoyed the tour and all of the wonderful numbers and metrics it provided. I’ve placed the code that generated these charts on Github if you’re the coding type. If you’re not, I’ll see you out on the servers instead - we have 2017’s numbers to take care of!
|FreeOrion takes a while to get into, but is very fun once you get the hang of it.|
A new release is now available on GitHub, stable version 0.9.5. This version focuses on adding new content and experimental features. Downloads are available for Mac OS X, 64-bit Windows, and 32-bit Windows. Ubuntu Linux packages are available in a PPA, and a Debian Linux package is also available. For more details, see the changelog.
I’ve decided to document my experiments in random story generation, in the hope that these notes will be helpful to other developers and hobbyists. This first post will define some of the terms I’ll be using and introduce some of the theory.
My first idea for a random story generator came during a literary criticism class I took during university. We were learning about reader response criticism, which is a model that focuses on the interaction between reader and text. In RRC it doesn’t make sense to say that a text has an inherent meaning; instead, meaning is something that is actively constructed by the reader through the process of reading. The author of the text, and whatever they intended the text to mean, doesn’t enter into it. If we don’t need to worry about authorial intent, why bother with an author at all?
The next piece of the puzzle came from Scott McCloud’s explanation of closure in Understanding Comics. A comic consists of a sequence of separate images; the reader uses closure to combine these images into a coherent story. I realized that the same would apply to a series of short narrative arcs in a computer game. Even without intentional connections between the arcs, the player’s sense of closure would interpret them as a meaningful story.
Finally, Vladimir Propp’s narrative functions provided a way to arrange these arcs so that the reader/player would be likely to interpret them as a coherent story. Propp analyzed Russian folk tales and discovered that all of their plots could be constructed from a finite list of story events which always appear in the same order.
From all this I got the idea to create a big list of story fragments, then use some kind of algorithm to arrange them into reasonably intelligible sequences. Turns out that’s pretty much how all procedural story generators work, even today.
I named the smallest narrative chunk a Plot, which I will capitalize to differentiate from the regular use of the word. A Plot modifies the game world for as long as it is active; it might alter an NPC’s dialogue options, or add an encounter to the world map. In GearHead-1 the Plots are quite coarse, defining an entire mission or a chapter of the core story. In GearHead-2 the Plots are much smaller; a single combat mission might consist of four linked Plots- one for the NPC offering the mission, a separate Plot defining the mission’s combat encounter, a Plot that is activated if the PC wins the mission, and another that is activated if the PC loses. The Plots in Dungeon Monkey Eternal are even more finely grained.
Using lots of small Plots is much better than using few large Plots. First off, if a quest is composed of multiple Plots, it means that the player won’t know how it ends just because they’ve seen this beginning before. Second, it allows reuse of code, which is a huge advantage for both bug control and refactoring. Instead of every mission having to define its own combat encounter, they can just call for a standard combat encounter Plot. Third, it greatly increases the number of combinations your system can generate, and in general you want your random plot generator to be able to generate a really really big number of combinations.
There are numerous ways to arrange Plots, including Markov Chains and context free grammars. The important bit is to have some way to describe the context of a Plot, so that Plots which belong together get placed together. Next time I’ll describe how the GearHead-1 core story context system works. Let me know in the comments if you have any questions.
|This is a very old screen from Unknown Horizons, but I couldn't find a newer one right now.|
Hi, crawlers! Welcome – to the first changelog of 2017!
The SuperTux Team wishes you a happy and successful new year.
Since the release of SuperTux 0.5, we have received a lot of feedback on the editor, much of which has been very positive. Some of this feedback comes in the form of levels, some as feedback on IRC or in the forums. The team would like to thank you for voicing some of your thoughts and ideas, and encourage you to keep telling us what you think so that we can continue improving the game.
However, we also noticed several usability problems in the user interface. We want to ensure the level editor is easy to use for our players, so we wish to collect more detailed feedback in the form of a survey.
It would help the team out a lot if you could fill in the form here.
|Only one texture and one model of car was used|
|One of the next gen arena made with sculpting|