Unit balancing methodology

Game Designer saying: “when someone tells you that there is a problem in your design, 90% of the time he’s right. When he points out what you need to change to fix it, 90% of the time he’s wrong.”

In this first blog post about Game Design, we have chosen to focus on units balancing, a fundamental condition in real-time strategy game viability.
Balancing requires to identify with precision the cause and solution to a problem detected during a test session. Keep in mind that neither the cause nor the solution to a given problem are obvious, and the important thing is to always keep an overall view of the balance of the game when making an adjustment.

In order not to bring a disaster and make the game unplayable for a time, it’s important to keep some essential points in mind. Of course, since the following examples are directly taken from Win That War!, you’ll have to make some adjustments.

logo win that war

Balancing rules

  1. Always read the specs (specifications) of the units that are directly or indirectly related to a change. Remember the role of this unit in the strategic and economic balance of the game.
  2. There is always two sides to a deficiency or an excess in a stat (a parameter). Either the stats of this unit is too high, or the stat (of this unit or its opposite) which counterbalances it is too low. It’s essential to consider which side of the issue needs to be improved, all the while preserving the original intent of the gameplay dynamic and, above all, minimizing the imbalance caused on the game economy. Most of the time, this means picking the solution that would have the least possible impact on the rest of the system.
  3. Preserving the rewarding aspect of the use of an unit: its specificity, its imbalance in some particular situations (regulated and counterbalanced by other local imbalances in the other units’ stats and mechanics), its role in the economy and the possible strategy of a player, or rather the possible strategies.
  4. Finally, keeping an eye on the possible upcoming upgrades that would affect this unit: don’t nullify or OP-ify (Over-Power-ify. Don’t make it too strong) an upgrade when you affect a stat that might be subject to possible improvements for one of the factions. Some units are bound to be much more useful in a build of a particular faction. This is normal and advisable.

 

Case study – Units balancing in a RTS

Example: We find out that Bombers are way too weak compared to the AirKnocker, which devalues the use of surprise air-ground tactics and late game air-rush.

 

The question is: how to make this unit less efficient in this specific case, without going against the concept of use of this very unit, or any other one?

Here are some of the possible choices, as well as their impact on the game:

  • Changes such as improving the attack stats of the Bomber against the armor of the AirKnocker, making the Bomber harder to target or increasing the range of its bombs seem to be the best options at first sight, but would have a destabilizing impact on all air-ground fighting situations. These three options are then excluded.
  • Nerfing (reducing) the armor of the AirKnocker makes it more vulnerable to all ground units, which would be very frustrating since this unit is quite expensive and takes time to be produced. Moreover, this change would only take effect when the attacking player has a compo allowing him to reach AirKnockers through more powerful lines of units, which is the usual function of this unit. This means that the effective impact on the problem will be lower than the imbalance felt by the player as he watches his units get destroyed in one shot. That’s not a good idea, so this option is also excluded.
  • Increasing the price of the AirKnocker (as well as its required production time) to justify its power by its cost would make it a powerful and high-value unit to the player, which counterbalances its light armor and its visual appearance. Moreover, being the only anti-air specialized unit, it needs to be accessible, as beginner players would otherwise feel helpless when faced with air tactics. Well, we’ll exclude this one too.
  • Reducing the range or the fighting stats of the AirKnocker could be the solution, while keeping in mind the preservation of its specific role, its tactical viability and its difference compared with the use of anti-air turrets. A small change in several stats can subtly remove the problem by giving the unit a slightly awkward feeling. A medium or low cost unit shouldn’t have an “ace”, capable of anything kind of feeling, and making it less reactive while preserving its specialty is a very good option.

screenshot001

In most cases, (after a number of iterations), the existing balance of the stats of a given unit is correct and matches its role, and simultaneously scaling several stats by a small factor is enough to fix a defect or an excess of power.
As a general tip: Do not cancel what makes the unit special and fun, but rather work on related factors that reinforce its strengths and weaknesses while remaining consistent. Eg. making it easier or harder to use a feature.

In the case of the AirKnocker, the range, the acceleration and the tracking speed were the three main factors we had to tweak to solve its relation problem with the Bomber, while maintaining the overall balance.

Since we don’t want you to get bored with Game Design, we’ll keep the topic of economic balance for another blog post.

Switching Win That War! to the Entity-Component-System Pattern

This post describes the switch of our gameplay codebase from a class hierarchy to an architecture based on the Entity-Component-System pattern (ECS). It will first explain why we undertook this refactoring and then present the new ECS framework with which we are currently developing Win That War!. The description is accompanied by some code samples as this post is voluntarily geared towards readers who are curious about the technical details of such an implementation.

The old ways

The Win That War! team is growing and the scope of the game has evolved towards a richer design than originally planned. Concretely, this means that we now need to support new game mechanics as well as new units with some unanticipated characteristics.

Some months ago, at the core of Win That War!‘s code was your typical class hierarchy. A base GameObject implemented all the shared behavior. Additional sub-classing then progressively added new functionalities to create specialized types (Fig. 1). This was all fine and dandy, until our game designer got loose and imagined fancy units such as the Command Unit. Here is an excerpt from its specifications:

The command unit is both a building and a unit that materializes the player’s presence on the game map. The player’s buildings can only operate within the range of a Command Unit and its destruction triggers the player’s defeat.

In other words, this unit must be able to anchor itself on the ground, like a building, but also to take off in order to establish new bases on any other point of the map. Behold the first flaw of the class tree, the dreaded diamond: due to the tree-like nature of our architecture, we got to a point where it was impossible to share antagonist behaviors such as being both a static building and a mobile unit.

ecs-tree

Fig. 1 — Simplified representation of the initial architecture. The new Command Unit does not fit in this hierarchy.

At this point, we had two options. Option 1 was to go deeper into the rabbit hole and create a new subclass of GameObject (imagine a StaticButSometimesMobile class alongside Mobile and Static). Option 2 was to think ahead and switch to a more flexible architecture. Given the loads of other units and mechanics that are planned, it became obvious that we really needed to look at alternatives. After some consideration, we chose the Entity-Component-System pattern.

In the meantime, we settled for a quick hack: two versions of the Command Unit were coded, a mobile one and a static one, and we swapped them when landing/taking off. Let’s just say that we were only moderately satisfied with this approach. Some code had to be duplicated and having this very specific swapping logic for a single  type of unit did not sit well with us.

Composition over inheritance

The Entity-Component-System pattern is an alternative to the canonical class hierarchy. The three ingredient of the ECS recipe are:

  • Entities: the concrete instances of our game objects. For example, units, buildings, decor elements and cameras can all be entities. Conceptually, an entity can be seen as a bag of components.
  • Components: the pieces of data that represent specific aspects of the entity that they belong to. For example, position, physics parameters, 3D models and health could all be components. It is the aggregation of components that defines the nature of an entity. We call this set of components the entity’s composition. A strong characteristic of the ECS pattern is that components should only contain data and no logic.
  • Systems: the modules that govern the logic of specific parts of the game by manipulating related components (Fig. 2). For example, a Drawing system could examine the Position and Model components of entities in order to render them. A Physics system could examine Velocity components to mutate Position components. Another strong characteristic of the ECS pattern is that all the game logic should reside in systems and that systems are responsible for the interaction between components.
ecs-data-logic

Fig. 2 — Entities (Top) can be seen as “bags of components”. Systems (Bottom) update them. There is a clean separation between data and logic.

ECS is a component-based pattern with a strict separation of data and logic. The Unity game engine often comes into the discussion when speaking of components. However, the vanilla Unity approach is looser in its definition: a component (MonoBehaviour) contains both the data and the logic. Some libraries do provide an ECS layer for Unity, such as Entitas.

Here are the benefits that we expect from ECS:

  • Flexibility: it will be trivial to dynamically alter the nature of our entities. Want to temporarily buff a unit? Simply change the data in the appropriate component or swap it with another component altogether. Similarly, systems can be enabled/disabled at runtime, which is extremely useful to un-complexify the game for testing/debugging or to reproduce Minimal Working Examples.
  • Data-driven: because ECS is so strict about the separation of data and logic, we should naturally end up with a more data-oriented application. Hence, it will be more straightforward to deserialize our on-disk game data (authored by the game designer) into game entities. Similarly, it will be easier to sync this data over the network without resorting to an intermediary form.
While it was not the reason for this refactoring, ECS is also known to be performance-friendly because the underlying data structures are often layout in a way that corresponds to their processing. That is, same-type components that are processed sequentially by logic systems are contiguous in memory. Thus, the CPU cache is happy.

Practicalities

The new architecture had to mesh well with most of the code that was already in place. To this end, we designed the central data store for entities and components (the Entity Manager) to expose them in different forms to the “legacy” code and to the “new” code (which will reside in Systems).

The gist of it is that the legacy code uses stand-alone Entities with a similar API as the old stand-alone GameObjects. However, the new ECS systems leverage a more sophisticated approach in which they process views on entities that match certain compositions (each system has it own criteria).

Fig. 3 gives an overview of this architecture. Each part will be discussed in the following sections.

Fig 3 -- TODO

Fig 3 — Our ECS architecture. The game data is exposed to the “new” code and to the “legacy” code in different forms.

Components

We use an interface to mark a class as being a component. Notice that there is no internal references to the entity that owns the component. This is a voluntary design choice: not exposing the owner forbids indelicate programmers to access unrelated data (eg. myTransform.Owner.AnUnrelatedComponent). Even more importantly, not exposing the owner prevents to add any logic to the components that could mutate them from the inside, since their context of execution (the “neighbor components”) is unknown. The way in which logic systems do access this context in order to make components interact will be discussed in a further section.

EntityManager

The entity manager contains the meat of our implementation. It has the following roles:

  1. Managing the entities lifetime. Users have control over the creation and destruction of entities. On creation, an entity is given a unique ID by the manager. Under the hood, entities are stored in a map in which they are indexed by this ID.
  2. Composing entities. Users can create, destroy, and query components. Components are stored in a matrix-like structure where rows correspond to the various types of components, and columns correspond to entities. Querying component X of entity Y is a matter of looking at element (X, Y) in this map. Tab. 1 illustrates the kind of data that can be found inside the matrix if you were to inspect its content (this article provides a nice illustration of this layout).
  3. Categorizing entities with respect to their composition. The last job of the manager is to keep track of which entities match a set of user-defined compositions. In this way, logic systems can process only a subset of the existing entities and only consider components that are consistent with their work. This mechanics is detailed in the Logic Systems section.
Tab. 1 — The game data is stored in a matrix-like structure that associates component types and entity IDs. Rows correspond to component types. Columns correspond to individual entities. Changing the composition of an entity simply consists in filling its slots with other components.
ENTITIES
#1
(tank)
#2
(resource)
#3
(decor element)
#4
(factory)
COMPONENTS Transform
  • x: 0
  • y: 5
  • z: 1
  • x: 0
  • y: 0
  • z: 3
  • x: 0
  • y: 0
  • z: 5
  • x: 3
  • y: 10
  • z: 10
RigidBody
  • type: dynamic,
  • mass: 1000
  • type: static
  • type: static
Model
  • name: "tank"
  • name: "crystal"
  •  name: "tiny_rock"
  • name: "factory"
Weapon
  • effect: "laser"
  • dmg: "5"

This structure is a good illustration of the flexibility provided by ECS. It really favors experimentation and quick iteration because, once all our components are defined, we can design entities with novel behaviors in a pinch. For instance, it’s trivial to weaponize a factory (give a Weapon component to #4) or to make some decor elements interactive (switch the RigidBody of #2 from static to dynamic) so that players can play with them.

Entity

An IEntity instance exposes methods for mutating and inspecting a specific game entity. In practice, this interface is mostly used by legacy code that has not been converted to ECS. Because its usage closely resembles that of the previous architecture (a stand-alone GameObject held all the data of a single unit/building/game thingy), we kept a similar API, which significantly reduced the amount of code rewrite.

Manipulating entities is straightforward:

The concrete Entity class that we use acts as a facade for the EntityManager. It also adds a layer of cache in order to reduce queries for the most used components, plus game-related metadata that we had to keep for legacy reasons.

Logic Systems

The last part of the architecture deals with the logic systems that update the entities’ components and run the game simulation. Let’s start by looking at the type of code that we wanted to avoid writing:

We did not want to iterate blindly through all entities (there could be thousands), filtering them away with some predicate, only to process a fraction of them. Instead, we needed a way for each system to express which types of entities it is interested in ahead of time, so that it would only process those.

This mechanics is made possible by the formulation of compositions. A composition is a user-defined class with a number of fields of type IComponent, as well as a reference to an entity that possesses said components.

A composition instance, or node, can be seen as a view on an entity, exposing only components of interest. Their creation is handled by the entity manager who is already responsible for mutating the entities and thus provides the best place to also inspect them when a change in composition happens. Basically, for each existing composition type TComposition,  the manager has an internal collection CompositionNodes<TComposition> containing one node for each entity that matches TComposition (see code sample below).

The logic systems can access those node collections via the EntityManager.GetNodes<TComposition>() method that was seen previously. They can also subscribe to two events: OnNodeCreated(node) and OnNodeDestroyed(node). The collection raises OnNodeCreated when an entity matches the composition and it raises OnNodeRemoved when an entity does not match it anymore. In this way, systems do not need to consider an entity during its whole lifetime, but only when the entity’s composition is relevant to its work.

Here is an example of a physics system written with this strategy.

In this example, the system reacts to new entities having both a Transform and a RigidBody, and it manipulates nodes exposing only those two components. A benefit of this approach is that a programmer does not need to know the inner workings of our ECS implementation by heart to write new systems. The entity manager does all the bookkeeping by tracking which entities match which compositions, and systems just have to listen to the events that it raises.

This notion of expressing subsets of entities to work on can be found in other forms in established ECS libraries. For instance, Artemis-odb lets users formulate aspects and the Ash framework lets users define nodes in a way similar to ours.

Results

After spending several months coding gameplay within this new architecture based on ECS, some conclusions can be drawn.

  • Unavoidably, refactoring a sizable codebase such as Win That War!‘s was several week’s work. Switching to this new “philosophy” also required a bit of getting used to from everyone in the team. So, all in all, the move to ECS took a bite in our schedule. However, the promise of ECS is to make up for this lost time with greater speed and flexibility during the rest of the development. It seems that ECS is already paying dividends as we now iterate more quickly on new features.
  • We had to make some compromises during the switch to ECS and chose to convert specific parts of the codebase in priority. Some aspects of the game logic still adhere to the old ways of doing things and will probably not be updated due to lack of time. And this is fine, because these parts interface well with the Entity facade that we described. In any case, the code that has been converted — as well as new code — feels cleaner. It’s just simpler to write clear, explicit code, and a lot of complex use cases just seem to sort themselves out naturally.
  • Finally, the ECS favors isolation, which is precious for testing/debugging purposes. For instance, we obviously don’t want to pull all of the game rules in our unit tests and some game mechanics that would be constraining in this context (eg. the need to be close a relay for a unit to be active) can be trivially disabled by turning off the systems that handle them.
Screenshot of Win That War! with the components of several in-game entities

Fig. 4 — Some components actually used in Win That War! for different units.

To conclude, switching Win That War! to the Entity-Component-System pattern required a significative amount of work but we are already reaping some benefits. The gameplay code is more modular since various aspects of the game are now neatly decoupled from each other. Most importantly the game code feels clearer and gives us a better sense of control. For the curious, Fig. 4 shows a screenshot of Win That War! with some of the components that are actually used under the hood.

About this Command Unit trick that we had to resort to (the building version sneakily swapped for the mobile version): now we just give our unit a Building component when it lands. When the unit takes off, we replace the Building with a Motion component and all is well in the ECS world!

References

New gameplay mechanics.

If you subscribed to our mailing list or if you were at Stunfest 2016, you might have tested our 0.3.4 pre-alpha demo in which you’ve seen new gameplay mechanics. How about a quick rundown?

3 command units

When starting a game, you now have to choose one out of three different command units that will influence your early-game strategy. Their typical use in a team game is highly complementary and allows for smart choices and specialization.

 

Excavator - Sentinel - OUtpost      
Excavator – Sentinel – Outpost

 

The Sentinel is a powerful battle station with a deadly laser turret and heavy armor. Its firepower is sufficient to hold off a small army and defend its base. However, it moves slowly and has a smaller control zone compared to other command centers.

 

The Excavator has advanced mining capabilities: it is able to forage for Sharp Crystal hidden deep underground. Using an Excavator enables production and base development right from the start of a game, even in sectors that lack sufficient resource supply.

 

The Outpost allows for the most versatile base development tactics. It can move faster and has a much larger control zone than other command units. Additionally, its base energy production is much higher, allowing for fast base development. Its wide radar detection range also allows for efficient enemy and resource detection.

Relay antennas

screen_relayantenna

 

Buildings now need to be inside your command zone in order to function. The command zone can be expanded by placing one or several relay antennas on the map. Every player is allowed a limited number of relay antennas.

Actual ballistics in RTS gameplay and why they matter.

Following the « What you see is what you get » principle, Win That War! Relies on accurate physical simulation, rather than precalculated damage and approximations.

Thus, for example:

  • Damage is applied at the moment of a projectile’s impact (not at launch time)
  • Accidental friendly fire is possible
  • Any object that comes between a unit and its target may intercept a projectile.

All units and weapons have their own characteristics. Here are a few gameplay situations that may occur, as a consequence of realistic ballistics.

Ground attacks

Bombers and artilleries have in common the ability to aim at a position on the ground instead of a unit. They aren’t much good at hitting a fast-moving target. Especially effective against buildings, they can also perform barrage shots to deny access to a zone or prevent enemy passage through a bottleneck.

artillery

bomber

Since projectiles take time to reach their target, it may occur that the damage gets dealt after the attacking unit has been destroyed, possibly resulting in mutual kills.

Seeking projectiles

Seeker missiles are able to circumvent obstacles in order to reach a hidden target. This characteristics, in addition to splash damage, makes them very effective in mountains, where they can ambush their targets and deny passage through tight canyons.

missile launcher

On the other hand, seeking projectiles have their limits. Very fast units such as buggies can easily dodge them by moving in unpredictable patterns.

buggy

Lasers

Laser shots are almost instantaneous. This is why a Sentinel unit and its fast-tracking laser turret will easily decimate an army of flimsy buggies.

sentinel

Lasers can be obstructed by terrain obstacles. This is why, given the order to attack, the AI will try to place its laser-wielding units individually to give them an optimal shooting angle without being blocked by friendly units.

It is possible to give a group of units the order to position themselves for an attack on a specific position using the « Aim » command (ctrl+right click).

→ This update, and more on our Kickstarter page.

3 mega-corporations: pick your side!

MEGA_corpo_logos

When taking part in the online campaign in Win That War! you will have a choice to join one of three mega-corporations that confront each other in a perpetual economical and tactical conflict.
You will choose your side according to your own affinity towards a faction’s style, ideals, or preferred strategies. Each faction has a specific upgrade tree, and a story of its own.

ATLAS CORP

illu-cartel-ATLAS

By choosing to run with Atlas, you choose the firepower and expertise in offensive tactics that have proven their worth over many generations. Atlas made the pledge to bring security to all, in a world where, they claim, dissuasive armament is the one way to maintain an ideal state of orderly peace.
Having a background doing business in the paramilitary weapons market, Atlas Corp. naturally has unlimited access to the latest technologies in all things combat-ready. No one would risk an attack on an Atlas base without a carefully elaborated plan, lest they be silenced instantly.

 

N.A.S.C.A

illu-cartel-NASCOM

NASCA’s researchers and engineers are widely known in 43 major solar systems for being part of the highest-operating humanist activists in these parts of the galaxy. By joining NASCA’s ranks, you take a pledge to dedicate your life’s work to creating better worlds for the future generations. Specialized in infrastructural engineering and environment reforming, they claim to strive for the emergence of a “sane and pure version of our world, one that would not include or comprehend conflicts and criminality”.
Note that if the use of military pressure and economical subjugation proves necessary on the way to making the universe prosperous and worry-free, they are resolved to do it out of devotion, so that the people do not have to.

 

JONN GALT CONSORTIUM

illu-cartel-JONN-GALT

As long as men can remember, the Jonn Galt Consortium has always been around. People would probably fail to be surprised if told that Jonn Galt had preceded the universe. Joining the ranks of the consortium means to become a pioneer, and, as the brochure says, to secure a life of prosperity for your own, that would not be thinkable by working for any other private institution.
The rugged workers and experienced industry men that run the JGC have inherited an empire of federated corporations, that excels in the production of lucrative raw materials, thriving thanks to their near-monopoly in ownership of the most fruitful mining facilities, and their exclusive patents on the most advanced extraction hardware.

 

This article (and much more info) is also available on our Kickstarter page.

Our Kickstarter is live!

We’ve just launched our Kickstarter campaign!

To you, our day 1 followers (or if you’re just passing by), who believe in our project: If you do want Win That War! to come into being, well, this is the time to show your support.

now on ks

If you’re not familiar with the concept of a Kickstarter campaign, it’s what is called a crowdfunding platform. You can donate whatever amount you want, and choose to get various rewards depending on how much you donated. In our case, the rewards are (of course) the game itself, plus early access to the Alpha and closed Beta programs. But there’s also a bunch of awesome goodies, such as : the game’s OST, unique in-game badges and skins to pimp your avatar and robots, 3D-printed figures, artbooks …

See the full video on our Kickstarter page.

To us, every action counts ! Just one euro in our piggy bank to show your support, or spreading the news with your friends to make us known, these things mean a lot to us, because getting good visibility during the first days of the campaign is highly decisive to make it a success!

We’re counting on you!

WinThatWar_Kickstarter

Step by Step #1 the Engineer

Moving on with our new blog sections, this time we decided to tease you with some new eye-candy. Down to the real talk, we’re taking you step by step through the process of implementing an asset, from conception to in-game integration.
To inaugurate this section, Michel the engineer bot is going to be our guinea pig.
A few months ago, this is how Michel used to look:

Miche Insane Unity Win That War RTS

Since Nico has recently joined the team, Michel got a little face lift. We kept the same feel but made him a little more bulky for some additional #galacticswag  (please, be sure to use this hashtag in strict moderation and keep it away from children).
If you’re in the process of creating game assets yourself, feel free to share and compare your own workflow down there in the comments. Here is our usual pipeline:

Research.

michel-recherche

Concept.

michel-concept

Model sheet.

michel-model-sheet

3D model.

MICHEL_TURNABLE_FINAL

Well, now we’ll just have to put it in the game, and the good old Michel won’t exist anymore. Don’t be sad, on the inside, he’s still the same!

 

Stand Up! #1

As we were spring cleaning the blog, we’ve decided to bring a few changes and to create new article categories so that we could write more often about various topics related to WinThatWar! and Insane Unity.

This article is kind of a crash test.

As you may know, we’re working using the SCRUM method, which consists in dividing the tasks into “sprints” that we chose to last two weeks to help us we can redefine the priorities as we go along.

Actually, if you’re a SCRUM’s enlightened, you know that it mostly consists in a gigantic white board covered with dozens of sticky notes and a “stand-up meeting” every morning to let everybody in the team know which task is completed or in progress. In our case, every two weeks, we take stock and build a new release of WinThatWar! so we can all test the new features.

From now on, we will be able to write this kind of articles and update you in (almost) real time.

Dev

We know that it’s really frustrating to have to suddenly leave a game for any reason. So we figured we could create the save/load system and it is now perfectly functional, but on solo mode only.

We’re currently setting up the planetary view. Well, for now, it’s still a prototype. A few days ago it was just a spherical skeleton drawn by some neon green laser on Doom’s computer, who may explain how he did it in an article further ahead. By then, we should reveal quite a few enhancements right after the next “sprint”.

vue planétaire

Gameplay

A brand new building will soon appear in the game: the relay antenna. What is this thing? Well, as the name suggests, it will be used to relay the “network” on a given zone. Without this wonderful invention, you’ll be able to build factories, but you won’t be able to switch it on which could be an issue, right? I only can suggest to do your best to protect your antennas.

Arts

As you know (or you will know by reading this article), we’ll be present at the London EGX Rezzed on 7-8-9 April. We already have published the poster and here is the flyer! Hope you’ll like it as much as we do.

flyer winthatwar

Regarding the artistic production for the game itself, no less than a dozen units and buildings have been designed the last couple months (left to right: buggy, tank, diplomat).

conceptsweb

By the way, we’re working on the buggy’s 3D model and you’ll soon be able to create herds of them. They go just so fast!

buggyweb

Sound design isn’t outdone neither. We found a band, that’s now working with us on WinThatWar! original soundtrack, and we’re really excited about it. Plus, most of the sound effects have been reworked and the ambience sounds have been enriched, especially the “Space Ship” theme which, if you wear headphones, gives you more and more the feeling that you actually are in a cock-pit, guiding your robots armies.

To finish this article, remember that if you’re in London the next couple of days, we’ll be present at the EGX Rezzed where you could play a short demo or ask anything you want about the game to Etham and Perik! See you there (in the “Indie Room” area).

egx-map

London, here we come!

For the very first time, WinThatWar! travels!

The EGX Rezzed, will take place in London on April 7, 8 & 9, and we’ll be there! If ever you plan on spending a weekend in London, this is the time. You could come by and say hello!

In the meantime, here is a sneak peek at the poster we made for the event.

WinthatWar-Poster-resize2

I love splines!

 

A curve

In Mathematics, a Spline is a numeric Function that is Piecewise-defined by Polynomial function, and which possesses a high degree of smoothness at the places where the polynomial pieces connect (which are known as knots)“. Thank you dear Wikipedia, I couldn’t have said it better myself.

“But, what link can there possibly be between Splines and Polygons?” you may ask yourself. And that’s a legitimate question, since I usually write about polygons and cake (made from polygons too).

Well, you have to know you can actually create 3D models by using these famous splines. That’s right!

A basic spline

As you may know, I mainly use 3DS Max to model my vehicles, buildings, etc. 3DS  taught me to use the word “spline” to define a 3D Bezier curve when it comes to design.

Actually, It’s a commonly used technique in automotive design. Seeing as I mostly model vehicles, it makes perfect sense for me to be working with curves.

However, I apologize in advance, because somehow, I have the feeling this post will feel like a tutorial.

The 3DS Max “Lathe” tool works just like an actual shaping tool and allows to easily sculpt an object  with a very smooth shape.
So, as an example, I’ve made a pretty bowl for you:

The process to use Lathe modifier.

I’ve got another little trick for you : You also can do what is called a “Sweep”. This is actually a  standard shape that you’ll select and with which you’ll “sweep” the previously drawn curve.  The shape is then multiplied to create the desired object.
Here is another example for you, and be prepared, I went a bit crazy and I’m now modeling…a mug!

The process to use Sweep modifier.

Anyway, now that you see how it works, let’s get serious and I’ll show you how you can apply it to your 3D modeling.

Once, in my student days, I was looking for a tool to model by using Splines, and I finally found a tool called SURFACE. At the beginning, Surface was a third party plugin, then Kinetix eventually bought the licence and included the tool in 3DS Max 3.0. I don’t know who this third-party is, but I owe him a big “thanks”.

Digging through my archives, I found the following model. That’s what it looked like the first time I tried to use this tool, based on three pieces of circles intersecting with each other.

The use of a Surface modifier

How did the software turn this into that? I don’t have a clue. Voodoo magic?
Well, and so… how do you put this technique into practice? Among other things, you can  use these tricks to model a vehicle. An airplane, for example.

Use of spline in modeling

It can also be used for specific organic creations.
Like for this wonderful purple…marshmallow.
I could probably have made something sexier, but you get the idea.

Chantilly

In short, I love modeling using Splines . The tool “Surface modifier ” is probably my favorite, it’s part of the workflow for all my vehicles .

I also think it’s a good starting point to model an object with a lot of rounded surfaces .

However , be aware that Splines, alone, are difficult to comprehend in 3D for our poor humanoid eyes that can’t decide whether a form is curved or hollow. So we will have to get used to the tool and rotate around your model, regularly move the camera angle to visualize the form , and then use the Surface modifier.

If you’re not using this technique already, I can only recommend you try it asap!

Cheers

Philemon

Return top