Sunday, December 8, 2013

Three?!

Came up with an idea for a new game. A third one.

Turns out it's a lot easier to come out with ideas for games than actually making those games (duh!).

I'm already working on 2 games at the moment (more on them next week), so why would I want to work on third one? Did I mention I also have a full time job?

Well, there are pros and cons to every decision. And when there's so much you want to do - the decision is made a lot harder.

But there are advantages to developing that third game. The stuff learned through its development would be priceless and would serve me greatly when coding multi-player into my third game (the biggest of the three).

So, should I go for it? Try and create three different games simultaneously?

I still don't have an answer for it. At the moment, I'm working on a demo and design for my new game. At some point I'll have to decide. Some point soon. Not yet, though. What do you think? Should I go for three, or stick to the two I've already got?

Sunday, November 3, 2013

I'm back (again)...

So, it's been a while...

Yeah. It seems that the old saying is true - when you least expect it, life kicks you in the ass. That's the old saying, right?

Anyway - starting a new job; moving to a new place; the sudden, unexpected death of my mom; - they all took their toll. And since I had to deal with all of them at once - everything else had to stop. I had less time for friends. I had less time for TV. I had less time for sports. And, of course - I had less time for developing games.

But!!!

Life goes on.

Everything that happened - happened. It took a while, but I got over them, and I'm ready to get back on the horse. Oh, how I missed the horse...

Getting back on the horse actually takes some time. I had to open old projects, and read my own code. Everything seems easy and obvious when you write it, but when you look at it a few months later, all you can think is "what the hell is this shit?!"
No, it's not that I did a bad job. It's not that I didn't know what I was doing. It's just that it takes some time to get to the same state of mind you had a few months ago. It takes time to remember all the little decisions you made a while ago, and didn't document because they're so obvious you'll never forget them. Well - you do. So, never count on your memory - document everything!

You can also forget about all those fancy Gantt charts, and those precious timetables. Sometimes, life gets in the way. And you can't run away from life.

So, of course there will be a delay. Of course timetables and Gantt charts will need to be updated. Am I upset about this? No. That's just the way things are. The games are still being made, and that's all that counts.

I'm back, bitches!


Wednesday, May 29, 2013

Plot - what is it good for?


Turns out - story is an essential part of every game. Or - is it?? Do you really need a plot (even a bad one) to play a game? Would it change your game experience if one never existed? Or, if it was simply awful or boring? And besides - what do stories and games have in common? Why mix them at all?

Let's start at the beginning: what constitutes a story and what constitutes a good one?

According to Wiki, a narrative (story) is "any account that presents connected events". Well, sounds simple enough. And then it continues: "Narrative is found in all forms of human creativity and art, including speech, writing, songs, film, television, video games, photography, theater, and visual arts such as painting".

Now that we know what a story is, can we recognize a good one? Obviously, "good" and "bad" are subjective feelings, and so it's harder to mark a story as either one. Sure, there are some rules (like structure, character, plot, them style and so on) that help make a story better, but none of them are definitive. Following all the rules won't necessarily make your story a good one. Someone may still not like it.

So, how do we define a good story?

In my opinion - you can't define a globally good story. A story may be good in your eyes, and bad in mine. You may like it - I may not. But it's not just you and me that are different. I may like a story today, and hate it tomorrow. Your feelings toward a story may change with time.

So, we can't. A story can't be defined as good or bad, as an absolute thing. Same as art. Probably because stories ARE art.

Now that we know what stories are, let's talk about their role in video games.

Humanity always had a thing with story-telling. It's almost a burning need we humans have, to tell a story. And we'll use every new piece of technology to do it. Cavemen used paint and color to draw on walls, while Egyptians carved them in stone. The moment we learned to speak - we invented the theater. Later, we drew on canvas. And as technology advanced we used books, paper and photography to tell stories (comics are part of this stage). Then it was radio, TV and the internet. So, given all those forms of story-telling, why not one more? It seems gaming is - at the very least - a valid platform for story-telling.

But, do stories make games better? Let's compare some popular games: Pong and Tetris vs. Mass Effect and To The Moon. It's obvious two of those games are story-oriented and wouldn't survive without it. To The Moon, for example, has almost no game-play, except for following a sad story. But it's still a great game. On the other hand - Pong and Tetris have no story in them - and they're very popular (still are). So, how can that be? Is the plot of a game good for it, or bad for it?

in my opinion, video games stand on various legs. The more legs a game has - the better. The stronger the legs - the better. These legs are graphics, music, game-play, UI, design and so on. The story is just one more leg. If it's good - it will help lift the game. If it's bad - it will harm the game. If it's missing - other elements may cover for it.
In conclusion - stories add to the game experience, but they are not a must if the game is good and compelling enough without them. Done right - they do add a lot to the game.

That dilemma came up when working on my own games.

One of the games is an interactive story, so of course story is an important part of it. Actually, it's the MOST important part. Everything else is just there to serve the story, so not only does the game need a story - it needs a GOOD one. A very good, compelling story. Otherwise - the game will crash and burn. Being an interactive story, the other elements of the game, aren't good enough without a good story. It's a good thing I'm working hard on providing one!

As for the other one - that was a real dilemma. You're flying in space, shooting bad guys, doing missions. Do you really need a background story for that? My personal advice - yes, you do. At the very least - it can't hurt. At it's best - it will make your game better, more memorable, and most important - more fun! It's a lot more fun if you have a reason to shoot the bad guys. Not just "because they're there", but because you hate them, and want them dead. Once you have that - a feeling inside you that relates to the game - you're more connected to it. And the more connected you are to the game - the more you enjoy it.
And how do you get someone to feel something towards a video game? You add a good story to it!

Till next time, have a good night.
-Shay

Sunday, May 5, 2013

Postponement!

The 1st of May was supposed to be the day I launch the new retro site. A glorious day. A day to remember and celebrate. Working late the night before, I realized I won't be able to meet the deadline.

Technically, it's not so bad. The deadline has been postponed to the 10th of May, and not harm was done. No-one knows about the site yet, so no-one got upset. No-one was waiting for it. Nobody cares.

But me...

To me, it feels like a personal failure. Sure, things like that happen all the time. Deadlines move. Projects get delayed. Sometimes it's nobody's fault.

And yet - I still feel as though the weight of it all is on my shoulders. And so is the blame. I was the one who didn't make the deadline. I was the one who didn't get the site up on time. It was all me. And only me.

That being said - there's nothing much to be done about it. The site wasn't ready, and I prefer to delay it a few days and launch a better site, then meet the deadline and launch a broken one. Launching a broken site (even if it's a first version of it) is a bad business decision. After all - your website is usually the first thing people see. It's the face of the company. And if that's broken - so is the first impression. And first impressions are hard to fix.

So - the 10th. It's this weekend, and I'm working hard and fast to meet that deadline. Don't want to delay it any further. Keep your fingers crossed.

Tuesday, April 30, 2013

Going public

As I write this, it's half past midnight, Tuesday night. We're set to go live tomorrow,
Wednesay, the first of May. And the pressure is on.

And it's not just the fact that there's a lot of work to be done between now and then. A LOT of work. The site is not ready, I haven't even started working on the Facebook page, and will I be able to get a mobile site up as well by tomorrow?

Lots of tiny things piling up at the last minute. Details. Things you never thought of. Work.

But that only adds up to a small part of the total pressure. The bigger part is the coming out part.

New Retro Studio has been up and about for a few months, but up until now, it's been kept a secret. Only a handful of people know about it. And tomorrow - the world will know. My friends. My family. Co-workers. Strangers. Everyone.

Tomorrow they'll be able to support, encourage, ridicule, mock, help, ignore...

Tomorrow they'll know.

It was easy keeping it under wraps. As long as it was my secret, I had no commitment. Now, the eyes of the world - for better and for worse - will be watching. And judging. And I'll have to accept that. And live with that.

So, yeah, tomorrow's a big day. Let's hope it will be a good one.

-Shay

Thursday, April 11, 2013

2 games?!

Is is possible, really?

At it's base - New Retro Studio was created to make games. Not one game, but games. Plural.

But when it was created, no one thought about more than 1 game at a time, at least until we'll make something of ourselves.

In the last couple of days a new idea came up. An idea for a new game. One that is completely different from our main creation (the space sim). But can it be done? Can we make 2 games at the same time? Especially considering our small production team?

Well, that's a question I've been debating on for the last few days. There are pros and cons for each decision.

The main problem will be the allocation of resources. If the developer is working on one game - he's not working on the other at that exact time. Same goes for the artist, the writer, and so on. In a small production team, the people are our most valuable resource. That's the resource we have the least, and therefor, the one that'll create a bottleneck in every production cycle.

There are other issues. Focus, for example. You want your artist to focus on one game, and not two, otherwise things may effect one another. Let's say you have 2 games: one a child's game with lovely pink unicorns, and the other an adult dark story, with blood and gore. Working on both, at the same time, you may find your pink unicorns a bit too dark and scary for a children's tale.

The sulotion is simple: more people. Have 1 artist working on one game, and another on the other. But in the real world, where money (and therefor - people) is scarce, that is not a real option. At least, not for now.

So, what to do? Give up on the second game? Delay it until after the first game is released?

Well, turns out the answer is a bit more complicated.

The first game - the space sim - is already planned out. Right now, an artist and a developer are working on it. The second game - an interactive story - is simple to program, and won't take much of the programer's time. Most of the work will be done by the writer, and the artist. And turns out - our artist can't do the type of work required for that kind of game, so another artist will be required.

That lead me to believe, that although it's a completely new game, there won't be a loss of focus. The programmer will be working on game 1, and artist #1 as well. Artist #2 will be working on game 2 with the writer. 2 games, but with different people working on different tasks.

So, the decision is this: we're working on 2 games!!!

Stay tuned for more details on both games, coming up soon.

-Shay

P.S. - sorry for being away for the last month or so, but I've been dealing with work issues. Those are fixed now, and we're back in business. Expect more frequent posts in the coming weeks.


Wednesday, March 13, 2013

What did I learn?

(Reposting this, since posterous is closing its gates)

Turns out - a lot!

Let me be clear: starting an indie game studio, developing your own game from scratch, shipping, selling, and actually making profit - never seemed like a small task. It always seemed like a monumental project. It did.
But only when I actually delved into it I started to realize how big of a task it actually is. The amount of work that needs to be done is just... amazing! This is not a one-man-project! 10-men should work on it! And even then, they'll be swamped!
You might think I'm exaggerating, but I'm not. The task really is THAT big. So, what do you do? How do you deal with that many items on your to-do list? How do you handle such a large project? We'll get to that...
But first - what do you actually have to do?
Well, the list is long. But it boils down to this:
  • Game design.
  • Art design.
  • Coding.
  • QA.
  • Marketing.
  • Publishing.
  • Misc. (Trust me - there's a lot of misc)
And now - it more detail:
Game design
Game design is the first stage. That's probably the ONLY stage in the process that happens independently, before all other stages. In this stage you have to think what kind of game you want to create. Is it going to be an FPS? An RPG? An MMO? Other type of game that's not described in three-letter-acronym? (For those of you not in the gaming world - FPS = First Person Shooter, RPG = Role Playing Game, and MMO = Massive Multiplayer Online)
But that's not all. The game - YOUR game! - doesn't need to fit in those pre-established definitions. Your game can be something completely new. Or it can be a combination of a few genres - an FPS with RTS (Real-Time Strategy), for example.
Deciding what type of game you'll create is the most important step. Some consider it the easiest, since you only have to decide on one thing, and not actually do anything, but it's quite the opposite. The decisions you make here will set your path from that moment on. Make one decision - and you have one game. Make another - it's a completely different game! And a completely different development process.
So, choose well. Take the time to think things through. What kind of game do you want to make? Can you make that kind of game? What will it require? Is it just a copy of another game (that's not necessarily a bad thing - a lot of games are just clones of more successful ones)? What does it have to offer to other players around the world? Will it sell? Will it be fun?
A lot of question to answer, but once you think them through, and answer all of them - you know one thing (and just one thing): you know what kind of game you're going to make. And that's step one.
Art design
So, you know what type of game you'll create. That's great. Now it's time to decide on how it'll look. Many different games - all of the same genre - look and feel different. That look and feel are the responsibility of the art department. More precisely - the art designer. Again, this is a very important step, since games can rise and fall on their looks alone, and deciding how your game looks will effect the end result - how much will it sell.
Let's say you've chosen a first person shooter. That's a great choice, since those are always very popular. Well, here are two very famous FPSs: Doom 3 and Farcry 3. In Doom 3 you play a marine on a mars colony attacked by zombies and ghosts. The game is very dark and gritty. A lot of the time you're walking alone in the dark with only your flash light to light the way. And of course, you jump in your sit screaming when something awful jumps at you from a dark corner.
In Farcry 3, on the other hand, you play a teenager in a tropical island. The game takes place in broad daylight, and your enemies are mostly bandits (humans) around the island.
Both games are first person shooters, but they look and feel completely different, and it's up to you to decide how your game will look like. You have to choose color palettes for the game. You have to choose settings, styles, and so on. But that's not all. Doom 3 is scary because the story is scary (zombies and ghosts are scary, right?). Do you know your story yet?
Another part of the art design is the story part. You have to sit down and write your game's story. What is it going? Who's against who and why? How is it going to unfold in front of the player? How will the story progress as the game progress? How will that affect the gameplay?
Story telling is part of your art directing. Your story will set your tone. Your tone will be shown with the proper art design, colors and settings.
Coding
Coding - as I see it - is everything you need to do to get your game from concept and art, to an actual product - to something you can play.
Basically, every game is built of 2 important items: game engine, and levels.
Game engine is the thing that makes everything possible. The game engine handles your mouse and keyboard clicks, plays sounds when appropriate, renders everything you see on the screen, "thinks" for your opponents, and so on. Basically, it handles everything that goes on in the game. But, having an engine alone is not enough. You also need to give it something to do.
That's where levels come in. Levels are sections of code you insert into your game engine that tell it how to build your level for you.
For example, in the original Mario games, you had levels that were above ground, and levels beneath it. Each of those is a completely new level you need to design. When your player starts playing, you load one of those levels into your engine - and the player can play it. Once he's through it - you load another one into your engine, and the player can now play that one.
You only need to build one engine, but you can build as many levels as you want. The levels themselves actually depend on your story. They are there to help you tell it, and should only as long as the story does. Once your story is over - so should the game.
In order to make all that happen you have to write amazing amounts of code. Code that will make it all work. Code that will make thousands of little pieces of software work together perfectly. And it's not an easy task. You'll have to spend hours and hours on that. In fact - coding is the hardest (and longest) part of your game development. It will suck up all of your free time. And if you're not an experienced programmer when you start coding - it'll be a while before you can get anything real going.
Quick tip: don't write anything you don't need. Meaning: if someone else did it already, and it exists out there - use it. If it's free - no problem. If you need to buy it - consider it. The less code you have to write (and test, and debug) - the better for you.
QA
Stands for Quality Assurance. I always thought QA wasn't a real job. It's not really necessary to have a QA on staff. I mean, we - the programmers - check everything we do. If it's not right - it simply won't work, right? Right?
Wrong!
Dead wrong, actually. Like I said before, your game will be a piece of software made up of thousands little parts working together to create a great experience. How can you expect them all to work perfectly, right off the bat? Things are bound to fall apart. Things will not function. Things will not work as expected.
But here's the kicker: the programmers won't notice. The programmers are so busy testing their newest feature they rarely have time to look at the whole picture. Not only that, even within the confines of their own tiny feature - programmers miss a lot of bugs.
In the simplest of terms - it's the QAs job to catch those bugs before the client does. A buggy software is a bad thing. Critics won't like it. Customers will hate. And everyone will recommend on not buying it. It may be a great game - but if it's buggy, playing it will be frustrating.
Marketing
Marketing is probably the section that needs the least explaining. Everyone know what it is. Want an example of good marketing? It's simple. Do you know what "Coca-Cola" means? It's that black drink that comes in red cans, right?
The fact that almost everyone around the world knows what Coca-Cola is, means people at Coca-Cola are doing a great job, for years now.
You'll have to do the same. Probably not on the same scale, but still the same. I mean, it's great to develop the greatest game of all times, but it's kinda useless if no-one's aware of it. And if no-one's aware of it - no one will play it.
So you'll have to market it. And you'll have to do it early on. Right as you start working on it. Blog it (that's what we're doing here...). Talk about it. Let people know it's coming. Let them know how it's doing. Share.
If people will know about it, they'll spread the word. They'll wait for it. And eventually - they'll buy it. And that's what we all want.
Publishing
Just as Game Design was the first stage and had to occur before all other stages started - publishing is the last stage, and can only occur after all other stages ended.
But it's the last stage!
And if you've made it this far - congratz! You're ready to capitalize on your hard work. Finally!
Well... almost.
Publishing is just as important as any other stage along the way. And the way you publish will eventually decide how much money you earn. There are several different way to publish. You can publish independently - having customers pay you directly. You can publish through a service like Steam. You can publish through game portals. And so on.
Deciding where and how to publish is an important decision you should consider carefully when the time to publish arrives. But the good new are just around the corner: once you publish - all you have to do is sit back and enjoy your profits. Not!
More on that later.
Misc.
There's a lot of miscellaneous tasks to do that don't fall exactly into each category. There's legal work to be done (you'll need a lawyer for that). There's accounting. There's debugging. There's learning. There's a lot to do.
And the work doesn't end once you ship the game. It only starts there!
***
So, where do I stand? How much of that list did I actually do?
Not much, apparently.
I'm at the point where game design is over, and I'm starting coding and art-work (got my own graphic designer for that). It'll be a while before I get to publishing. But I'm guessing that's part of the fun, right?
And although the list may seem clear and obvious to those reading it for the first time - it's not. It took me a while to get here. A long while. There's a learning curve here - you're not born an indie developer. You'll have to become one. Even if you have experience in many of the fields required - you need to have them all. That means - either hire someone to do that job for you - or learn how to do it yourself.
If you can't draw - hire an artist, or draw yourself, taking into account the game will have crude graphics. The decision is not easy, since not everyone has the funds to pay someone else's salary, and some crude drawings may be too crude. We'll get to the money issues on another post, though...
On future posts I'll delve much deeper into each and every one of those issues. I'll explain what I've learned, and how I plan to implement it in my own game. Like I said - I got a lot to say.
Good night
-Shay

Saturday, March 9, 2013

Day job

It's been a crazy week. Most of it due to some chaos in my day job.

Some background: I work as a software engineer for a large high-tech company. That's my day job. I go there every morning, and come back every evening. And then I start working on the game.

In the last couple of months things seem to go wrong at the place I work. So much so, I'm actively thinking about looking for a new job. And that fact, got me thinking. Why the hell do I need a day job? Am I not an indie game developer? Isn't that my job?

Well, the short answer is: no, it's not. The slightly longer answer is: no, not yet.

Here's the sum of the dream: we make an indie game. It makes enough money to make it worth it to quit my day-job and make more indie games. Those games make enough money to make my studio bigger. Hire more workers. Make bigger games. Better games. Make more money.

That's the dream, at least. The goal.

So, if my goal is to work as an indie game developer, or as a studio CEO, why do I keep my day job?

The simple answer is, of course: it pays the bills. I have my own place (and it's a sweeeet place). I have my own car. My dog is well fed. My girlfriend gets nice presents (when I feel like it). The electricity is always on. I have hot water. The fridge is full of tasty things. And so on...

But, is that the only reason?

No. My day job pays for this pc. It enabled me to buy a domain for my company. I pay for software. I pay for hardware. And I can sleep quietly at night.

Simply put: my day job pays for my night job. More specifically: my day job pays for my dream. My day job enables me to dream.

I don't know how long I'll need to hold on to my day job, but until my night job makes enough money - I'll have to keep my day job. Hopefully - it won't be for that long.

-Shay

 

Sunday, February 24, 2013

Logo work

New_retro_logo3

 

New Retro Studio, finally has a logo!

Creating a logo for your studio is not an easy thing. First off - you have the money issue. Are you paying a professional logo-maker (that's an actual job!) to design and create the logo for you, or are you doing it in-house, saving a few precious bucks?

In this case, I went with the latter. Money is scarce here (did someone say kickstarter?), and we have to save it for the important stuff. The company's logo, though important, is not vital. A bad logo might get some criticism, or be mocked, but it won't affect the sales of your product. Your product will affect the sales of your product!

With that out of the way, remains the issue of actually doing it. How do you design a logo?

I wanted something simple. Something that meant "New Retro" without being too loud. Something I could use over and over, on every site.

I've decided to go with the letters NR, giving each letter a different look. Some trial and error later, and the N became metallic, while the R was carved out of wood. A white spot light finished the look.

I rendered out two version: the big one, displayed at the top, and the smaller one, attached below. The big one is the official version. A short movie will be made, based on that.

The smaller one is the one that can be used as an icon, avatar and so on. I'm guessing that'll be the one you'll see the most. It's not an exact copy of the bigger one. The reflections are off, and the lighting is a bit different. Still - same logo.

 

New_retro_logo4

But here's the thing about make a logo: it's one of those things you rarely think about when you decide on making a game. It's just one of those many small things that suck up your time unexpectedly. And the list is endless.

Anyway, endless or not, check one off the list!

 

-Shay

Sunday, February 17, 2013

First Concept Art

2013-01-25_14

So, my talented (and cute) girlfriend has finally decided to draw me some spaceships.

Mind you - that's a girl who knows nothing about sci-fi, spaceship et cetra.

So, for the last few weeks, I've been forcing her to watch all kinds of sci-fis with me: Star-Trek, Star Wars, Battlestar Galactica, and so on.


She loved some of them, got bored at others. But that didn't matter to me. My goal was to make her see space ships. Lots of lots of spaceships. And she did.

And now she finally started drawing some of them.

It's not as easy as it seems. Especially to someone who's not familiar with the source material. That's both good and bad. On the one hand - she doesn't know what to draw. She doesn't even know where to start. On the other hand - she's not compromised by "common" things. The ships she draws are different and unique.

That said, I chose to display two of the ships she drew that don't have that quality in them. Why? Cos I want the game to be familiar to anyone who's familiar with the genre. I want players to look at a ship and say "yup, that's a ship."

Here's another example:

2013-01-25_14
I like them.

-Shay

Saturday, February 9, 2013

Competition!

I never expected to be the only one. Everyone knows that the gaming industry is highly competitive and rough.

But I did have an advantage (not the only one): I was about to make a game in a "dead" genre. A type of game that existed in the 90s and is gone. I was about to revive it.

And then, about a year ago, someone got ahead of me and tried to do it. The game I'm refering to was Sol Exodus by Seamless Entertainment. The good news was it was a bad game. Not close to being good enough, and not close to matching me own idea. That game won't revive the genre.

And then I find out that a few more similar games are coming out! 2 came out last week, and a major one has already found its founding on kick-starter.

But - is it bad news? What does it mean for my game?

Well - I don't know.

If those games come out, and become big successes - they'll imply that there's a market for that kind of game. People are willing to pay for it. Assuming my game will be better - that's good news.

If those games fail miserably - still good news! It only means something went wrong (maybe the games sucked?) - but it doesn't mean no-one's interested in the genre.

There are many more options, but the bottom line is this: I can't tell. No-one can. But, although more similar games on the market mean more competition, it can also mean good sales and good reception.

Let's hope so.

-Shay

Saturday, February 2, 2013

To The Moon - Game Review

To_the_moon-launch-poster-lrg

This is an interesting time in gaming world. Making your own indie game - crazy as it might be - has become easy enough so that anyone can do it. And since anyone can do it - we get tons of new games, of all kinds and varieties. Games that the big companies won't produce. Won't pay to produce. Games that are different.

And different is not a bad word.

One of those games is "To The Moon". Calling it a game is really a stretch. More like - an interactive story. You don't fight. Don't shoot anyone. You don't jump from platform to platform. You don't collect items. You don't make money, or buy items. You don't actually do anything! Except, follow the main story...

And that's about it. You see the story unfolding in front of your eyes. You read the texts, follow the characters, listen to the music. Most of the time, you just click through the conversations. Once in a while you solve a minor (very minor) puzzle that takes all of 5 seconds to complete. And that's it.

To some of you, that may sound like a bad thing. It's not.

Without all these distractions you can really let the story draw you in. You can focus on the plot completely, and ignore all distractions. And it works! The story feels really sad, and you get to identify with the characters and their pain.

The story revolves around an old man named John. On his deathbed, John makes a final wish - to reach the moon. In the game, a technology exists that allows to implent memories inside peoples' heads.

Enter Dr. Rosalene and Dr. Watts - our 2 officials come to fulfill John's last wish - at least, in his head. In order to do that, they plug a machine to his head, and enter his memories, going through them, from his latest (old age), to his earliest. Their goal: reach an early memory and implant the idea of getting to the moon there. Kinda like "Inception". On the way, they get to know the man, and see interact with his memories.

Most important of all - they get to meet his deceased wife, River, the love of life ever since he was a kid. 

Following the trail of memories is a painful process. At first - it seems strange and intimidating. But as the journey continues, we get to know John and River better. We get to connect to them, and to understand them. And when things start to clear up (after several hours of playing) - emotions start to emerge.

All of that is achieved despite of a century-ago-graphics, and despite repetitive music (which does set the right tone). Quite an achievement.

I've played the entire game with my girlfriend, who's anything but a gamer, and even she enjoyed it. Probably because it doesn't feel like a game. We should probably broaden our definition of a game now...

The game clocks at about 6 hours, and although it's more of an interactive movie than a game - it's a fun experience, well worth the 10$ (cheaper than a movie, lasts longer).

4/5 - go get it.

Have fun getting to the moon

-Shay

 

 

 

Sunday, January 27, 2013

Time to get to work.

760305-old-book-and-reading-glasses
So, for the last month or so, all I'm doing is reading. A LOT. I'm reading blogs, books, forums, posts and what not. You name it - I'm reading it.

And it's nice. It's good. It's easy.

And that's the problem.

Reading is easy. Too easy. When you read you don't have to think. You don't have to invest. You don't have to do anything, actually. Just... read.

And that's not good enough. Reading won't get your project off the ground. Reading won't write your code for you. Reading will get you nowhere.

Of course, I'm exaggerating. Reading is good. It puts some knowledge in your noggin'. But reading is not enough. At some point - you have to stop reading, and start doing.

I've reached that point.

I have all the knowledge and know-how I need. I don't need to see more code examples. Don't need to read more documentation. Don't need to read another blog-post. I don't need.

It's action time.

So, reaching that conclusion, I've put my reading glasses down (metaphorically speaking, I had laser surgery years ago), and started coding. Started creating.

The results are coming up soon, I promise.

 

Have a great day

-Shay

Monday, January 21, 2013

Book review: WPF 4 Unleashed.

0000

 

So, it seems I needed to learn some WPF.

It wasn't my favorite choice, but once I decided that WPF is the way to go - I had to learn it as fast as possible.

This part - the learning part - is the hardest part. You sit around, reading a book on your kindle, PC, or actually holding one in your hand. And it may be interesting (not all technincal books are interesting) - but you still have this nagging feeling that you're not actually doing anything. You're not working.

Well - that may be how you feel, but it's not true. In order to create any piece of software you have to work in steps, and if step 1 is: "learn WPF" - than sitting at home reading a book is the first step - and it is, indeed - a step. It gets you closer to your goal, and it's not any different from (for example) - step 2: "Design the menus".

So, I've decided to put all of my energy to learning WPF as quick as possible. Made some inquiries, and finally decided on WPF 4 Unleashed .

So, how was it? Good and bad.

The good:

It covers a LOT of basic WPF stuff, starting from xaml reading and writing, layout options and all the way to advanced controls and graphics. The book covers every subject to in length, and provides tips, warnings, and example code.

The bad:

It's too boring and not well written. It is obvious the writer, Adam Nathan, knows a lot about WPF and its internal working mechanisms. Too bad he uses that knowledge to make things more complicated then simple. Some of the chapters were too complex and puzzling, leaving you confused instead of enlightened.

The conclusion:

It's not a bad book. I wouldn't recommend it as a must-read, and definitly not for those starting out with WPF, but it's a good book to keep around as reference, since its code examples may be copy-pasted directly into your own projects.

3/5.

-Shay

 

Monday, January 14, 2013

My big idea

It's about time to talk about my game.

A while ago, I've been talking to a good friend of mine about video games. Specifically, we were talking about games we liked as teen-agers. Gamers that are no longer available. And we found out we're always coming back to the same type of games, a type that's gone from this world. No-one seems to be creating those types of games anymore. I'm talking about space-combat-sim.

In case you have no idea what I'm talking about, I'll give a few examples: Star Wars: X-Wing, Star Wars: Tie Fighter, Star Wars: X-wing Alliance, Freespace 2 and so on.

In those games you usually play a pilot, flying some kind of space-craft into battle. You have various missions and goals, and you fight other crafts - big and small - to meet them.

But that's not all.

I'm not planning on making another TIE Fighter clone. I'm planning on making a level-engine for this type of game.

What does it mean?

It means that ANYONE around the world, by editing a simple XML file, will be able to create missions, briefings, and even whole campaigns!

The idea is very simple: all of the assets and game-logic (including AI) will aready be in the game. All the mission editor will have to do is simply define who and what happens on the mission. For example, a player may want to define the following simple rules:

  • A shuttle (called "Victory") moves from point A to point B.
  • 3 fighters (named Red1 to Red3) are escorting it.
  • The player, flying another fighter (Blue1) and his wingman (a bomber named Blue2) need to destroy the shuttle before it reaches point B.
  • If player dies - the level ends in failure.
  • If the shuttle reaches point B - the level end in failure.
  • If the shuttle is destroyed before reaching point B - the level ends in victory.

Simple enough, right?

Well, that's basically all the player will have to define. The fighters escorting the shuttle will know what their job is: they will automatically fly around the shuttle, and once an enemy gets close - will break off to attack them. They will fight to the death. Once the opposition gives up or is destroyed - they will move to escort the shuttle once more. Blue2 will know his job and follow orders given to him by the player. He'll also protect the player if necessary. The shuttle will make its way as fast as possible to point B, moving through the shortest route possible.

This example show how a very simple mission could go. The player making the mission (we'll call him designer) will only need to define some very simple stuff - and the engine will do the rest.

But that's not all!

Using the game engine and XML, the designer will be able to create in-game cutscenes, pre (and post) mission briefings, campaigns trees (since they're won't be linear) and in-game dilemmas that occur while playing.

I'm also planning on integrating an achievement and challanges system, as well as a personnal tracking system, and a global one.

But that's not all!

I'm also planning on sharing the glory!

If you're a level-designer, and you've created a good level (mission), or campaign - you'll be able to upload it to our servers, and once it gets approved - sell it through our in-game system.

This means players will have as many levels and campaigns as they want - some for free - and they'll be able to create new ones, and make money off of it. Probably not a LOT of money - but still - money is money.

So, that's it. There's actually a lot more to it - but that's the basic concept. What do you think? Will it make me rich?

Let's hope so

-Shay