Jump to content

  • Log In with Google      Sign In   
  • Create Account

Bluefirehawk's: "Path to World Domination"

The boring part of being a Developer or: Why I failed

Posted by , in Info, Coding, C++ Endeavor 28 September 2012 - - - - - - · 1,401 views

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.


What makes my game fun? PT 3.

Posted by , in Game Design 21 September 2012 - - - - - - · 850 views

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.


What makes my game fun? PT 2.

Posted by , in Game Design 07 September 2012 - - - - - - · 767 views

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.

Being helpful
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.

Being fun
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.

Recon
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.

SURPRISE!
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.





September 2012 »

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
30      

0 user(s) viewing

0 members, 0 guests, 0 anonymous users

Latest Visitors