About this blog
Setting fire to these damn cows one entry at a time!
Entries in this blog
Yes, I am starting a new project! But before I get to the meat of it, the game idea, I want to point out what I actually would like to accomplish with this project.
I want a platform where I can learn more about game programming and in general designing a medium sized code project. It should be a game with a very limited scope, a small game that I can dissect and inspect completely, that I can experiment with and test my expectations.
Wow, I almost sounded like Ghandi... anyways it is a study project with one main goal, learning. I want to learn more about game design, programming, and software architecture. The latter one is great, since I have this very subject in my current semester, yay!
Ok, so what is it? What is the game about that will flatten my path to world domination? Alright, here it comes:
ALIENS! Wait no, not this one, MAFIA!
This game idea is based on the social game Mafia aka Werewolf aka Assassins aka Witch Hunt. I thought it may be a very interesting concept for a multiplayer game. I also think it is a good excercise how you translate a "normal" game to a computer one.
Alright, roll up your sleeves, LET'S DO THIS!!... But how?
How do you base a game on a different game? Writing it down, it seems like a no-brainer: Let's research the original game! Wikipedia had a surprisingly good page on it:[quote]
is a [/font][/color]party game[color=rgb(0,0,0)][font=sans-serif] created in the [/font][/color]USSR[color=rgb(0,0,0)][font=sans-serif] by Dimitry Davidoff in 1986, [/font][/color][color=rgb(0,0,0)][font=sans-serif] modelling a battle between an informed minority (the [/font][/color]mafia[color=rgb(0,0,0)][font=sans-serif]) and an [/font][/color]uninformed[color=rgb(0,0,0)][font=sans-serif] majority (the townspeople)... [/font][/color][/quote]
Why do I bring this up? This little sentence sums up the whole game, it is the core mechanic! Alright, why should that help?
The core mechanic in my opinion defines what the gamer does but not necessarily why the gamer likes it. Sometimes the core mechanic is easy to find and sometimes it is as hard to find as your car keys you had 2 minutes ago.
What is the single mechanic in Portal? The Portal Gun of course! Nobody would make a Portal sequel without the Portal Gun. Think about it, in Portal, you have many different objects to play with. You have boxes, "hard light bridges", fluids etc. to play with. All of that are only new toys for you to screw around with the Portal Gun.
Yet in Diablo 2 I can't find a single core mechanic apart from it being "Action" RPG, which was the single revolutionary aspect in the
original Diablo, every notable RPG before it was round based. Thinking about the Diablo series like that suddenly makes more sense why D3 fell flat in everything gameplay related. The skill system is crippled with the extensive cooldown, resource system and limited skill selection. At the core of Diablo was the idea to just "use" your skills. On the other hand they fitted the D3's Monk with such ridiculously shallow resource "spirit", that I could only use the cool skills I wanted any 20 seconds or so and even if i had the resources, anything cool had a stupid cooldown timer too. No other skill reflects that better than the D3 Barbarian Rage skillset which all have a cooldown timer of 120 SECONDS. Blizzard, are you telling me that I need to wait TWO BLOODY minutes until my barbarian does something awesome again?! What the HELL is that, coffee brake mandated by *the hero's union*?
On the contrary, in Diablo 2 I could use almost every cool skill I wanted at any moment as often as I wanted, if the situation allowed it (e.g. enough mana and no manaburners). I could even use skills for somethng they weren't intended for, using the Paladins Charge skill to get away. That's why on surface Diablo 3 looks similar like Diablo 2, they correctly analysed what people liked at the old Diablo games but they completely forgot what you were supposed to do. That's why it isn't a true sequel to the Diablo series, like you made a Portal 3 without the Portal Gun...
buuut back to topic... at least how I understood this, you can make completely different games with the same core mechanic, you simply vary with what you give the player, with the core aestetics. You could make a shooter out of this, but that would be putting a different mechanic at the core and just use that as an "extra".
So basically I try bringing this social game in the digital realm. That doesn't mean that it is simple, now with networking, animations and fancy stuff I can add a lot more to the core mechanic...
AAAAAAAHHH SCREW YOU, BRAIN!
You may not have noticed this, but often things become more clear when I've written them down, and now suddenly my brain kicked in and told me that I could be trying to deviate more from the social game and explore more... and I had a few nice ideas how you could encorporate the game... so I am going to experiment more with this, but that should be the topic for an other post.
Damn, this entry is even less coherent than usual, maybe this really deserves the rambling tag. In defense, I am getting a cold, so that may be a reason why...
As the title says, you gain experience shortly after you needed it, or in this case, knowledge I gained after abandoning my project that would have been useful at the start.
Basically, those are all the questions and tasks I should have tackled before I began. This post is partly for me and partly for anybody who also wants to start his own projects like me: HEAD ON!! . I guess many people are like me, when you have an idea you want to get started ASAP! But you tend to profit from stepping back and ask yourself some important questions, you have to be sure it is the right project at the right time.
This is in no way the best or only way, or the only questions to answer, this is only what I will be doing in the future.
Why do you even want to make a game, what is your personal goal?
This question isn't asked often enough. Why do you do it? It's maybe the most important question you need to ask yourself, everything else, the goal of your project, depends on it. This isn't a philosophical question, your answers can be very trivial like "I want to make a living", "I want to learn about X". Maybe you don't have only one goal but serveral, in that case you should settle on one main goal. The answers alone seem a bit useless, but they get important together with the next question, so bare with me.
What is the goal of the project?
Again, the answers can be very simplistic like in the first question ("I want to sell it"). Now if your main personal goal and the goal of the project deviate, you inevitably run into problems. For example, if you want to learn but the main goal of the project is to be profitable, then you probably are working on the wrong project. If you want to learn, it is important to be able to fail, sometimes you learn more by failing instead of accidentally getting it right.
What technology do I use?
Unless your goal is to learn a specific platform, toolset, language etc. this is the wrong question to ask yourself at this point. Don't settle on your technology to early, maybe there are better tools for the job.
Alright, I got everything. I have this great game idea, let's do it!
I was there too, you have written your game idea to paper, and are keen on working on your game, but wait, you missed something!
Do you know which mechanics are more important? Do they even fit the game you have in mind? Do the mechanics even tell the same story as the story?
Before I ramble on, I want to say something about how you get your ideas.
Very often, you come up with an idea by mixing existing games or genres together, because in your head, it plays like the next cool game (my earlier post about that). But that's not the only way to get new ideas, for example: the fine people at Valve came up with "Left4Dead" while AI Programmers were testing new bots for Counter Strike. They were fighting as a small group of human players against a large number of bots who only used knives and they had incredible fun while doing so.
Dissecting the game
Let's go back to Left4Dead, I think it is an easy game to dissect when you have listened to the developer commentaries, some things become strangely clear. I am no professional, everything I write here is purely based on my understanding of game design.
I'd say, every game has a core principle, the core gameplay, how you would describe the gameplay in one sentence, many unarmed enemies against few armed players. That is, at least in my opinion, what the developers at valve experienced and liked while playing against unarmed bots, they played the earliest prototype of Left4Dead.
We then have to set the core aestetics for the game (watch the video at the end, it explains this better than I ever could). For Left4Dead, it is undoubtedly Co-Op, but it didn't have to be. I am sure you could imagine a game where compete against each other player. Both can be explained with the same phrase, but nobody would say that these games are related.
Now why should this matter? Again, let's turn to our poster child. I challenge anyone to find anything in Left4Dead that doesn't enforce co op. From the items, over the levels to the story, everything serves only this purpose. Yes, it also has a competitive aspect when you put 4 vs 4 in the mix, but I argue it isn't a core aestetics, in the end you compare the team effort. Compare this to Call of Duty multiplayer death match, where a good player can essentially win the round while he drags along not so super players. In Left4Dead on the other hand, it doesn't matter if you have an uber player in your team, he can't win alone.
So, why is Left4Dead a zombie shooter? Because it fits perfectly with the core gameplay and the core aestetics. Valve didn't do it the other way around. That's why everything feels right in Left4Dead, there is nothing that seems out of place at least in my opinion.
I think this is by far the hardest step, this is where you see the difference between novice and senior game developers. If you do this right as early as possible, you have a good understanding what it is that you are producing and how valuable feature X is to the game. It gives you a scale to judge your features on.
...you should have a solid basis for your game project, mind you anything of the above should never change. But the reality is, they often do. If something does change, don't take it lightly, be sure what impact your change has on the game, the project and on you.
I think now
I wanted to write about my own game idea and how I tried to dissect it. Alright then, that will be the topic of the next entry.
Starting your narrative
Alright, this is going to be a bit of a gloomy post, at least for me.
In short, I am postphoning Project: Phoenix indefinitely, as studios like to put it. I am not going to work on it in the near future, but maybe later when I am wiser, more experienced, have more resources at my disposal and a better grasp of what actually needs to be done in a game project. I wrote in my last post why I am abandoning the game, here I want to show you why it is the right choice.
The simplest explanation is, my goals changed. This first started as a framework to dig deep into C++ and more low level programming. After starting to think more about the game I want to be making, I got more and more excited about this project of mine, until I had a cool game in my mind that I really wanted to see coming to life. Without really realising it, I changed my goals.
That isn't a bad thing, until I came to realise the second thing, I haven't done a single game before. Making a 'good' game, let alone the quality game I had in mind needs more than pretty ideas.Excluding story and artwork, it needs solid game design, fitting mechanics that envoke the feelings you intend to invoke, about the pacing of the game.
It is like writing a poem, just because you can write words on a sheet of paper doesn't mean anybody will like it. It also doesn't just take hard work and time. It takes a special way of looking and analysing your writing, what it tells the reader conciously and subconciously. And that in a nutshell is game design, at least this is how I understood it.
And here lies the main point, I don't know anything about this. To learn it, you need to gather analysing skills, you need to analyse different work, and most importantly, experiment with it. This may be the best way to learn about game design more than in any other field. And with Project: Phoenix, I had no room for experimenting, wich also means room for failing.
So I abandoned the project, the goal was not really reachable for me and it was the wrong goal to begin with. My goal should be about learning, learning how to solve the problems in game programming and how you design a game.
That doesn't mean that I wasted my time, quite the contrary, I know now very precisely how you should NOT start a game project, I know how and why games can change so vastly during development, I aquired the best grades in my college C++ classes, I started gathering skills to analyse games and game ideas. I learned about human psychology, the uncanny valley and pacing, I learned about the story structure, the journey of a hero and the badly written plot. And those are only the non technical aspects, I learned much about topics I didn't intend to learn about, which is a good thing I guess.
To the future! With a project that I can experiment and possibly fail.
What is it going to be? I'll write that in my next post.
sooo... this week's entry is about the completely same topic as the last one, but a bit from a different side. In a nutshell I want to show what I did wrong in my first game draft and what I further change. At the same time this should be a bit of a example how fast your game idea can change.
in this post, I rely heavily on the principles explained in this video:
So, everybody watched it? Yes? Everybody understood it? NO?! GREAT, let's move on!
The Original "Project: Phoenix" Game
In retrospect, the game I had in mind when I wrote the first entry, has something like these three core aestetics:
Looking back at it, this seems a bit overblown. I fear it would have been too much, a too mixed experience to be any good. It is like combining drama, documentary and action in one movie. Even if you pull it off, it is too mixed for the viewer, not focused enough.
Especially the Co-OP and Strategy aspect would have been in conflict with each other. The original game would have been more like two completely different games in one.
I am sure there exists a way to make a beautiful game with very similar core aestetics, but maybe not for this type of game.
It may be important to note here why this happened, I am sure many new game developers do the same mistake I did:
You want to make your game you always wanted, your awesome revolutionary idea, so very different etc. Even if you KNOW this to be wrong, it still felt that way when I first wrote about my game. I see a lot of similar dream posts when I have a look at the forums. When you first write about it, you tend to explain it with different games (Oh, it's gonna be like StarCraft, but with your friend being able to play as a champion like in League of legends... etc.) and that's basically what you did, what I did. Mashing games together. That's why this won't work, you end up trying to provide many different core aestetics without analysing if they actually fit the game. How could you, you just started really experimentnig with game design. The best you could achieve is getting two different games packed together in one, or the worst and more likely solution, you get a game that is neither of those you originally mashed. Like having a bollywood romantic plot in a shocker movie like Repo Men.
Obviously, Project: Phoenix has to change. One aestetic has to step down from the core. It can still be in the game but only to enforce the other two aspects. This means that there would be a planning phase but far less powerful,more as a platform for players to communicate what they want to do.
But by having these two core aestetics in focus, Co-Op and Exploration, makes for a different play, a different experience. It is, a different game.
Welcome to "Project: Phoenix 1.1".
I think this could make an awesome game, putting in many of the ideas I touched upon in previous entries. The soundtrack fits perfectly.
Even the theme I have in mind only enforces the two core aspects of the game. I'd like to explore the very human feelings you get when you are sent out in a world where everything is here to kill you, where your life is essentially in the hands of the guy next to you. I would need to scrap the previous lore and story drafts but I wasn't too happy with it anyways.
Maybe you haven't noticed but I am very fond of this crude draft of the game, so why am I using words like "would"?
I won't be working on that game. Not in the near future. It has a more serious theme and requires serious artwork, it's a beast of a game that needs more content, it requires more resources than I have.Furthermore it is my fist game, this isn't a good platform to experiment with. I would be too attached and too fearsome to release any version of it to playtest.
I would trap myself in a circle of doom and never progress further.
What to do now? Well, I can play with the aestetics, setting and theme of the game and have a look what comes out. Maybe I can reuse some ideas from the original game. Maybe something comes out that takes less time and may be interesting to experiment with from a game design perspective.
The biggest resource eater is the Exploration aspect. So let's get rid of it. It's still a post apocalyptic isometric shooter, but not the same game anymore. The basic storyline would be something like "Old bunker should be breached and cleared for a new base in this area. Make it happen." This leads to a more Level-like area, with limited space and limited possibilities. This would also get rid almost rid of any strategy aspect. This game would have the player to think about the tactics but that's not as in depth and complex than anything you'd expect from a strategy game.
This is the closest I get to the original game idea, not bad.
Let's scrap the Exploration part and the game theme and instead, play with the gamer's "Trust". Let me explain:
Normally in a multiplayer game you can very much trust your partners. They have the same goal as you, if you lose, they lose too. Unless you have a troll, they probably don't want to stab you in tha back.
But what if your partner has a different goal?
The idea is taken from a social game I think the english world knows as "witch hunt" or "mafia".
Reimplementing a social game is a bit futile, then the gamers could just play it via skype. But I can take out the basic idea of the game, there is an informed minority in a group that try to work against each other.
I haven't figured out much, but I know that it makes sense to change the setting too.
You see, now I have a completely different game that shares almost nothing with the original draft.
Scrap Co-Op, exploration and the theme. Instead focus on action and storytelling, making it a single player experience. There probably won't be a leveling system in this variaton. In the Project: Phoenix 1.1, the leveling system is used to enforce "Co-Op", each member is trying to get more valuable for the team, being the guy the team needs him to be. But in this variation may a leveling system even be wrong.
In such a world, a more scary theme could be a good way to go but that also requires a different protagonist that isn't a soldier.
So what is it going to be?
I don't know, I seriously don't. But of one thing I am sure, the game I'll be making probably deserves a new journal.
sooo... this week may be a bit of a weird post. More weird than usual? Maybe, probably...
I am sort of scrapping everything of Project:Phoenix and start again, except for the code, there isn't much around yet, but more to that later.
I didn't write about it, but a lot changed since the last time I updated this journal, the game today and the game I wrote about in my first post back in August are more different than they could be. It seems very similar to species evolving, diversifying and eventually becoming so different that they are considered different species.
The same thing happened with the game idea, I added, changed and removed ideas and ways I thought about, now it is a different game.They still are related, I am proud that so many ideas persisted for so long and how many will persist that I haven't even written about. I am sure that this could become a great game one day. But I'd have to work on it till the end of times to be in a fit and finish I have in mind, until I can move on.
So what changed then?
Something I found out I defined without really knowing what I did. I first imagined that people will play it at LAN-Parties, just having a good time.
Without knowing, I defined a theme, a feeling for the game, something the player should experience while he plays. But I also had a second theme in mind, I wanted to be more realistic in how a military team works. Look at the Battlefields and Call of Duties out there, Everybody does what he wants and shoots around. In reality, an attack is planned beforehand, the bigger the attack, the more vigorous the planning.
I didn't put both in, because they fit well together, they don't. I put them in because I liked the idea, because in my simple imagination it worked. In reality however, they are more conflicting than not.
And that's what I changed and what I haven't yet decided, the theme. One idea for the theme is Trust. You are sent in a dangerous world with your fellow gamers, you live because the guy next to you doesn't let you die. But he is encouraged to. In the end you are set to face a dilemma, only one of your team can survive and join at the side of the commanders. So you either have to kill your team or you all die.
I like the theme, you can have plot twists which are not in the plot, but in the action of each friend you are gaming with.
Sadly, empowers the game as much as it hinders it. This game does not make sense in single player model. Let's be honest, I never released a game, practically nobody knows about it, there is nothing I can show. I am lucky enough when somebody takes a look at it, when it is required to play with a friend or two, who probably aren't around at the moment.
In short, scrap it. Valve could pull something like that off, but I don't. So I don't
What am I doing?
I don't know, I am still dreaming about different things, scenes, and in general, what you should actually let the player do, how do you tell a story, how do you let the gamer experience something about himself. But I can tell you this much, it will be a single player game, some mechanics will prevail, but it will be vastly different from the game I have in mind.
When I have the theme laid out, I will rewrite my basic game idea, trying to draw a more acurate picture than I did before and, try to show you just how much it deviates and where it is very much the same game.
The lesson to learn here: if you want to make a game and you have a game idea, try thinking about the theme, what feeling the player conciously or subconciously is exploring while playing your game. What question he's left with when he finished. It defines EVERYTHING!
Sooo... this week I write about the overworld. "Why?", well, I missed writing about it in previous posts and it is important enough to get it's own entry. Without further delay, here it is:
If you remember, I have an overworld. This feels weird writing it like that, as if it's an illness. But back to the topic. The first thing that I missed thinking about, when do I switch from overworld to "fight view", and vice versa? And since everything else kind of depends on that, I should think about that first, right? Maybe, but I won't. I try it the other way around.
The Overworld is rasterized, I call one square a "sector" in game. Of course it doesn't make sense mathematically, but it sounds cool and very military like.
While trying to solidify the idea of the overworld, I came up very Usability-Like requirements... I am baffled, what has dry technical stuff to do with fun games? This makes sense, in Jagged Alliance, you could have let the player run through every sector of the world, but that wouldn't be fun. So my overworld only exists so the gamer can cope with the vast levels. Pure usability. Well done, I tried to do a project to get away from the dry stuff, at least it has more colors and features guns.
But anyways, the overworld view should provide time saving mechanisms and should serve as an information hub, giving an overview of all relevant informations (well duh, it's called OVERworld, of course it should give an OVERview). I know this is a bit like being captain obvious, still it is an important requirement to meet.
This too seems to be a no-brainer at first, FAST FORWARD! It gets a bit complicated when looked at carefully. When is the gamer able to fast forward? Does it have some kind of dark side? How can he simply command tasks that are to be fast forwarded?
For example, is he able to let his soldier do reconaissance on it's own and fast forward it? Well then it is a useless mechanic and I only waste the player's time, even if it isn't much. Or do I let him chose to do it himself and award him with something? Or do I get rid of it and tell in the lore that satelites provide all necessary info? It is amazing how you can easily include or remove a whole gameplay mechanic. This decision is more important than any "what language to use" decision for the actual game.
Back to the most obvious fast forwarded task, travelling. This too hides some problems. In Jagged Alliance for example, you could fast forward when you travel from sector to sector, there wasn't anything "between" the sectors, even when you manually walked through a sector, you still had some travel time to go to the next. Project Phoenix on the other hand, should have a seamless transition from one sector to an other. In a game like that, where you could get ambushed at any time, it is important for you what route you choose inside of each sector. So I need a powerful tool to let the user chose his path of desire at the right level of abstraction. Furthermore I have to define when the gamer is allowed to fast forward, how far away enemies have to be, and so on... and an other very important question, if I allow the gamer to fast forward, do I allow him to stop time? ...oh boy.
Still, very easy at the first glance, but what information should I put in the overview? What is relevant to the gamer?
What information do I actually have?
I don't know, or I don't know everything not one thing definitively, this shows that my game is "work in progress". At least I now know what I don't know, this is progress, progress is good.
A view thinks are self descriptive:
Your camps, and as a pop-up your equipment and supplies.
Yout home base and save zones.
Your target city/stronghold
Enemy movement you know of (somehow)
Now it already gets messy, what enemy movement. For example a fast moving group of hunter demons that hunt YOU is very important to display, but a group of demons that are going to fortify a position, is that important? If not, how do I intuitively hide the info so the user can see it if he thinks it is necessary?
Here, Jagged Alliance has a nice solution idea, there you can toggle displayed information on and off. For example, you can toggle to display enemy troops on and off.
Now that's not too bad of a start, I wanted to write anything about the overworld here, but I start to think I wrote about everything I currently can vote. Like I've written before, I now know what I don't know, I have to write more about the demons and furthermore I have to think about something I call macro strategy. What strategy the gamer can pursue to defeat the demons.
sooo, this week I try to write the entry drunk... yeah, I am really drunk, so don't think to harshly about any spelling errors.
This is the second part of the "Power of Music" series, but I have to disappoint you, this won't be a huge entry writing about the missing music pieces of my current project. So why did I have the need to write this?
Basically, I was listening to pandora.com and literally tripped over a piece of music that couldn't represent my game more perfectly than any piece of music that I know of. Here it is:
I can envision it as only a sort of "travel" soundtrack for my game, and yet it strangely underlines my overall vision of the game. It draws a sort of torn apart picture. I can imagine the artwork I'd like to be associated with the game, I can imagine quite a lot.
To be blatantly honest, that's why I had the need to post yet another entry about the music, without having diferen soundtracks for diffenent situations that I coudln't cover before. Until today, it was I kind of searching for music that made ME feel the right things for the specific game moments. This isn't too bad, but now I feel like I've found the music style I would tell to a professional composer (if i had the money).
It seems to me that this day marks a very important decision. At the first glance, it seems more trivial than anything else, but defining the STYLE of the ingame music can be very difinitive to what kind of person likes the game or not.
I first didn't grasp the groundlaying outcome of this decision, but I think defining a music style for a game is more than just "a music style", it defines your overall feel of the game.
Thinking about Portal 2, if it had an other type of ingame music, it wouldn't be the same at all, it is not only the style of music you settle on, it is the style of emotion you try to set for your game.
I am very sure that this decision is often not taken too serious, not thinking about how much the music influences the overall "feel" of the game (in the end, that's what the people will remember of your game).
So, while just posting one music file for my game project, which won't be available in the actual game (due to copyright issues if I am not mistaken), this single soundtrack may be more important than any posts I've wrote over the last couple of months. If I have some art piece posted to me,. I can actually decide if it fits to my world or not, I started to define the remebrable part of the game, the art and feel of it.
Having an arstyle, story, sound and music that fits your world is one part, but making it distinctive enough that people will remember it is an other aspect. I always compare Borderlands to Darksiders. Both games have a good looking artstyle, butTa I am very sure that Borderlands will be remembered as one best games of all times, while Darksiders will eventually be lost in the flood of games.
Darksiders doesn't have an ugly art style, but it is just so generic, it fits to every halfways epic music, it is so mainstream fantasy style.
Borderlands on the other hand has a very distinctive world, very distinctive artstyle. This is not only a good thing, Imagine the difference of the Borderlands 1 and Borderlands 2 theme songs. From a "money" perspective, making a sequel to the predecessor isn't easy, especially when it stood out with it's exceptional artstyle and overall feel, as a game designer, you may be limited in your enovations.
Still, defining a style is to me like having a face for a game in the flood of games we have today. People may not necessarily like your game because of your artstlye, but they at least will remember it, for the good of bad of it.
Maybe you missed my latest entries in this journal. I wrote this in my last "almost missed entry", some weeks ago I wrote the journal entries days to weeks before they were published, I sometimes scheduled the topic of the entries a month before the entry was supposed to get posted. The last few weeks have bitten me in my ass, by not completing me pre-scheduled entries, they were published in a very unfinished state. I was already very annoyed by that. But when I took the already published entries down, made them fit and finish and reposted them, they weren't listened in the gamedev.net latest journal entries.
So if you haven't already, take a look of my past entries, maybe you have missed one if you are interested.
That was it, I hope it was at least entertaining for you to read my text written by drunk me. Have a nice week end.
Sooo.. this weeks entry is about what the title says.
Why? Because of everything.
I recently came to the conclusion that designing a game doesn't only mean designing mechanics, designing the gameplay. Good games design the feelings the player has while playing the game. And those are the games we remember, we know and love.
On the other hand, the very bad games have much in common with bad horror movies. Instead of feeling scared, you laugh your pants off in the worst case. Not because it has such good humour, but you see the director trying, and terribly failing at giving you an emotion.
Making a good game, starts by you knowing what atmosphere your game should have.
I try doing this by going out there and finding music that reflects the atmosphere I want to have in the game. I know this is starting to look a bit esotherical, but trust me, I am an engineer.
No seriously, think about the greatest moments you had in video games, movies, etc. When you find the soundtrack of exactly that moment, you feel the same way you did during that scene. I think music is a very good way to make atmosphere tangible and if I was working in a design team, this may be even more important. Without it, there is a bigger chance that the designers have different images of the game in their head, therefore the game can become inconsistent.
In my opinion, inconsitencies in the game are the most accidentally hilarous thinks that can happen.
Finding music for the World itself was the most important task. It should help defining the settings and the overall mood. Also, how the people react to earth's transformation from a habitable to a very hostile planet. It also gives a bit of a "I am fighting for earth" mood.
Planning should be important in this game, so it deserves a soundtrack.
I am not completely happy with the soundtrack, it is a tap too much A-Team like, it has a different style that doesn't completely fit with what I have in mind, but it gets in the right direction. It gives a kind of urgency that I very like.
In Project-Phoenix, you have three basic tactics, therefore they have to have a completely different appeal, they deserve a different soundtrack. That's the reason, why playing splinter cell as a Rambo just feels wrong.
I stumbled upon this by watching people play Halo 4. I enjoy this soundtrack very much and it happened to fit in my vision of gameplay for an attack. It isn't too fancy, you don't feel like being part of one big army, it starts and ends bitter, almost sad. I want the player to feel that he is fighting, because the only other choice he has is death for him or his comrades. So they fight not for glory, not for freedom. not to be remembered, because there is nothing left to do. Because it is there last hope for a better world.
To me, this soundtrack fits perfectly to what I envisioned, if I could, I would put it in the game. I love the way the soundtrack builds up urgency.
I want the gamer to sneak around, finding his way to his target and either take out an demon before he sees him or sneak around him. Or if the player was spotted, kill the alerted before it is too late and he has to flee.
The sudden rises in the soundtrack fits that perfectly. If I want to make the gameplay awesome, I should incorporate that uprising in the game.I dynamically change fade in and fade out a soundtrack if he was spotted or is attacking.
I currently don't have a soundtrack for that. I first wondered why, if i don't know enough different songs. Well, here comes the practical application for finding soundtracks to your game design. My vision of ambushing an enemy is just boring. Find a place to attack, find a spot for each player, BOOM, flee, rinse and repeat. It is too short compared to an assassination or attack, and frankly, too repetitive. I also wanted to have the ambush fail, let the demons take an other route and miss the ambush spot. Then I frankly just wasted the players time.
I didn't find anything because there wouldn't be a soundtrack not good enough, my vision isn't good enough.
I still don't have soundtracks for the other way around,when you have to Hide, Run, Retreat, or when you die. It's possible that I don't include a "Victory" theme, as you have in Call of Duty every time you've won a round. I'd like to give the player a feeling of accomplishment, but having victory trumpets is just wrong an a dark, bitter world like this. Ideally, the player would have the feeling that he accomplished SOMETHING, but he is not sure if it is for long, or if he got closer to his end goal, liberating earth.
In the last two weeks, I accidentally published a couple of entries that weren't supposed to go up. I normally use the function to schedule a specific entry for publishing. I then normally wrote the entry one to three weeks before it was actually visible. Now with all the exams, I stumbled out of schedule and you saw this and the next entry already in a very unfinished state. I apologise for that.
Sooo... this is a bit of a mix post in terms of categories, since thinking about the antagonists sort of touches upon most Categories in a computer game.
Talking about enemies is one of the most obvious crossover between game mechanics, story and art. All of them are equally important to form a good antagonist, that is fun. To me, it also means the disciples are influencing each other as well.
Minerals of Plot
I've read the guide to bad plots(http://www.ansible.c...le/plotdev.html), I tried to not use plotdevices, but I almost have to have at least one in a game like this, I just can't get anywhere without one. BEHOLD: The Minerals of PLOT!
I cleverly call it Diabolite. The name is not the greatest of all, I know. I am likely to change it when I find a better one. For now, it will serve it's purpose.
And since I am already writing about names that are subject to change, I let the humans call the enemies "the Horrors". The name doesn't satisfy me either, it is a better way to refer to the antagonists than "the enemies" or "monsters" I presume.
But back to the Diabolite:
the minerals come from far down under the earth: Natural Diabolite grows in a crystal shape. Even in it's unrefinded state, it is a valuable resource for both the Horrors and the Rising Sun. The Diabolite crystal is remarkably sturdy against most steel alloys. It tends to enclose precious metals like Titanium, Gold, Cobalt, Palladium and sometimes even Platinum that can be retrieved by refining the mineral.
But it's main application is to serve as a source of power for the humans as well as the horrors. Since the invasion, the humans have almost no other powersource left.
For the Horrors, it is more accurately described as a nutrition, the more primitive Horrors seem to feed on the raw Diabolite, while refined Mineral is eaten by the more intelligent creatures. Either way it is the only thing left after defeating one of the Horrors.
More on the mechanics side:
Diabolite is the main mineral of the game, the player needs it at LEAST to buy ammunition. Maybe I will do more with it once I give more thought into the Items/Skill system.
The weapons of the later game mainly use high performance ammunition. While effective, using them is also expensive, using it against a weak target is essentially wasting resource.
From a design standpoint, I always knew I wanted two groups of enemies. One group attacking with melee and one attacking on long range. A team of players has to use a completely different strategy for each group. While dealing with long range attacks, each player should dash from cover to cover and trying to provide cover fire. But fighting against fast, melee enemies it is generally saver to stay in a open field and take them out when they run towards the players.
I also played a bit with Ghouls, Zombies essentially, in my head. They never seemed to really fit. By fleshing out the resource idea, they suddenly make sense: Ghouls are the resource eaters, plus they potentially alert the more dangerous enemies. They themselfes are not a real threat, but a group of ghouls at the right time at the right place can change the situation.
The long range enemies are represented by the "demons", generally humanoid creatures that are also fairly intelligent and are able to form teams, flank and ambush the player.
Close range and let's call them 'special purpose' enemies are called 'Nightmares'. From an evolutionary standpoint, they don't make sense at all. Most of them are fast and vicious opponents, although most of them are not very intelligent. But there are some Nightmares, the humans call them Overlords. Alone, they are no threat whatsoever, but they seem to be able to control the simple minded Nightmares and let them attack in packs, wait for the player around the corner, flank them from behind etc.
The Horrors are now in a very raw state. I will carve them out in a later entry. I need a crude idea of what the Horrors are and what they can do, so I can think more about the overworld strategy.
the Inevitable happened, the exam storm has hit the harbor. And it hit hard.
Also, I maintain other hobbies than programming, I also do some martial arts and now have the chance to train for amateur full contact fights. That would mean more training and less time for other stuff.
But I don't want to stop programming this, I love the concepts, problems to solve and design thoughts while starting my own game engine. Abandoning the project is not what I want to do and not what I will do.
Long story short, I don't have time writing more journal entries at the moment, I was very lucky to have time writing this one. Because if I am not writing a journal, I am studying or try to educate myself more on how to tackle such a complex software, or I am fighting with minor problems of QT and Doxygen.
(Talking about QT, bugger me but getting QT and doxygen working together was very anoying. The plugin for the QTCreator needed a newer version of QTCreator. The right version installed, I've found out that Linux Mint used an older version of a library, I think it was a C Library. In the end I installed Kubuntu, had trouble installing the latest versions of QT, and settled with the older QT Package but the QTCreator 2.5.0)
And When I am doing neither of those, I am training.
I am still figuring out what problems design problems I have to solve, and when I try to maintain the interval and length of published entries, I won't have any time left to do what I came here to do, to program.
This means I will probably lengthen my Entry interval, maybe write less structured and shorter entries. Only time will tell. But I try to update on my thoughts and design questions/choices.
...finally! Finally something I wanted to write about all along!
Why didn't I do it? Well...
... I knew I didn't know anything about designing such a complex system. I tried to find some good examples on the Internet. While one wasn't very bad, it didn't make too much sense to me, I always felt like something was missing.
I finally ordered the book "Game Engine Architecture" by . In short, it is great, it contais what the title says. It talks about the problems in modern AAA game engines and how the different engines solved them.
"I don't want to make a AAA game engine, why should this book be good for me?" Because it talks about everything a game engine has to do, about what subsystems it can have.
If you make your own hobbyist game, you face similar problems, only your solutions are simpler. Plus it orders your code nicely and logically.
So basically, if you own this book, this entry is obselete. Almost. Here, I want to write about the groundlaying decisions you have to make not as a professional, but as a hobbyist, as a guy who just wants to start programming fun stuff.
Starting your own Engine
The first and most important question:What is my target, what do I want to get out of it?
Many starters rush to the next questions about the engine, but most importantly, why do you want to do it? Do you want to get money out of it? Do you want to learn? Do you want to implement your dream?
It was simple for me, I came the other way around. I originally wanted to have a C++ learning project. After some time, it dawned to me, instead of programming some boring shit, I could write a game!
To the people who want to realise their dream... unless you are a senior in gamedev, it won't happen. Or the game would not look like the way you dreamed. If you know this (not simply reading this sentence, but KNOW what concequences this can have on your motivation), then move on.
What game do I want to make?
There is no point making an engine without a game in mind. That's how simple it is. If you have a raw idea, it helped me writing it down, solidifying my thoughts. A good Idea is writing a journal about it ;).
What platforms should it be running on?
This can already narrow your choices. For example: "My platform is IPhone", you are pretty much set.
If you say "Well... uhm... on a PC?" You didn't get much further. You also have to ask what for what operating systems. JUST DON'T ASK ME WHICH!
"So for what operating system should I programm?" ARRGH, alright let's not start a crusade here. It should run on your favourite platform you are developing at. You can put more thoughts into it, what kind of person will download and play your game. But that is only secondary, unless you want to make money out of it.
I chose to tackle the Devil, I went for cross-platform. If you use cross-platform libraries, it shouldn't be a big problem, right? NO!
It is easyER when you chose a higher programming language like java, C#, or python.
In a Language like C++, it isn't too difficult either, when you know how. And you DON'T KNOW how when you're not an experienced C++ developer.
Just for the record, I am NOT an experienced C++ developer, I witnessed first hand how painfull it is.
What Language do I use?
For now I tried to avoid talking about religion, but now I can't talk around it any longer.
From a Theoretical Computer Science stand point, it really does't matter. There is nothing you can do with language A that can't be done with language B. The only difference is, some things might be easier to do in a specific language.
"So what should I choose?"
Oh dear. Ok... just... alright, are you a beginner? If you are, choose anything BUT C++. Go with C# or Java, both work very well, both have a good tutorials and beginner forums. Both have a C syntax and you could even get a professional job as a programmer in both languages. Don't just DON'T START with C++.
"Why?" Let me tell it to you this way: Java and C# are like a good wooden bridge over a deep cliff. It supports your weight and even has a wooden safety railing. You can jump off if you want to.
C++ on the other hand is like a bridge of three ropes, one for your feet and 2 for your hands, with a angry gorilla at the other side shaking the ropes wildly. It also has a sign besides it "Health and Safety Advice: Don't fall off, or you're dead!".
If you say "well, I looked at the C++ tutorials and I thought they are pretty simple", then I can't help you here. Do what you have to. You'll see soon enough.
What libraries do I use?
With your favourite language chosen, you can go out and search for useful libraries. I can't advise you how you chose it, I can only urge you to use one.
You don't have to reinvent the wheel all the time.
What Toolchain do I use?
If you are new to programming, you may ask yourself "what do you mean, toolchain? Like a toolbelt of a construction worker?"
No, with toolchain you refer to the tools you are using while developing your program.
Now you are at a point where sometimes, you already have a common toolchain available, I urge you to use it. Don't try to be different, there is a reason why it is common.
Before you start coding, you should set up your toolchain. I know many don't believe me, but you'll save much trouble later on.
You should at least have a:
Repository, SVN and Git are the most prominent. Git is especially interesting with the free online git repository server github.org. check it out.
an IDE that is able to compile and debug your program.
While not needed, it is a good idea to have a testing framework.
If you've chosen to go down the path of doom, using C++ in a cross platform project, then here is where a lot of your time is eaten up. I've written serveral posts about it, and about the frustration.
That's it for this week, I wanted to write more about the actual architecture, but will be in an other entry.
Sooo... this weeks post will be less structured, it is again more of a "writing thoughts to words" entry than something new to the game... anyways.
I gave more thoughts on the engine design, also how you design as efficient as possible, how do you implement a Entity based design correctly... and it went on and on.
Suddenly it jumped my mind, I wasn't going anywhere with it, even though having experience with business application, being one of the better programmers in my college, I want to have a state of the art AAA engine design on my first try.
It won't happen.
I am young, I have a long way to go, much to learn and much to conquer.
College is a weird thing, you learn so much in a single year, that you are shocked at the stuff you have written a year ago and when you are good in your college, it can happen to you what has happened to me: It gets over your head. You think too highly of yourself.
So you do something very few people ever do on the internet. Put your ego down. You are not the best there is.
Game developing is hard, noone can tell you how hard it is, until you tried designing even a simple Iso game in more detail. The learning curve is steep, very steep and you will produce much much shit. That is how you learn, not by endlessly browsing for the best solution.
I don't say that you shouldn't try educating yourself (for me, this would be the Entity Design), you also don't have to reinvent the wheel, if you can learn from the mistakes of others, GREAT!
But if your learning process keeps you away from the actual task, programming, you should rather go ahead and make bad design choices.
Nothing should take away you actually programming something.
It kinda did for me, so I stop worrying so much about making mistakes and just do them. I will find them soon enough, then I know why the design choices were mistakes in the first place.
So to any other new game programmer: you will do badly, that is why it is called "programming experience". Don't try to learn something from a mistake you didn't do yet.
...yes, I really am that happy.
"Why" do you ask? Simply put:
IT WORKS!! HAHAAAAAAA!!!! SUCK ON THAT SEVENTH CIRCLE OF DEV. HELL!! Screw you guys, I'm going home.
(If you haven't noticed already, this entry has the Rambling tag)
It works, I still cannot really believe it, I feel a bit lightheaded from that, or maybe it's the hangover, or the chocolate flash, I don't KNOW and I don't CARE, It WORKS.
I've found my light, my saviour, my knight in shining armour. Alright that sounded a bit gay, but moving on. Hail the almighty [color=#B22222]
QTCREATOR. [/color]I finally have everything besides the coding. Everything I that was so nervewracking, i can really start to do what I came here to do: Program a game and chewing bubble gum. And I am all out of gum! DUN DUN DUUUUN!
And to beat ass, never forget to beat ass...
"So why is it so good?" QTCreator WORKS! YES! It is easy to install on all platforms I currently want to develop on (windows+debian), a QMake script is fairly easy to understand and yet the easiest Makefile generator script I've found. It as a powerful testing framework and I think the most intuitive switching between "editing, debug..." views. The editor itself is pretty much what you'd expect in an IDE these days.
It's not without it's faults, the "add library" dialogue only allows for .lib files, whick is pretty anoying for your .dlls. Sometimes the design tries to be too posh, too much "Look at me, I am a hip, cool IDE! Not your nerdy Visual Studio, nobody laughs at you when you use me!" I don't need a good looking IDE. It has to work and be productive, I don't care how it looks.
The next weeks post is a bit more structured and maybe a bit depressive, because it is not the day that you think it is. I write these entries sometimes weeks earlier. My entry two weeks ago "Watching people play games..." was written back in August. But the Context never seemed right to post it, so I always pushed this entry further back. I started writing this entry back in october, but you see this in the middle of october, I am actually writing to you from the past!!
That means, sometimes you have an outdated project update and sometimes posts that follow are older than the current post, like in this case. I actually have the next 2-3 entries almost completely written. Next weeks post is older and maybe a bit depressing, hopefully you still find some value in it.
I'm already rambling, I feel like writing some more: WTF, my post was featured? I don't know what the requirements are to get your post featured, I don't know if a human or an algorithm selects the featured entries. If it was a human, I have no idea why he or she thought the entry "Watching people play games..." was so good. I've written most of it in an hour, didn't put much thought in it and even I thought it wasn't terribly interesting. Maybe mildly entertaining, but that's it.
I don't want to bitch around, I like being featured, it makes me feel important. I just don't understand why this entry, and not one of those I actually put hard work in it.
Soooo... this weeks post originally was more on the gameplay, but first to something completely different:
As I started to think more about the engine design, I couldn't get my head around how I should switch correctly between the "overworld view" and "fight view". As it turned out, the actual problem was lying somewhere else, I don't really know what I want to achieve with the "overworld view". Before I write an addendum to the "Why is my game fun" series, I should think about what you do with what you do. And to know this, I need to be more clear about the story and the first 10 minutes of the mission...
I start to see, game design combines everything: Programming, gameplay design, story, level design, sound/music, you even care about what the gamer should feel at a specific point in the game.
The term "Game Design" makes sense, it is hard to fathom the extend of your design work you have to do. I Also learned that you shouldn't lose the overview of the whole game, and that you cannot finish programming when you don't really know what kind of gameplay you want to have... everything depends on each other.
There are two fields I didn't think much about, that also influence the overworld view: Story/Lore, which should help define the overall mood and style the game has, the music, because nothing is more teeth grinding than music that does not fit the game, and the enemies you fight. In the end, the overworld revolves around the monster activities.
What I ought to do is make a bit of a mix of what I didn't do so far, concentrate on everything else than coding and design. I think i schould look for a "game soundtrack". Nothing official and I probably won't put it in the game because of copyright. But nothing helps setting the mood like the music.
... doesn't sound creepy at all does it?
I had to write in ruby, didn't have a lot of sleep and just ate a piece of chocolate, hellllooo rambling time!
Soooo in this weeks post I talk about... what did you guess? About watching people play games.
For quite some time I've been into watching people play video games on youtube. I especially like SSoHPKC and the Creature stuff they do, but that is an other story, maybe for an other rambling post.
To those who don't know them, they essentially record themselfes playing video games and talking about random stuff.
The weird thing is, I think it does more than just entertain me, I think it helps me looking at game design from a more neutral standpoint.
"You are weird" you say? I have to tell you: I am watching people play games, what do you think I should be?!
But in all seriousness, it really does. More often than not, the commentary breaks the atmosphere of the game. "Why should that be a good thing" you say? Well, sometimes it seems games brush over bad design or bad story elements by providing an atmosphere that draws the players attention away.
Breaking away the atmosphere with the commentator shouting "SHOTGUN RAAAIIIIN" lets you notice all the dips and bumps.
The best example: try watching Call of Duty: Black ops, or COD: MW3 for that matter.
The singleplayer SUCKS! The story gets increasingly embarassing, the gameplay has stayed the same since Modern Warfare 1, the only thing that makes the singleplayer acceptable is the atmosphere. The distributed "I am so awesome" events like breaching and a few total badassery moments at the end of the game to make you forget about it.
COD: Black Ops at least TRIED to have an interesting story, they put effort in a plottwist that you maybe could not have seen coming.
But the latest MW3... seriously?! Have you ever had a knive in your heart, didn't care about bleeding, survived a World War 2 emergency medical procedure and walked around shooting stuff few days later? Was he faith healed by Peter Popoff? They didn't even try...
I couldn't watch SSoH play MW3, it just was too boring. Same shit, different day. On the other hand, watching him play Batman: Arkham Asylum was just awesome. Not only becaue he failed hilariously, but even by watching the game, I was drawn into the world of this game.
But back to watching people... play games...
Usability engineers have a technique called "talking out loud", they try to encourage a test person to talk out loud what he/she thinks while using the gui. This isn't just for shits&giggles, it helps evaluating the design, finding design errors. In other words, there are people on youtube doing exactly that for video games! For free! Day and Night!
Next week is business as usual, better structure and fleshed out thoughts. For today, I just wanted to ramble around a bit. See you soon!
Soooo... this week I write again about the boring part of developing: Software Construction
If you've read my ramblings on "The seventh Circle of Dev Hell", know that I have my problems with the toolchains for C++, so this is basically part 2 of the Dev Hell, but more structured and no random sentences. Since I don't think C++ veterans have any interest in a text of my first experiences with different C++ tools. I aim this at the C++ newbie, like I am.
I don't have a lot of experience with the toolchains, all of this are the first experience I had with them, so don't take it too seriously when I write "tool xy sucks", I havent worked with them for more than a few hours.
"What are the best tools to use" you ask? None of them, they all suck.
The Problem with the C++ tools
They are old, mostly.
As I sink more and more time into everything around the coding, I see now why C# and Java use a separate RE. I suddenly like Ant + JUnit. It is just so easy to set up build scripts and tests for your platfom, that happens to work on others as well.
I am very disappointed by the tools available for C++, comparing to what is at Java/C# disposal, they are shabby.
This is managable for a C++ newbie if you get some help from tools, like Eclipse CDT that takes care of your make files.
Good for you, but if your project should be platform indipendent, so should be your makefiles (traditional makefiles aren't afaik). And here is where the pain starts, here is where you sink too much time, here is where you have to learn more than you think.
There are tools around, like CMake or QMake. CMake is fit for the job, but you don't. It isn't an easy tool to work with, at least for me, it really starts to get on my nerves.
That's why you shouldn't use C++ for your first big project. You spend so much time figuring out how everything else besides the coding works, how you install tool XY, how do you link correctly, how the HELL do you set up a good cross plattform build environment??
Setting up such an environment isn't hard, if you have experience how you do it. I would love somebody explaining to me his/her setup why it was done that way and not otherwise...
But alas, there was nothing I could find that satisfied me. So the short story: I gave up.
I decided to not go for platform indipendece, I first aim for Linux 64 bit environment. And if the unexpected happens and the game suddenly gains huge popularity, I can make the project cross platform with roughly the same amount of work. But then, it would be worth the time.
Sooo in this weeks entry I write about the final aspect of my game:
"Real time fight" aspect
The last one of the aspects and maybe the most important one, This is what the player does all the time and this is what he should want to do even more. To me it seems like the Real time fight is connected to the other two other ones. I mean because I have an RPG part in my game and because I have a strategy part, the fighting part can be a bit more than just "point, klick, kill".
More than the other aspects, when playing a real time game, you have your moments that are especially cool.
Together with the Strategy
The "Oh SHIT!" moment:
This comes from the strategy aspect. Sometimes your plan was wrong, and the monsters aren't where they are supposed to be or aren't the monsters you thought they were. I want to incorporat the "Oh SHIT" moment in this game, followed by one of the other two moments.
I have to watch out for some things:
The Oh SHIT moment musn't be overused, or it becomes "not again..." moment.
If it happens, it has to be extra rewarding or the player just feels screwed.
It has to have the right amount of difficulty. The change is either a real challenge, or so hard that it is almost impossible and fleeing is the better option. But even when he choses to flee, he shouldn't leave completely empty handed, or it feels like the game just screwed him over and he just lost time.
The "HELL YEAH" moment:.
When all went milhouse. The player should feel accomplished
The "that did end poorly" moment.
When you died. These moments have to exist as well, or it isn't so special beating the "Oh SHIT" event. I HOPE also that it isn't so frustrating for the player, because he knew what he did was risky.
Together with the RPG
"earlier I was good, but now I am a BEAST" moment
The "real" in real time fight
What the title says, the gameplay should be real.
This was it for the design aspects/principles/dudles whatever you wanna call it. Now this is all cool, but implementing it is a different story. "So, this was a waste of time then" you might think, and you are partially correct.
It still holds some value though, while I was writing these entries, I really had to think about what I want to accomplish with this game. I mean of course you KNOW it, but when you write it down you force yourself to think about it and you run over holes you wouldn't have found otherwise.
And the main reason to this: You have a way to judge your mechanics. Using business talk, these are the requirements of the game.
Now that this is done for the moment, I have to take on an other topic of the game, even I haven't decided what it will be yet. I hope I can show you some first engine drafts, and finally some pictures. I am also writing this in advance, maybe in two weeks I have something to show you or maybe not. Only time will tell.
Soooo this weeks post is business as usual, here is the second part about the core aspects of the game.
I am currently on holiday, so there won't be a new entry next week. To compensate a bit, this one will be a bit longer, see you in two weeks!
"Strategy" aspect (planning with your friends)
That's it, basically. But since you are still reading, here is it a bit more detailed.
While deciding what to do, I always thought of the old round based Jagged Alliance series. They were incredible fun and had some cool game mechanics. The main flaw of the game to me was always the missing LAN support.
In the idea stage of the game I first wanted to go for a round based fight system. But I wanted to go some steps closer to realism than JA did and round based system allows for some weird tactics, like running out of cover, shooting and running back.
On the other hand, realtime fight today encourages the player to just walk in, hopes for the best and when shit hits the fans, screams at the checkpoint system.
Since attacks in the real world military require good planning, it suddenly struck me that I can combine the two gameplays a bit.
Unlike the RPG aspect, I don't know any game that has a similar gameplay, so I can't reflect over their choices and then make my own.
To punish and enslave
Like I wrote in the Gameplay Overview entry, I don't want to force the player to plan his attacks. I want to 'encourage' it. I want the fight to punish player mistakes. The player risks his life, having him restart at the basecamp or even worse, compromising the basecamp and losing his stashed equipment. The fight planner should help him reduce the numbers of mistakes significantly.
This seems brainkillingly trivial, but all this fails when the Planner doesn't help the players.
To be helpful, the Planner needs the right level of abstraction, meaning it will not make sense for him to plan every move and every bullet he fires. What matters is if his escape route is free of enemies, or how many enemies he attracts by firing, what his hit-chances are etc.
The other part is it has to be user friendly. Fuck-a-do-de-ly tastic. I love the user-friendly requirement, it is always somewhere in a software requirement specification and it says close to nothing. The only thing it says is that I should do user testing.
Well duh, of course it has to be fun, nevertheless important to think about. This is a mechanic that gives the game a special touch and this being a game, it must be fun. 'Encouraging' the player to use a mechanic he doesn't like... do I have to spell it out?
The main factor I can control is the ratio between fight/plan.
Since the planning should help the fighting, and also give the fighting a special touch, the player/s should not have to spend too much time planning. My target is about 3 minutes planning time for an attack. Ideally during the plan, you notice that your chosen strategy doesn't work and you have to start over. This makes the planning interesting, if it doesn't take more than 2-4 tries to get a working strategy.
Divide and conquer
This is kinda belongs to "Being fun" and "Being helpful" but i redeemed it important enough to give it a separate heading. Like in most militaries, the task is divided up into subtasks, as it goes down the chain of command. I want to incorporate something similar, so all players in a team have something to do/plan.
I wasn't sure if it belongs here, but what the heck: Important part of planning is haing a good recon of the area. I first thought of making an "automated recon", sending your character to observe a certain area for a certain amount of time. The longer you observe the more accurate your recon is.
This is a bit boring, what should the player do while waiting, play robot unicorn assault? A workaround would be to increase time speed, but then waiting has no real penalty, you set the observe time to 2 weeks, go get a drink while your character is evolving in a plant. In short: a useless mechanic for me.
It is dawning me that a part to make planning interesting, is to make recon interesting and rewarding. Rewarding is easier, I can randomly generate lost supply stashes and so on.
Making it interesting is a hard one.
I should post an entry about the recon on a later date.
Doing all this recon, planning and setting up, It can break the fight mechanic, you know where the enemies are, how to sneak by them... So no matter how good the recon was or how detailed the planning has been, I want to put random deviations from the situation.
The downside, it potentially breaks the strategy mechanic. When it is random, why would you plan anyways?
So my solution is: make small changes often (suddenly, there are 5 enemies instead of 4) and make big changes rare but important. The big changes essentially breaks the planning, forcing the player to either retreat or improvise. As long as these changes have the right rarity, the player never really feels too save, the small changes remind him there might be a big fat surprise around the next corner.
"NOT EVEN DEATH CAN SAVE YOU FROM ME"
Soooo in this weeks post I talk about the devil in development: TOOLS!
"Why tools?" you say, "Tools make the life easier" you say. NO! THEY'RE NOT! THEY ARE EVIL!
I started from the C#/Java world, and I naively assumed that there are few good, widely spread toolset that work great together for developing C++ in a Unix enviroment. But I forgot the main problem of Unix: OPEN SOURCE!
You are probably asking yourself what the hell am I rambling on about, open source is great. Let me explain:
I agree, I love the GNU licences but it is not the ultimate solution to everything like some people think. Open source also has its darksides too which I really really tasted while searching for a good workflow developing my game on linux. You have increasingly diverse tools, all working differently and having different levels of sophistication. If you have never set up a dev enviroment for C++ before, this stuff is more frustrating than teaching a cat to roll over. I spent hours searching in the depths of the web how to use different tools, just to find out that for me, they create more problems than they solve. Rinse and repeat.
I didn't get around to code very much, to be honest, i didn't code at all. Until now I had to think about everything BUT the coding. And I HATE IT! Arrrrrgh!
So you can imagine I am mad, mad at everything. Even trees. Why do they just stand around, waiting to get water? Why? GET UP and DO something you stupid piece of wood! At least entertain my when you have nothing else to do, but NOOOO, you just have to keep standing there like I am not talking to you... LOOK AT ME WHEN I AM SPEAKING!
In Java, this is somewhat simpler. Almost everything is open soure too, but you have a handful of widespread toolset with a high level of quality. You can go with either of them. Eventually you stumble over a tool/library that suits you better and will keep using that. So why cannot C++ developers move forward into this century? Why do all the tools have to be so needlessly complicated and sporadically work together?!
Few, that felt good.
Some of the problems are my own fault, I know now why other languages come with their own runtime. Everything gets more complicated when you just try to be platform indipendent.
So if anyone cares, that's what I chose for the moment:
Github repo: wow, just wow. I didn't come around to use it very much before this project. It isn't very easy when you are just used to tortoiseSVN. But man, this is thing is amazing.
QT: this tool sounds stupid, but I need a platformindipendent builder, and I don't seem to understand CMake. Plus it comes with a testing framework. CUTE just didn't want to link properly for me.
IDE: Eclipse CDT. Not what I hoped, but it gets decreasingly anoying. For some reason it doesn't want to remove popup windows correctly under Mint Debian. So I sometimes have half transparent rectangles sitting there.
CI: Jenkins. Well, not at the moment, in the future maybe when I have the rest set up and running.
Since this entry is already structure free, I might as well add this here.
I know this journal isn't the most read compared to other newer journals on gamedev.net. I also know why:
Most journals have some cool footage from their game, or at least some cool artwork to show, but I have nothing. It will take quite some time before I can even post some Techdemo. And no, I won't draw some artwork for you, it would be so ugly not even my mother would put it on the fridge.
So there is just me to entertain you, sometimes trying to be professional and sometimes saying "screw it" and just write about random stuff.
I don't know if anybody views this journal frequently, I guess people are just stumbling over my entries whenever I post a new one.
But if there is somebody who actually LOOKS for this journal: Thank you kind sir or madam, you rock!
Next week I post entries in the usual language, posting about the actual game I am working on.
So long and have a nice weekend.
I first wanted to post about all three core aspects, but then I realized it might be too much to post in one entry. Instead I decided to only post one aspect and try digging a bit deeper.
So here it is:
Part 1, The "RPG" aspect
If you were kind enough to read my ramblings about the lore, you may have noticed that you will probably start as a novice soldier and get new equipment/Skills/Level ups through the course of the game.
I get into more detail on this in a later post (very, very much later), currently they are just scribbles on a piece of paper that magically make sense to me... anyways.
These points I am focussing on came from comparing Diablo 2 to Diablo 3, and why exactly I stopped playing the sequel.
It seems trivial: "Well I did 15.8 dps before, now I do 21.1. If that isn't progress I don't know what is."
Yes, this is essentially it, but the player should not notice it while looking at the damage he does. Diablo 2 does a very good job by letting your character "evolve". For example: You start out our Amazone, who can throw a spear. After 10 levels, you can throw a poisonous spear, after 10 levels more a lightning spear, after 30 levels more a lightning spear that breaks into more lightnings.
The fun skills were the ones that "evolve" as well. The Amazone had a great example,
lvl 1 skill: can throw a lightning spear that breaks up into one other lightning.
Lvl 20 skill: can throw lightning spear that breaks up into QUAZZILLION F*CKING LIGHTNING STORM ULTIMATE KILLAARRR.
In the end yes, you only did more damage. But you also hit more enemies AND you looked badass while doing so.
"This will be SWEET" times
In my opinion, this is the most important aspect in the early game, I want the player to be excited about a future skill/future crafted weapon the player can have. The player's character cannot start of with the coolest abilities, but he needs a reason to keep playing. If the user doesn't at least say it in his mind, it did something wrong.
to explore possibilities/to punish and enslave
you get the best illustration these two oposites by comparing the skill system of diablo 2 and diablo 3.
Diablo 3 let's you freely choose and rechoose your skill. The good side of this is that you can explore possibilities, what works best etc. You cannot do anything wrong.
The bad thing is, you cannot do anything wrong. Why would you play up a second barbarian, the only difference between the first and the second one is the gear, which can also be interchanged.
Diablo 2 took the other side of the extreme, it punished you for bad skilling/bad attribute distribution, your character was weak in comparison. And because the skill system was very complex, you would make many, many mistakes before you would even come near a good skillset. This will easily throw off new players.
Now, what will I do?
Definitely not the Diablo 3 way (how can you even justify selecting a few skills from a big pool? Is your character too stupid to remember more than 6 at once?).
I haven't decided yet, I will analyze the reason why the system was so complex, and maybe give the novice player a little boost. But I definately want to punish the player for making skill mistakes. It is frustrating, but the player will continue playing as long as he feels it was "his" mistake and not the one of the game. Finding his optimum skillset will be far more rewarding.
So, this was it for the first part, stick around for the second part soon. What do you guys think about Diablo 2 and 3, what was good/bad?
Soooo this week, I am writing a bit about the raw drafts of the gameplay. I first wanted to post an entry about design principles, but I realized, it is hard writing about design principles for a game, if you don't know the basic gameplay. Don't worry, you will see the posts about the game design principles, I will simply post them a week later.
Before we dive into the whole game and stuff, I want to add that this will be a multiplayer game, if and how there will be a singleplayer component is not yet decided. But this game isn't aimed to be an MMO, it is thought to be a "Lan Party" game, with your friends in hearing range, or at least available over teamspeak. I won't care about voip support in-game, I may not even care about a messaging system.
If you read last weeks babble about the first drafts of the lore (thank you very much), if you guessed you would start the game as a young RSR recruit, you were correct. The tutorial and character creation process will be in the RSR bootcamp. Then, you and your friends are sent out to your very first mission.
From your secure base, you can select the gear you take on your journey. You will need to take different weapons with you to be prepared for different tactics/enemies. But you are limited in the size of your inventory and the weight. You then can move around the overworld (as long as you don't step into a trap ). You then can set up your base camp and stash your equipment you don't need. From there, you can move more quickly and if needed, set up a preliminary camp with some supplies (like ammo).
These are the basics, from here the game can be split up into three groups:
Your character can choose a primary and a secondary role out of 3 roles: Assault, Assassination, Ambush.
This decides what weapons and skills will be available later. This means I will have 6 different set ups for a character (Yes this text is a bit meager, but I will expand on the skills, equipment and other stuff soon in a separate entry. Posting this here would explode the entry).
You shouldn't storm in a position guns blazing. Well you can, but you may get you and your friends killed in the process. It is encouraged to first do reconnaissance of the area and think about what to do. You can choose 3 basic tactics: Assault, Assassination, Ambush. Depending on your available equipment, skills and the monsters you face, you can start mixing tatcits. You also need an escape plan. To shake off a hunter groups, or in case your plan goes wrong.
After planning, you start the attack. You have your waypoints laid out, you know where the enemy should be hiding and how strong they should be. The bad thing is, recon is never a 100% accurate, there might be unexpected changes, for example a group of monsters twice the size they should be. Then you have to improvise, or bail.
The enemies do also not just stand around, if they know you are in the area, they are starting to search for you. Or if an attack went wrong and you had to bail the alerted enemy, they will sent hunter groups after you. And those hunters are fast on their limbs.
If they locate your base camp, they will destroy it with all its contents. But when you go to your basecamp and take the supplies, you move slower. So don't try to really mess up.
So this was it for the overview. Next weeks entry will be about gamedesign principles and after that I will focus more on the subparts.
This is a small Update on the Lore of the Game. If you find some parts cheesy, please let me know. I first want to emphasise what happened to the World and the humans to have a solid basis to work from (and dream up more stuff later).
(If you don't care about it, come back later. The next post will talk about the gamedesing choises and analysis. Later on about monsters, and maybe soon some first drafts of my own little engine ;))
The Fall of the old World
The history of these events are shady, most documents and footage got lost after the powergrid collapsed, so this is put together by word of mouth of the survivors.
It all started to fall appart when the Yellowstone vulcano erupted, shooting up so much volcanic ashes in the skies that it blot out the sun.
They weren't afraid, the people have been preparing years for this event. But then, "They" came. The demons, monsters, beasts, they were called, only leaving death and ashes. "They" came up from everywhere and nowhere. Apparently, nobody ever saw them coming. The Generals were mostly occupied with trying to figure out what country they belong to, instead of mobilizing the armory they had at their disposal. Once their communication broke down, there was nothing to stop these beasts.
The humans fleed in all directions, some were lucky enough to flee to the mountains and search refuge there. For some reason, they didn't follow them there. Others fleed to the seas, never to be seen again. No one knows if they starved, or found a save island.
No government has survived the fall either, once great countries have been reduced to a name for that particular piece of land.
The new World
Now 23 years after the erruption, the humans have set up Strongholds in the mountains all over the world, by far the largest is in the Himalaya where the majority of the humans live now.
The former Swiss Military has built huge underground bunkers, big enough to host armies. Now they host majority of survivors of Europe. They also have the largest supply of military equipment.
In North America managed to rescue many helicopters and have the most mobile force.
Each stronghold is indipendent and has it's own governing system, but their military forces are united under acommon name and leadership: "the Rising Sun". They all fight together to bring the sun back, send the monster back to the hell they came from.
The name "Spectre" originated from a legend in the eary days of the fall. A team of elite soldiers defeated the first wave of attack on a Swiss Nuclear Powerplant. The engineers never saw the soldiers, nor did the people of the nearby town, but through their action, they were able to shutdown the reactor and flee to the mountains. Thanks to word of mouth they became legends, they called them "guardians", but as the story got translated into english it became "Spectre".
In honor of these unknown Soldiers, the RS gave called their elite soldiers specres.
They are few but experienced, well trained and well equipped.
A spectre is not allowed to retire until 'the humans have won the war', not that any spectre has lived up to the retirement age.
RS Army and the LSR
Even though the Rising Sun still has some traditional forces, they are rarely send to combat today. Only when the Spectre did an extensive recon operation on the target and only if they can get in and out of the battlezone quickly.
RSR stands for "Rising Sun's Raiders", they started out as a advanced training group for future Spectre soldiers and have now become the military's main forces. The new recruits almost always start in the RSR Regiments, working their way up and maybe, if the soldier is dedicated enough (and survives) he or she gets promoted to a spectre.
The regiments have a solid training program, but are notoriously under-equipped. To reduce further loss of weapons and supplies, only the experienced soldiers receive good equipment, meaning that an RSR Soldier doesn't get what he needs, but what he deserves.
about the journal
2d Artist needed
about the game "Project Phoenix
Hopes and Dreams
I am a normal IT student in a land far far away who has put an idea into his head. V thaught us, that ideas are bulletproof and now it's kinda stuck forever. The idea, to create a world.
About the journal
Here I will write EVERYTHING (well, almost, but I try hard), from posts about the lore, up to design choices in the engine.
So why should I put so much time writing about that stuff, if I could code?
Well, this project will take a long time and when I have people interested in my work, I won't abandon it. It is also a great help for me writing down ideas and concepts in coherent sentences, not just as half-assed scribble on a dirty sheet of paper. Plus, I have the chance that somebody will eventually read this and maybe find some value in it.
I will update this Journal at least every two weeks.
If you have questions, remarks or even critic about something, please leave a comment. Feedback is the best way to improve.
2d Artist needed
Yeah, what the heading says.
About the game "Project Phoenix"
Yes, my project is called "Project Phoenix", to reduce confusion, I won't use the word "project" in my posts.
I haven't worked out the lore yet, but I can give you an overview:
Project Phoenix plays in a post apocalyptic world, where the humans fight for their survival. You are (of course) a human, you fight in a 2d real-time isometric shooter against an enemy more powerful than you are. To succeed, you need to work as a team, plan your attacks, assasinations, ambushes carefully and improvise in case shit happens.
So yeah, it is a multiplayer game at some point in the future...
The game engine is my own, I work with SDL and later hopefully with OpenGL. It is free to play and the source code is open.
Hopes and Dreams
You see, I hope to make an interesting game from the ground up. Even though I have programming experience, I never had a project this complex. Further, it doesn't take a good programmer to make a good game. A good game is more than code.
Even though I work hard, I expect something more than a tech demo in a year maybe. And I will have to put the project on ice temporarly when an examstorm is brewing, but I promise to pick it back up afterwards.
So here I am with an ambitious project with ambitious goals... what could possibly go wrong?