japro's journal

My original plan for this second entry was to also add a matrix class that interacts with the vector class from my last journal entry. In the meanwhile Splinter of Chaos gave us a reason why we should use vectors in his journal and in the comments to said journal entry JTippetts brought up the problem that lots of libraries etc. use their own vector type. The "heterogeneity" of the C++ library landscape sadly isn't something we can change now, but when designing our own Vector type, we can at least take it into account.

Integration of other (array style) Vector data

So going back to my earlier implementation of a Vector class I'd like to add a way to interact with other implementations and "raw vectors" (also known as array). Luckily everything is already based around expression templates which are easily extendable. What I want is a way to interpret raw data as a Vector compatible with my implementation. All I have to do for that is copy & paste my whole Vector class, change its name to "InPlaceVector", replace "T data[D];" with "T *const data;" and provide a constructor that takes a pointer. Then I add the following function for convenience[source lang="cpp"]template<unsigned D, class T>InPlaceVector<T,D> MakeVector(T *const p){ return InPlaceVector<T,D>(p);}[/source]and can apply the full functionality of my Vector class to any kind of other vector class or representation that stores its data in an array.Example:[source lang="cpp"]double raw_vector[3];Vector<double, 3> a(1,2,3);MakeVector<3>(raw_vector) += a;[/source]And since the InPlaceVector object only contains a const pointer, it will once again very likely be optimized away and we don't even incur any conversion overhead.

So with that problem out of the way (sort of). We can move on to matrices.

The Matrix

So if we are already in need of vectors chance are we also want matrices. A simple Matrix class can be obtained by just copy pasting my Vector class, replace the "operator[](unsigned)" with "operator()(unsigned, unsigned)" etc. When implementing matrices one also has to decide between row and column major order for storage. I went with column major since that makes the matrices directly usable with OpenGL. An argument for row major order would be that the native c++ matrices (double mat[3][3]) are row major and are therefore more natural in C++.Besides the element wise operations we "inherited" from the vector class we also need matrix-vector multiplication and matrix-matrix multiplication. These could be implemented directly, but to make it more elegant we will first introduce a way to access the rows and columns like they were vector expressions. I guess this can be considered a form of the decorator pattern:[source lang="cpp"]template<class T, unsigned D1, unsigned D2, class A>class RowVectorExpr : public VectorExpr<T, D2, RowVectorExpr<T, D1, D2, A> > {public: RowVectorExpr(const A& pa, const unsigned& i) : a(pa), index(i) { } inline T operator[](unsigned i) const { return a(index, i); }private: const A& a; const unsigned index;};template<class T, unsigned D1, unsigned D2, class A>inline RowVectorExpr<T,D1,D2,A>Row(const MatrixExpr<T,D1,D2,A> &a, const unsigned &index){ return RowVectorExpr<T,D1,D2,A>(a, index);}//similarly for columns[/source]There are other interesting "operations" that can and should also be implemented like this like submatrix access and transposition.

Expression templates and pitfalls

So this is the point where after all the praise for expression templates I have to address a problem with them. Expression templates offer a form of lazy evaluation. This means that operations are not carried out immediately. Instead they are carried out when the result is actually needed. This has advantages when not the whole calculation is actually required. Using the tools we just introduced consider for example this:[source lang="cpp"]Matrix<double,4,4> A, B;//fill A and B with some valuesVector<double,4> v = Row(A*B,2); //save the third row of A*B in v[/source]In the assignment to v only the matrix elements that lie in the requested Row are actually calculated!The downside of this is that the elements will be calculated multiple times if they are requested multiple times. This can happen when more than two matrices are multiplied in a single expression. In that case the temporary objects we avoided with the expression templates might actually be beneficial from a performance perspective. Even worse, operations where the left operand of an assignment is also part of the expression will even produce wrong results.[source lang="cpp"]Matrix<double,4,4> A;A = A*Transpose(A); //gives wrong result![/source]For pure Vector operations this usually isn't a problem given that the dependencies are only component wise, but for matrix and matrix-vector multiplications this has to be taken into account.An easy way to solve both of these problems is to use an explicit evaluation function:[source lang="cpp"]template<class T, unsigned D, class A>inline Vector<T, D> eval(const VectorExpr<T, D, A>& a){ return Vector<T, D>(a);}template<class T, unsigned D1, unsigned D2, class A>inline Matrix<T, D1, D2> eval(const MatrixExpr<T, D1, D2, A>& a){ return Matrix<T, D1, D2>(a);}[/source]This allows us to force the execution of an expression and get a temporary from it.[source lang="cpp"] Matrix<double,4,4> A,B,C,D;A = eval(A*Transpose(A)); //correct!A = eval(B*C)*D//less operations in exchange for a temporary object! [/source]It would also be possible to have the expression templates detect these situations by passing "source" references through the expression tree and some template specialization magic. At the moment I'll stick with the "eval" solution.

Vector types are used in almost any kind of game code. Position, velocity, acceleration, forces, points in polygons and polyhedra etc. are all using some sort of vector type. Writing a vector class isn't particularly hard, but since it's such a central part of the code it might be worth it to have a closer look. Over the last couple years I implemented and customized several versions of vector classes and will now try to present my collected findings and thoughts here.

Two types of Vectors

While mathematically the same, "small" and "big" vectors are not identical from a programmers perspective. Especially in the case of game programming we typically have the small vectors that are two or three dimensional and are used for positions, velocities and so forth. Then there are the vectors we use for example when solving linear equation systems. These are often way larger and their dimension isn't necessarily known beforehand. Simply put, there are the vectors that scale in dimension with the problem size and those that don't. For example the vectors you need to represent positions of units in a game have fixed size. No matter how many units there are in the game, their positions always are two- or three-dimensional. On the other hand if you are calculating splines (which requires you to solve a linear equation system) the vector size in your linear system depends on the amount of points you want to calculate the spline for. This concept of knowing the size beforehand is relevant to programming C++ since you have to decide whether to have the size defined statically at compile time or dynamically at run time. This is also a performance concern since dynamic sizes always require memory allocations while static sizes allow you to place the vector data directly on the call stack and compilers usually have an easier time optimizing for the static case.

But in C++ there isn't really a reason why we should restrict ourselves to a type and dimension at this point. So we probably should make type and dimension template arguments. For the type this is trivial, we just replace every "double" with "T". But the dimension is a problem with the way we named the components. A obvious solution to allow arbitrary dimensions is to have the components in an array.[source lang="cpp"]template<class T, unsigned D>class Vector {public: Vector3d() { std::fill(data, data+D, T()); } inline T& operator[](unsigned i) { return data[i]; } inline const T& operator[](unsigned i) const { return data[i]; }private: T data[D];};[/source]Sadly we lose the ability to access the components via x, y and z. If we really want that we can explicitly specialize the template and add references. For the 3D case this would look like:[source lang="cpp"]template<class T>class Vector<T, 3> {public: Vector3d() : x(data[0]), y(data[1]), z(data[2]) { std::fill(data, data+D, T()); } inline T& operator[](unsigned i) { return data[i]; } inline const T& operator[](unsigned i) const { return data[i]; } T &x, &y, &z;private: T data[D];};[/source]I personally don't like doing this since writing myvec[0] instead of myvec.x is just as intuitive to me and it automatically reduces the chances that I'm writing copy/paste code since having the index operator in the sources makes it more obvious where I should use loops. Also as soon as you write a function using x, y and z, chances are you're restricting yourself to writing that function for the 2D or 3D case when you could just as well write it for the general case.

Woha... suddenly we have loops and local variables? Isn't that going to affect performance?Luckily compilers optimize this kind of stuff. Since D is known at compile time and usually small, the compiler will unroll that loop and after inlineing it will probably also optimize away the local variables if possible

The whole AddOp object will get optimized away at compile time and the result is the nice loop we wanted without any temporary objects (apart from the operation objects that aren't actually constructed at runtime).

I just started my first attempt at designing a board game. This is the first entry in hopefully a series of journal entries that takes me from the very start to a fun to play prototype.

Motivation

I was spending time lately watching some of the presentations in the gdcvault including the ones about board games (here and here) which made me think about non-digital games again. I always had phases where I was thinking about board/card games from a more abstract perspective, especially back when I was a very active MTG player. So yesterday when I was walking by a toy store I decided to buy some material and give board game design a try.

General Idea, Guidelines and Principles

Since this is the first time I am actually doing this I decided to not search for a super unique game idea/concept. It's going to be a rather generic dungeon crawling game and I will focus more on the details/rules. I always liked the idea of "realistic" board games where you are playing as an actual character as opposed to abstract games (I consider settlers or dominion abstract in this context). My main problem with existing games of that kind is that they tend to have relatively complex rules. While games with complex rules are completely fine for me, they just don't fit into the more "casual" circle of friends I usually get to play boardgames with. My goal is to get complex/emergent gameplay from rules that you don't need a whole evening to explain.So since I already spent some time thinking about problems I'm trying to solve and things I want to achieve I figured I should build a set of constraints and guidelines as a mental tool. So every time I introduce something or make a decision I can also make a sanity check against "my rules". So here is the first one:

Constraint: The rules have to fit on one side of a A5 "rules card".

Clarification: That is the rules about the game you need to know during play. Setup and examples are allowed to go on the back of the card.

Another important aspect is that I don't want to keep players waiting. So there should only be a minimum of "mechanics". With mechanics I mean the part of the game where you are doing calculations, throw dice, move around stuff and such to figure out what happens as opposed to the part where you make decisions and are actually playing. As an example: I don't want a player to make the simple decision "attack" and then stall the gameflow by a plethora of dice rolls (hit, damage, dodge, armor etc.).

Also waiting for your own turn shouldn't be boring. Having very elaborate turn structures or allowing players to in principle do an arbitrary amount of things in a turn (Dominion) can make watching other players turns very annoying.

Constraint: Turns have a constant upper "action" limit.Guideline: Allow all players to contribute to the game every turn.

I'll probably add more of these as I go along.

What I have done so far

I bought a pack of blank memory cards (6x6cm, 60 pcs) and lots of empty playing cards. I already knew that I want the playing field to be built from tiles (there just isn't any reason not to besides maybe setup time) so I painted dungeon walls on most of the memory cards.

In the rules department I so far decided that the interaction will revolve around playing cards. So this going to be kinda MTGish in the sense that apart from maybe some sort of health and level, all the stats will be determined by cards attached to characters/monsters and that it will be possible to play "spells" (during your own and the opponents turn).At the moment I imagine the turn structure to look something like this:

Draw a card

Either move to a neighboring tile, attack a player/monster that is standing on the same tile or do nothing

Starting with the active player each player may play a card

Combat takes place (each monster on the same tile as you automatically attacks you)

This will possibly change, but I don't want it to get significantly more complicated. Obviously most of the action will happen during the card playing phase.

Combat will probably look like: Use the players/monsters level as base damage, apply any modifiers on cards, reduce the amount of health points by the resulting damage.

I'm not yet sure what the goal will be. Possible something as simple as "reach level 20 first" or "reach level 20 and escape the dungeon". Another possibility I am considering is to give every player a unique win condition at the beginning of the game. This makes it more likely that some sort of actual story unfolds.